Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Default textbox for cyrillic/diacritics occupy 2 spaces (áúőьяаășț)

Status
Not open for further replies.

Webstar2000

Programmer
Sep 11, 2023
3
RO
Hello there,

I'm having a hard time trying to make cyrillic or diacritics characters work in VFP9.
After many tries I finally managed to gather these type of characters from SQL database to Cursor and show them readable.

photo1_vmx2hi.png


And this is how it looks in grid.
photo2_a0z8cw.png


Now the problem is when I'm trying to write something.. I get the following behaviour:
Cyrillic_mmscx7.gif


When I'm trying to "scroll" through text, where there are diacritics or cyrillic data, instead of 1 press on the right key to go to the next letter, I have to press twice. Same thing happens in grid too.

What I know:
-They are double-byte data, I'm aware of that, I know maybe I have to do some post-processing after I gather my data but I tried all combinations of STRCONV() and nothing worked properly.
-I use no form of transformations or formats in order to get FROM SQL to textbox, that means I use no "FontCharSet" in neither of textbox or grid, cause if I do use them, it shows them very bad
(example):
photo3_lkzko7.png

-My CODEPAGE is set to AUTO in config.fpw
-In reports I get different kind of behaviour
In report viewer it shows kind of weird like this:
reportviewer_ecadkn.png

But when I print it, it shows normal like this:
printed_tqo2jh.png

-I have already set on my Windows the UTF-8 worldwide compatibility (the checkbox from the Regional settings in Control Panel)
worldwidelanguage_ex3foy.png


TL;DR: What I want (if possible) is:
Gather cyrillic/diactriic data from SQL
Be able to add data like this, or edit it and insert it back in SQL (UPDATE)
Show them to look nice on reports

I mostly want Bulgarian(шеяш), Hungarian(áűúőé) and Romanian(ăâșț) data

