I have the same executable for a VFP9 app running on 2 servers.
On server 1 when user enters date 10/01/2022 into a text field with format property set to KD, and when text field loses focus, the value in the text field gets changed to 10/1/2022.
On server 2 when user enters date 10/01/2022 into a text field with format property set to KD, and when text field loses focus, the value in the text field does not get changed so it remains 10/01/2022.
I believe the format property having the D means to use windows settings and from what I have read/googled, perhaps the windows short date may be different on the 2 servers. Not really sure about any of that. Also, I can't find any VFP or otherwise documentation that would tell me from inside my VFP app, the windows setting for "is short date on?".
Any help appreciated,
John
tell me from inside my VFP app, the windows setting for "is short date on?"
I'd put it like: a local VFP instance's Date display is not affected by O/S setting as long as your code does not Set SysFormats On. The following custom check works for me in an En/US Windows as well as a German, and a French Windows UI. What are yours?
SET DATE SHORT
? ISALPHA(DTOC(DATE())) && returns .F.
SET DATE LONG
? ISALPHA(DTOC(DATE())) && returns .T.
As for the comment:
Perhaps this is a simpler asking of my question: The same exact executable is running on 2 servers. lddate=ctod("09/20/2022") On server 1, ?dtoc(lddate) returns "09/20/2022" On server 2 ?dtoc(lddate) returns "9/20/2022". What is causing the different results
Nobody can tell without seeing the two server's regional settings and the foxpro code of your executable.
Try to remove or disable any
Set Sysformats On
line in the foxpro code, the default settings there ought to be as documented
https://www.vfphelp.com/help/_5wn12pf0l.htm
The default date setting is AMERICAN
i.e. dtoc(Date(2022,9,20)) should return "09/20/2022" on both servers
Another possible cause could be a combination of an unusual Windows Short Date format. e.g. like d/M/yyyy, together with doing a SET DATE SHORT in the foxpro code
Related
Users who are used to working with another software package would like to type just the numbers of dates, without slashes: 0 9 1 8 2 0 1 7. They have developed "muscle-memory" for dates and are pretty grumpy about having to enter the slashes.
This is a "heads down" data-entry scenario where they have to enter hundreds of dates, and speed is a concern. They say that they often have to enter dates from previous years, and it takes too long to navigate to the past years using the dropdown calendar.
Is there a mode setting for the DevExpress DateEdit for Winforms which allows that mode of entry?
Try to specify a mask, I think it should work.
Set mask property, as you need.. but you must be clear what type of date format user will enter
In Qt5, the MMM format, which displays the month name in a short format (e.g., "Dec" instead of "12" or "December"), when using it for the Spanish locale, shows the abbreviated month name with a dot at the end, for example, for, "25th December 2016", in MMM/dd/yyyy format, shows "Dic./25/2016".
The problem is when editing. For displaying a date, it's ok, since it's what the Spanish rules say, but it isn't suitable for editing. I'm forced to position the cursor just after the point, at the end of the month part, to delete the point, and then, the rest of the month name. If I try to put the cursor just before the point, to edit just the month name part, the field is in "read-only" mode. I can't not remove anything, unless I remove everything from the very right of the line and back, character to character (or just selecting the whole month part and remove everything).
Besides, the point is not autocompleted. So, if the user writes the new month forgetting the dot, the edition is rejected and fall backs to the original value.
Taking all of it into account, editing a QDateEdit is a bit cumbersome (in Spanish).
I don't know if it is the built-in QDateEdit behaviour, or internally it is using a QRegExpValidator, but in that case, I don't know what it's the regexp expression, to personalize it from it.
In short, how can I "solved" it? (the cumbersome edition; it's ok for me both, removing the dot, or changing the validation).
The Qt 5 behavior is correct and there's nothing Qt can do (or should do). The only correct and acceptable short name of December in a es_ES locale is "dic.", trailing dot included. That's what CLDR says:
http://www.unicode.org/cldr/charts/30/summary/es.html#1636
http://www.unicode.org/cldr/charts/30/verify/dates/es.html
Is there a way to store subscript and superscript values in the Progress database, for example, chemical symbols and formulas, such as C2H5OH, and is it possible to display them ?
I tried copying from Word and pasting into fill in string fields but it doesn't format correctly, it doesn't recognize subscripted values and it is displayed as C2H5OH.
After some testing I've come this far:
1) You need to start your session with startup parameter -cpinternal utf-8 ie
prowin32.exe -cpinternal utf8
Depending on your need you might also need to set -cpstream utf-8 and possibly -cpcoll basic (or something else that matches your needs).
When I did this I had some strange crashes - but that might be because I edited a file saved in another codepage?
2) You need to get the data into your system (perhaps you already have it?).
I used Word and information found here and further explained here. The subscript font setting are just font settings (not unicode) so don't let that fool you (copy-pasting from your question is exactly the same). Basically you need to write the hexadecimal value of the subscript 2 (2082) in Word and then press Alt + X.
Assuming you want to write the actual data in a Progress based GUI I haven't been successful so far. Perhaps you could look at changing registry values as described in the links and continue along that path. I don't want to do that for just basic testing...
3) You will need a font with decent support for these characters. Some fonts don't support them at all!
Segoe UI:
Default system font (possibly) MS Sans Serif:
Arial:
5) Database? I'm unsure if you will need to use CLOB-fields to store this in your database or not. Most likely you shouldn't.
Hope this is enough to at least get you started!
This week we upgraded to JasperReports Server 4.7 (Professional) and iReport 4.7. I have several reports that I created in iReport 4.5.1 and successfully used in JasperReports Server 4.5.1.
After the upgrade, all of my dollar signs are now little boxes. The pattern for my currency fields is ¤ #,##0.00. JasperReports Server is not replacing the box with a dollar sign when the report is generated. Everything looks ok in the pattern sample. My percentage symbols are all still working. I tried removing and applying the currency pattern to the fields again, but this didn't fix the problem.
Any thoughts on how I can fix this?
This is Java operating as intended... but not as you want it to operate. Your locale does not specify a currency, so you get that "¤" symbol.
You could workaround it by changing your locale from "en" to "en_US". I just did this last week. As a side note, I found one tweak that I needed to make. After changing the locale to en_US I needed to copy one file like this:
cp .../jasperserver-pro/scripts/jquery/js/jquery.ui.datepicker-en.js .../jasperserver-pro/scripts/jquery/js/jquery.ui.datepicker-en-US.js
Alternatively, I usually find it's better to work around it by setting your format mask to use a hard-coded dollar sign. If you are displaying "$50.00" to a user in the United States, it would be nonsensical to display "€50,00" to a European user or "¥50.00" to a Japanese user for the same value. There are lots of times when the hard-coded currency symbol is more appropriate.
We restored from a backup in a different format to a new MySQL structure (which is setup correctly for UTF-8 support). We have weird characters showing in the browser, but we're not sure what they're called so we can find a master list of what they translate to.
I have noticed that they do, in fact, correlate to a specific character. For example:
â„¢ always translates to ™
— always translates to —
• always translates to ·
I referenced this post, which got me started, but this is far from a complete list. Either I'm not searching for the correct name, or the "master list" of these bad-to-good conversions as a reference doesn't exist.
Reference:
Detecting utf8 broken characters in MySQL
Also, when trying to search via MySQL query, if I search for â, I always get MySQL treating it as an "a". Is there any way to tweak my MySQL queries so that they are more literal searches? We don't use internationalization much so I can safely assume any fields containing the â character is considered to be a problematic entry, which would need to be remedied by our "fixit" script we're building.
Instead of designing a "fixit" script to go through and replace this data, I think it would be better to simply fix the issue directly. It seems like the data was originally stored in a different format than UTF-8 so that when you brought it into the table that was set up for UTF-8, it garbled the text. If you have the opportunity, go back to your original backup to determine the format the data was stored in. If you can't do that, you will probably need to do a bit of trial and error to figure out which format the data is in. However, once you know that, conversion is easy. Read the following article's section on Repairing:
http://www.istognosis.com/en/mysql/35-garbled-data-set-utf8-characters-to-mysql-
Basically you are going to set the column to BINARY and then set it to the original charset. That should make the text appear properly (a good check to know you are using the correct charset). Once that is done, set the column to UTF-8. This will convert the data properly and it will correct the problems you are currently experiencing.