Polish characters in VFP,

[Jureczek13]

Is there any way to display Polish characters in VFP, like ą, ć, ę, ł, ń, ó, ś, ż, ź (to type this characters outside VFP, I use right ALT + letter)
When I type them in VFP, I'getting this:
When I copy these funny characters outside VFP, I'm getting them back: ą, ć, ę, ł, ń, ó, ś, ż, ź

 

[herbstgy]

there should be a CODEPAGE= row in your config.fpw file.
CODEPAGE=AUTO means Foxpro follows your machine international setting.
CODEPAGE=1250 would mean Eastern European settings. then you should be able to see your national characters.
(you should also see your COLLATE parameter which sets the national sort ordering)

 

[Chris Miller]

It's already the essential answer. To add: When you have no config.fpw the codepage VFP uses is the same as with CODEPAGE=AUTO and it will only depend on the language setting of Windows. You'll see what codepage VFP uses with CPCURRENT() and when that doesn't match the Windows language setting, that is always shown with CPCURRENT(1) you should look why and how this is overridden. CPCURRENT(2) will show MSDOS codepage, for sake of completeness.

I think config.fpw is one way, another is within registry keys and a third way within foxuser.dbf. Not sure, but generally those are the three places settings can be changed and maybe it's even done in two of them and in a contradicting way.

Before digging anywhere, the easiest way to the codepage including Polish letters is setting the Windows language to Polish. If there is a reason Windows is English or something else, then you have to override VFPs codepage choice to be able to write code and comments and anything else with the ansi codepage that contains Polish letters, 1250 for Windows and 852 for DOS.

 

[Jureczek13]

Thanks for answers. But still didn't work.
But there is another question. Let's assume that it did work on my computer.
Can I be sure that when I compile my program to .exe, and send to my friends, will it work on any computer regardless their settings.
I think it won't work. In this case, I have to stop and have my programs written in English.
Thanks again for your effort.

 

[mJindrova]

How to change the display language for non-Unicode programs The window: https://activenetwork.my.salesforce...cle/Setting-Language-for-Non-Unicode-Programs --- Do not check UTF-8

 

[Chris Miller]

For the final exe, besides the setting Martina Jindrova suggests, you have the already mentioned CODEPAGE=something in a config.fpw you can provide externally or embedded within the EXE, and you have all the different language/region resource DLLs in C:\Program Files (x86)\Common Files\Microsoft Shared\VFP from VFP9rchs.dll to VFP9rrus.dll for distribution. The dll will be picked automatically according to Windows regional setting, you can override that, as said and then you can also force one of them with the command line option -LFileName where Filename is the filename of such a DLL. You can provide all of them so the automatic region dependency kicks in. You can't expect everything to switch to the DLL language, though, for further internationalization the best option is to use the INTL Toolkit from Steven Black. Before digging into that, look at the help chapters about international applications, there are some topics about that in the VFP help.

Sidenote & essence of that: It's totally possible to write applications in any specific language, if not even supporting multiple languages with or without the INTL Toolkit.

What did you try and what do you expect? The VFP9 IDE itself will stay English, that won't switch to Polish by changing the codepage, but with codepage 1250 you will be able to write polish letters in your code, in comments, in texts, in label and form captions, etc. and they also show up as Polish for clients using your final EXE, provided you set to codepage 1250 for them, too. It will also be the automatic setting when they run the final EXE on a Polish Windows or MUI Windows set to Polish region/language, just like the command line option -L also works for your EXEs, not only for VFP9.exe - so these mechanism are not IDE only mechanisms.

This all also works correspondingly for VFP6-8, which version of VFP are you using? And which version of Windows? MUI (multiple language user interface) was introduced with Windows 2000, I hope you're not using Win95/98 with FPDOS, or all these recommendations are not working, of course.

 

[Chris Miller]

I use right ALT + letter

Specifically on that topic. I don't know why you would do that, if you mean the way to make use of holding down ALT while entering a unicode codepoint, that will result in unicode characters that don't at all match an ansi codepage, neither the wrong nor the right one. Googling Polish keyboard layout I find this: http://kbdlayout.info/KBDPL/
Which tells me many of the polish letters are even just plain keys, or SHIFT+key for upper case, as it is with the usual 26 latin letters and then you get some letters with AltGr, like AltGr+D, for example.

The Unicode characters won't help you, whatever you set the codepage to.

It makes me think, whether you have defined and automatically loaded keyboard macros in a previous VFP version, which went missing now, where you defined ALT+letters to result in certain polish letters, which don't usually result from ALT+letter, though. Have you upgraded VFP recently? Do you have FKY files that store such macro definitions? Also see https://hackfox.github.io/section4/s4g193.html

 

[Chris Miller]

For testing I just installed the Polish language pack and keyboard layouts. (Still downloading)
Using an English keyboard layout with codepage 1250 does not lead to polish letters, both have to match.

Do you have a polish keyboard layout installed and set as current keyboard configuration? It should show in the systray, if you activate the language bar:

Here Polish 214.

Here the Programmers layout.

You can add these without changing the main Windows language.

 

[Chris Miller]

...breaking news...

