Search Combo Box revisited 2

[herbstgy]

Hi Guys,

I tried to create a Search Combo Box like you were discussed in thread184-1312767.
Also tried Mike Gagnon's solution with the ComboBox Interactive Event modification in faq184-1792.
Both solution does what it supposed to, with one flaw: neither of them works with international characters.
Does anyone have an idea to circumvent this problem?

 

[herbstgy]

The code is really just a few lines, if you don't understand what something is doing feel free to ask.

Thank you, Olaf.

Yes, I saw those lines in the code you emphasized. They have given value in those lines, but those values never used later and the properties never referred anywhere else in the code, so I truly don't understand why they needed. Maybe I lack some basic knowledge which is elementary for anyone else.

 

[herbstgy]

The first problem I see in your approach is trying to create a table into HOME(). This by default is in Program Files directory write protected and you'll likely find your DBF in your profile in some subfolder of C:\Users\%Username%\AppData\Roaming\Microsoft\Visual FoxPro 9}...
So you're doing this too literally as VFP. VFP has one advantage: It has installed this DBF where it is, during installation you can write files and such writes are not redirected. Do you know such mechanisms as write redirections since Vista? So first criticism is: Store your data in your own directories. The way VFP works with his central DBF is surely something you would need to replace when you deploy your application anyway.

No, sorry. I'm not creating the DBF in HOME(), but in HOME(7), which points to %APPDATA%\Microsoft\Visual FoxPro 9\ which is a read/write directory, and unique to each user.
The DBF is created as it supposed to (that was the first thing I checked) and filled with the expected data. Its codepage is 1250, which is the local default.

Next, I can't judge what your expression ALLTRIM(addr_city)+' '+ALLTRIM(addr_street)+' '+TRANSFORM(addr_number,'@Z 999.')+' '+ALLTRIM(company) AS srchdata results in, I don't have your gepek.dbf
And in regard what I told about codepage, what is CPDBF("gepek.dbf")

gepek.dbf has a codepage of 852, because it's inherited from an old FoxPro 2.6 for DOS app. yup, that's still a thing.
but it's translated by the select statement to 1250 automatically.

Is that the same code as you create with your CREATE TABLE statement? You obviously miss, that CREATE TABLE has a codepage=nnnn option, and if you don't use that and create a dbf with VFPs default codepage,

no, I didn't miss that. There's a "SET CPCOMPILE TO" command in VFP, by which you can set to create all new tables to the codepage to your liking. It is set to 1250, so any DBF I use is converted in flight to that.
I also tried to set explicitly CODEPAGE=1250 in the CREATE TABLE statement, but the result is the same.
[/quote]

which will depend on your locale, yes - of course - you are likely destroying your data because your insert of the data isn't converting anything. You can only copy this way when the source and target DBF have the same codepage.

the first thing I checked in qsrch.dbf that if the codepage and the accented characters are correct. they seemingly are.

 

[Olaf Doschke]

t's translated by the select statement to 1250 automatically.

did you check that? Did you browse your qsrch.dbf?
did you do a comparison, I just copied from codepage 850 to 1250 and for example À is not translated correctly.

I suggest you keep the data in the codepage it is to not loose anything. Or you better adapt the migration to corectly convert the data. It's jsut not done by INSERT INTO new.dbf (fields) SELECT ... FROM old.dbf

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[herbstgy]

Quote (herbstgy)
t's translated by the select statement to 1250 automatically.
did you check that? Did you browse your qsrch.dbf?
did you do a comparison, I just copied from codepage 850 to 1250 and for example À is not translated correctly.

of course I did. I even checked it by hex view from outside VFP.
but let's forget my qsrch.dbf for a moment.
I turned off completely this prepopulated search suggestions and let VFP do its thing with autocomp.dbf.
and it doesn't work as it does for you.
Yes, I saw your screenshot and I understand it should be working, but it doesn't.
For example, if I type "b", it shows the all the autocomplete matches starting with "b", that's okay. Among the matches, there's a "Bősárkány" (don't laugh, that's a village name here - it roughly translates to "Bigdragon") the 2nd char is CHR(245). But when I type "Bő", "Bősárkány" doesn't appear in the autocomplete matches. This drives me crazy.
And the punchline is, if I type through "Bősárkány", and press enter (start the search), it shows the searched record as it supposed to! It just doesn't appear in the autocomplete suggestions.

 

[Olaf Doschke]

of course I did. I even checked it by hex view from outside VFP. :)

Well, the bytes being the same proves there was not translation done.

If you use two different codepages, that have enough overlap in their character set to store the same text, same characters don't necessarily have the same byte values. Indeed if all characters would have the same byte values, that would mean the codepages are identical.

If you want to comapre data, you'll need to convert your old.dbf and new.dbf texts to UTF-8, for example,any encoding that is capable to have all characters of both codepages. And if that data doesn't differ bytewise, then you have equal characters.

Sorry, but bytewise comparison of ANSI data is besides the point.

For example, the ő in your village name Bősárkány doesn't get over to codepage 1252, in which VFPs autocomp table is encoded here, for me.
Your only problems seem to be codepage problems.

I don't get VFP started with codepage 1250, even using a config.fpw with CODEPAGE = 1250. I may continue tomorrow, but you may investigate in the direction codepage problems you have.
Besides CPCompile the CPCurrent() is more important besides dbf

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[herbstgy]

Well, the bytes being the same proves there was not translation done.

sorry, I guess you misunderstood me. I checked the DBF's in question. the bytes are not the same, the codepage translation happened as it is intended.

this is the header of the source dbf:

[pre]Structure for table: M:\DATAS\GEPEK.DBF
Number of data records: 4545
Date of last update: 2018.08.04
Memo file block size: 64
Code Page: 852[/pre]