I feel like I've been close to the answer so many times and I just missed it, does someone have some suggestions on how do I approach this or is it possible?
P.S: I already ruled out ActiveX controls since Windows 10 (from what I've read) I can no longer use Microsoft Forms 2.0 TextBox and I couldn't find any ActiveX (or maybe I didn't know where to properly search for them)
 
Double-byte ANSI codepages, Unicode and UTF-8 support is very limited in VFP, I don't know a mode that would at least move the text cursor correctly, for example.

You have LENC( ) instead of LEN() to get the length in characters instead of bytes, and ISLEADBYTE(cExpression) is a very specific function to tell you whether you have the first (lead) byte of a double-byte charactr or not, but as your experience shows, even if you prepare VFP to show correct Cyrillic characters in a textbox, it doesn't behave well with the arrow keys, for example.

If anyone could tell you about such things it would be but I guess it's hardly useful, when you don't speak russian. Then Steven Black. I don't know if his INTL toolkit would cover the textbox input, if not I'm afraid he's not working with or for VFP anymore. So the best advice is using Unicode-capable ActiveX controls instead of VFPs native controls.


Chriss
 
I agree with Chris that your best bet would be to look for an ActiveX control that specifically supports Unicode.

I suggest you start by looking at DBI ( I don't have any recent experience of their products, but I did use one of their older libraries some years ago, and was very pleased with it. No problem in using it with VFP. I see they now have a library called Studio Controls COM 64, which looks like it might meet your needs.

The main snag with DBI is that you have to buy the entire library - you can't just pick the items that you want. It's not particularly cheap, but there is an evaluation version.

DBI isn't the only possibility. There are other ActiveX controls available that might be suitable. Other forum members should be able to give some suggestions.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
I wonder if the textbox behaves correctly only on a Cyrillic or other Windows using codepage 1251 by default. Because even using features like the beta UTF8 support don't make VFP use unicode or utf8 by default.

Maybe it helps to do what Tom Borgman said in thread184-1813661:
Tom Borgman said:
adding CODEPAGE=1251 to config.fpw and placing vfp9rrus.dll into install directory was enough

Chriss
 
Mike,

I did see the article by Rick Strahl, that's how I was able to gather data from SQL in a safe manner, yet.. when he got to the point to show it in UI he also used ActiveX so I guess there's no chance for me without it.

Chris,

I did pay some attention to but it's very hard since I do not speak Russian, I tried to search through some articles by translating them to English but I didn't find anything related to this subject.

About your last post, I already tried the CODEPAGE=1251 in config.fpw and the dll near .exe, I had following results:
1. With FontCharSet of Cyrillic
The data I pull from database looks very bad, but I can write Cyrillic characters (Bulgarian: шеяш) and the cursor works fine, but only Bulgarian.. no Hungarian or Romanian, they don't look anything readable.

2. Without FontCharSet (0)
I can see properly the data I gather from database but I get the same behaviour in textbox/grids..

I guess the only chance I've got is to find a good ActiveX control to use..
 
Take a look at the various codepage values that is supported by VFP. Help gives the following:

1250 Eastern European Windows
1251 Russian Windows
1252 Windows ANSI
1253 Greek Windows
1254 Turkish Windows
1255 Hebrew Windows
1256 Arabic Windows

You might have to use a different value for different languages/regions.



Greg
 
Webstar, did you convert to UTF8? When you use codepage 1251 you alo have to convert the unicode coming from SQL Server into codepage 1251.

And RE ggreen61, codepage 1250 is for other Eastern European languages. Also, see Wikipedia:

Wikipedua said:
It is also used for Polish, Slovak, Hungarian, Slovene, Serbo-Croatian (Latin script), Romanian (before a 1993 spelling reform)

Conclusion: Only Unicode (no matter if UTF-8 UTF16 UCS, or other variants) allows usage of multiple languages at the same time, but VFP has no Unicode capable controls, even though it can display UTF8 (as codepage 65001), but VFP controls don't work correctly with Codepage=65001 in the config.fpw and there is no vfp9rutf8.dll or similar. I haven't tried but I bet VFP control won't recognize whenever a character is 2 (or even more) bytes long. Also not with the beta utf8 application setting of Windows.

VFPs ANSI architecture only allows limited support of multiple languages, as ANSI only allows groups of some languages, mainly of course with the Latin alphabet and even though Cyrillic is the base of multiple languages, too, you see the full Cyrillic alphabet is spread in two ANSI codepages, not one. That's not VFPs construct, that's ANSI. As a consequence, though, you can only support some Western languages with codepage 1252 in parallel. If you want to support other languages, that works with other codepages, but generally not at the same time, and while UTF-8 is a good basis for all language support there's a lack in controls behavior, obviously.

Chriss
 
Hello everyone,

As an update, I discovered this hidden gem Thread where Olaf is talking about cyrillic and diacritics and everything using Microsoft Forms 2.0 ActiveX

Using his guidance from this thread I managed to use the Microsoft Forms 2.0 Textbox control to gather my data from SQL properly, edit and update them back to SQL without problems.

For everyone having problems with these type of data I suggest taking a look at his example where he creates a form with one OLECONTROL and a button on it and from there it's easy to see how he has done it.

Thank u everyone for your help and suggestions !
 
Could you post your complete code so that it can be easily reproduced for others to use?

Greg
 
There's one general ActiveX you could also use - the Webbrowser control. That of course can use UTF-8 within HTML. Your name, Webstar2000, suggests you're fluent in HTML and JS and could use them. And while it's harder to get the Webbrowser ActiveX control to behave with modern HTML5 features, you don't need very much of that for input forms. It's all quite more work with the transfer to and from HTML and controlling HTML forms, but it may also be worth it when you're fluent in that area, too. I would digress from creating an HTML textbox, edit box checkbox etc. equivalent based on input types and using a Webbrowser control per interface control, rather use a set of HTML input controls in one Webbrowser control. Rick Strahl has the details on that in his article, too.

MS Forms controls are a good set of ActiveX controls,if you want to stay on that route. I don't know if there's a Treeview, though. Notice that the MS Treeview control is not Unicode, for example, and has the Font.Charset property just like VFPs FontCharset is. So when the need arises, it's best to have a set of ActiveX controls that all support Unicode in the same manner. AFAIK you can't license Microsoft Forms 2.0 for distribution of them, users will need to have Office to have these MS Forms ActiveX controls available. That's not bad, as Office automation is often something you do anyway, also requiring Office at least for the final consumption of generated spreadsheets or such output, too. But it might be worth looking into a suite of ActiveX controls to cover your needs. And it's easy enough to find a suite that's covering more than VFPs controls do.

Chriss
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top