My final experience with this is, that neither setting CODEPAGE=1250 nor having a polish keyboard layout nor both at the same time was sufficient to get Polish letters displayed in the VFP9 IDE. Martina Jindrova has the major point, in the administrative tab of Windows language settings the system locale has to be set to "Polish (Poland)" to get this going, the CPCURRENT(1) codepage then becomes 1250.


Here's a screenshot demonstrating it then works (fontsize set to 20 for a clear distintion from lower case l and upper case L).

On the other hand that's also the usual situation for a Polish Windows user without making that setting and when the locale is Polish you also don't need a config.fpw that sets CODEPAGE=1250, instead CPCURRENT() and CPCURRENT(1) is 1250 in that situation. Also, this combines with Windows display language set to another, if that's something you still need.

I didn't need ALT for these letters, I wonder what specific letters you thought of, as the keyboard layout shows most Polish letters simply are normal keys in the Polish layouts.

 

[Chris Miller]

Final thoughts:

It's true that other applications (Unicode capable applications) allow using the polish keyboard layout and input with them without having the system locale set to Polish (Poland). What I take from this that Windows makes a differrence of input language and display language, the VFP CODEPAGE=1250 setting is only covering the display language, which does not help to provide a polilsh application that displays Polish texts but doesn't support Pollish input. So it's not only a developer problem, but also an end user problem. We have to live with this downside of ANSI applications. It shouldn't be a problem with Polish users that also set their system locale to Polish, though.

The remaining questions are in the direction what problems you have with your development system, if you are a Polish developer with a Polish Windows, VFP should work for you even without any specific settings as the system locale should be Polish already. I can only assume you're either dealing with ealier Windows and/or VFP versions.

 

[ggreen61]

What is the source of the Polish text being displayed? If it is a cursor (from a SELECT-SQL command) and bound to the control, then the table CodePage should be set to 1250. By default, it will be set to VFP default value. In the create command for a cursor you can set the CodePage value. Example:

CREATE CURSOR c_polish CODEPAGE=1250 (field1 C(50), ...)

&&  do your field binding to the control(s)

SELECT field1, ... FROM textsource INTO CURSOR c_temp
SELECT c_polish
ZAP IN c_polish        && remove any from a previous COPY FROM...
COPY FROM DBF('c_temp')
USE IN SELECT('c_temp')

This might give you what you need to see the characters correctly.

 

[wOOdy-Soft]

And just as another tidbid: Almost every control in VFP's forms also has a FONTCHARSET property. If you set this to your desired codepage, then VFP will use that for displaying your data. That way you can even display different languages on a single form: the english original, a russian, bulgarian, polish textbox with proper foreign characters. etc. They will stil get saved as one of the 255 possible characters of the Ansi alphabet, and looking in browse window will show the standard character representation, but with the proper FontCharSet it will show as desired.

wOOdy

 

[Chris Miller]

Displaying something is not the only problem, though. The input is driven by the system locale, no matter if you set other keyboards. Switching to POL 214 I got ³ (superscript 3) instead of ł, for example. But in Unicode aware applications like Notepad++ the keyboard layout worked, as the system locale codepage for non Unicode application does, well, only apply for non Unicode applications, and I wonder how many other programming platforms even still create ANSI executables.

 

[wOOdy-Soft]

Displaying something is not the only problem, though. The input is driven by the system locale, no matter if you set other keyboards. Switching to POL 214 I got ³ (superscript 3) instead of ł, for example. But in Unicode aware applications like Notepad++ the keyboard layout worked, as the system locale codepage for non Unicode application does, well, only apply for non Unicode applications, and I wonder how many other programming platforms even still create ANSI executables.

Since that FontCharSet also works in Text- and Editboxes, you can enter polish characters on the fly. At least if you know the threeletter-AltCode (i.e.the Position in the 255 char Ansi table) or if you have the polish keyboard driver activated. Windows always uses Unicode, but converts the entered 2Byte chars to the corresponding 1Byte char if possible. That mappingtable is set to the current activated codepage for our NonUnicodeApp. That's done either by that global Windows setting, withe the Codepage setting in config.fpw or with our FontCharSet on a PerControl base.

Then there's another codepage setting for DBFs, but this isn't involved here, it just maps reading and writing data; mostly in a multi-environment setup, where different OS (like DOS, Win, Linux) are using the same tables with different Ascii codings.

 

[Chris Miller]

wOOdy, I have to try the effect of the FontCharset on controls, but when I start an editor with (for example) MODIFY COMMAND main.prg AS 1250 and have the Polish keyboard layout activated and still don't get the Polish letters from they keys that should give them, I still only see Martina's solution to set the locale for non-Unicode applications as the only working one for the developer writing code and forms and texts in labels, etc.

I don't see the effect of the automatic Unicode to Ansi translation in VFP. I see the keyboard layout and keys working as expected in Notepad++, as that is a Unicode capable application, but that's not helping in the VFP IDE. Jureczek13 did not only address problems end user's might have, but also his own development within the IDE. So as Polish developer you need a Windows with Polish language pack, set the locale for Polish and then everything works as expected on that level. I don't see this working without the locale set to Polish, though.

So unless you don't add in something like keyboard makros or any tool that makes the necessary mappings, I don't see Windows doing that without setting the locale for non Unicode applications, i.e. I don't see that Windows converts the entered 2Byte chars to the corresponding 1Byte char within the VFP IDE in the code ediitor windows.