this is the interim cursor, the result of the SELECT statement:

[pre]Structure for table: C:\USERS\HERBSTGY\APPDATA\LOCAL\TEMP\00003AQ101DF.TMP
Number of data records: 2059
Date of last update: . .
Code Page: 1250
[/pre]
this is the result DBF for the predefined search suggestions:

[pre]Structure for table: C:\USERS\HERBSTGY\APPDATA\ROAMING\MICROSOFT\VISUAL FOXPRO 9\QSRCH.DBF
Number of data records: 2059
Date of last update: 2018.08.09
Memo file block size: 64
Code Page: 1250[/pre]

also, the header of the default AUTOCOMP.DBF:

[pre]Structure for table: C:\USERS\HERBSTGY\APPDATA\ROAMING\MICROSOFT\VISUAL FOXPRO 9\AUTOCOMP.DBF
Number of data records: 9
Date of last update: 2018.08.09
Memo file block size: 64
Code Page: 1250[/pre]

CPCURRENT() value (default VFP codepage): 1250
CPCURRENT(1) value (default Windows codepage): 1250
CPCURRENT(2) value (underlying operating system codepage): 852

there is no additional codepage setting in config.fpw, everything left to default.

 

[Olaf Doschke]

Now you misunderstood.

To reproduce your problem I need to get my VFP into Codepage 1250 mode, but it doesn't react to a config.fpw so far.
Fine that you checked your headers are having the cirrect codepage numbers,

Did you look at some words/names giving you trouble in a browse, at least?

VFP will use the codepage given in the DBF to display the data, but in my tests the data you transfer is copied 1:1 by byte values, not by the look of the characters.
You must have a problem with your data, because otherwise it will be displayed and found via autocomplete. I'll see if I get my VFP going in CP1250 somehow to test that sepcific case.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Koen Piller]

Hi

Indeed I don't see acstyle used or have an idea why it is defined

the property was replaced with the local lnStyle.
the first coding was:

THIS.acStyle = THIS.Style
IF THIS.Style = 2
   THIS.Style = 0
ENDI

IF (lnLastKey >= 32 and lnLastKey <= 126)
	IF THIS.SelStart >= 1
		lcDisplayValue = SUBSTR(THIS.DisplayValue,1,THIS.SelStart-1)+(CHR(lnLastKey))
	ELSE
		lcDisplayValue = (CHR(lnLastKey))+ALLT(THIS.DisplayValue)
	ENDI
	IF EMPTY(lcDisplayValue)
		lcDisplayValue = ALLT(CHR(lnLastKey))
	ENDI
	FOR i = 1 TO THIS.ListCount
		IF UPPER(lcDisplayValue)==UPPER(SUBSTR(THIS.List(i),1,LEN(lcDisplayValue)))
			THIS.DisplayValue = THIS.List(i)
			WITH ThisForm
				.LastListNumber = i
				.List1.Refresh()
				.List1.Visible = .T.
			ENDWITH	
			THIS.SelStart = LEN(lcDisplayValue)
			nlLength = LEN(ALLT(THIS.DisplayValue))-LEN(lcDisplayValue)
			THIS.SelLength = IIF(nlLength<0,0,nlLength)
			THIS.LastDisplayValue = THIS.DisplayValue
			THIS.LastSelStart = THIS.SelStart
			THIS.LastSelLength = THIS.SelLength
			KEYBOARD '{F4}'
			RETURN
		ENDI
	ENDF
	IF THIS.acStyle = 2
		THIS.DisplayValue = THIS.LastDisplayValue
		THIS.SelStart = THIS.LastSelStart
		THIS.SelLength = THIS.LastSelLength
	ENDIF
ENDI

Koen

 

[Olaf Doschke]

The simplest reason, why you don't ever get ő is it's not a character in codepage 1250, the closest you have is ô.
Codepage 1252 gives you ő, but likely misses some other characters for which you choose codepage 1250, you'll have your reasons.

In your old dbf an ő will be byte 0x8B, in codepage 1250 it doesn't exist, in codepage 1252 it is 0xF5.

If I make that change manually I get autocomplete to work with the letter:

All you have is a codepage problem.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[herbstgy]

of course there is "ő" and capital "Ő" in codepage 1250. this is the default codepage for Eastern European Windows.

 

[Olaf Doschke]

Well,

https://de.wikipedia.org/wiki/Windows-1250

Do you really think I can't look into a codepage, which characters it has and which not?

The characters most similar to ő or Ő are:

oóôőö and in upper case OÓÔŐÖ

But none of them is ő or Ő.

This is something really very objectively checkable, just copy and paste a ő into a cp1250 dbf and what's coming over is an o.

Bye, Olaf.



Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

OK, sorry, forget about it, as you can see in my screenshot of autocomplete with Bõsárkány, at some step ő changed to õ, and I demonstrated autocomplete with Bõsárkány.

Now redoing that...

I can store the word in a codepage 1250 autocomp table, though pasting ő turns it into o:

I had to hack it to become chr(0xf5):

but I can't get my VFP session to work in that codepage, so I can't type in ő

So what's your case, if you browse your autocomp table, do you find the right character in it, or did the ő become an o or even an õ?
Or do you get as far as in that screenshot and then typing ő fails?

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[herbstgy]

Or do you get as far as in that screenshot and then typing ő fails?

I'd love to, but I'm not really familiar with this forum engine.
actually, I tried that days ago.
how do you insert pictures?
I only succeeded to upload one as attachment, but not insert into a post.

 

[Olaf Doschke]

All I asked for is a description, but to upload an image inline use this icon in the toolbar:

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name