sort order results

[Karl-Heinz]

Hi Chris

Build 2.0.0.5

Congratulations !

If the /vo13 switch is set, asort () - with and without a codeblock - shows now the same sort order as VO. No matter if the setting is #Windows or #clipper.

well done !

regards
Karl-Heinz

[Karl-Heinz]

Hi Chris,

I also tried "german2", and the "ASCII" sort is correct.

aSort := { "Übel", "Österreich" , "Ärger" , "Göthe" , "Goethe" , "Goldmann" , "Götz" , "Göbel"}

Goethe
Goldmann
Göbel
Göthe
Götz
Ärger
Österreich
Übel

i´m impressed !

BTW. is there anybody out there who ever used the german2.dll in VO ?

regards
Karl-Heinz

[robert]

Karl-Heinz,

Thanks for the feedback.
I am glad it works.
So can we expect your order for a FOX subscription soon <g>.

Robert

PS:
Did you also try the SetCollation(#Unicode). It should behave the same as SetCollation(#Windows) but should be somewhat faster and should also sort characters that are not in your Ansi codepage

[Karl-Heinz]

Hi Robert,

yes, collation #UNICODE and collation #WINDOWS sort orders are equal.
But it´s a little bit hard to detect the time differences with 8 items only

setinternational (#windows)
setcollation #unicode or #windows
"Lexikon"

Ärger
Göbel
Goethe
Goldmann
Göthe
Götz
Österreich
Übel


setinternational (#windows)
setcollation #unicode or #windows
"Telefonbuch"

Ärger
Göbel
Goethe
Göthe
Götz
Goldmann
Österreich
Übel

regards
Karl-Heinz

[Karl-Heinz]

Hi Chris and Robert,

something is working not correctly ....

setinternational ( #clipper)
setcollation ( #clipper )
setnatdll ( "german" )

i enhanced in the afternoon my sort array to have some more Umlaute: "Übel", "Österreich" and "Ärger" to test "german2" which sorts correctly.

aSort := { "Übel", "Österreich" , "Ärger" , "Göthe" , "Goethe" , "Goldmann" , "Götz" , "Göbel"}

but now, when i switch back to the x# "german" setting the result is the same result the VO german2.dll and x# "german2" gives ?


VO german2.dll + x# "german2" and currently x# "german" too.

Goethe
Goldmann
Göbel
Göthe
Götz
Ärger
Österreich
Übel


i´m not able to get with x# "german" this sort order:

VO german.dll

Ärger
Goethe
Goldmann
Göbel
Göthe
Götz
Österreich
Übel


- from Goethe upto Götz it´s always correct.

- setnatdll ( "german" )
? setnatdll() == "german"

- setnatdll ( "german2" )
? setnatdll() == "german2"


regards
Karl-Heinz

[Chris]

Hi Karl-Heinz,

Thanks, I also see the problem. Maybe the char weights are not correct, will have a look and will get back to you.

Chris

[Karl-Heinz]

very nice is the new runtimestate property "CompilerOptionVo13"

instead of setting the corresponding compiler switch in the IDE it´s now possible to set the VO compatible string comparison at runtime. The best place to do that is in the startup of the app where you set the general environment:

e.g.

setinternational ( #CLIPPER)
setcollation ( #CLIPPER )
setnatdll ( .... )
...
runtimestate:CompilerOptionVo13 := TRUE
...

regards
Karl-Heinz

[Chris]

Hi Karl-Heinz,

That was supposed to be undocumented

It's not exactly like that, though, this is only used so that the runtime is aware of the state of the option. The compiler itself still only knows the option passed to it at compile time, so the code generation will be based on what you had selected when compiling.

To see what I mean, please just compile this with /vo13 disabled:

FUNCTION Start( ) AS VOID
LOCAL c1,c2 AS STRING
LOCAL l AS LOGIC
l := c1 < c2
RETURN

and look at tthe generated code with ILSpy, then recompile with /vo13 enabled and see the difference.

The first version uses String.Compare() for the comparison, while the second uses a X# runtime function, __StringCompare() and this is not affected of course if you change the runtimestate at runtime.

Well, we could probably always call __StringCompare() nd then this function would check for the status of the runtimestate property, but I don't think it's worth (slightly) harmong performance for that.

Chris

[Karl-Heinz]

Hi Chris,

> That was supposed to be undocumented

but it is, see whatsnew.rtf

[...]
Fixed a problem with string comparisons in runtime functions like ASort(). This now also respects the new runtime property CompilerOptionVO13 to control the sorting.
[...]

i see the IL differences in your sample and also, that e.g. a Asort() string comparison behaviour - no matter if compiled with /Vo13 checked or uncecked - can be changed at runtime. So the question is: why is it allowed to change the CompilerOptionVO13 setting from outside. Or, in which constellation is it safe to change this setting from outside ?

regards
Karl-Heinz

[robert]

Karl-Heinz,
There is no "right" answer here.
In VO all string comparisons were using the VO style string comparison and were therefore respecting the Collation and in case of Clipper collation were using the weight tables from the nation module.

In .Net we do not want to force that, because these string comparisons are limited to the Ansi/OEM character set only and do not cover the full unicode character set. Therefore inside the base classes/structures such as USUAL we cannot know what kind of comparison you want to do. So we added this option, that allows you to control the string comparisons.
What you should realize is that this is a GLOBAL setting. So if your app sets this then also string comparisons in other components created with the X# runtime will be affected. This is good and bad at the same time. It depends on how you see it.
We initialize the setting only when you compile your main app with X#. So if you only created DLLs with X# but your main app is a C# app then you have no choice but to set / change this in your code.
Otherwise I would probably just let the compiler handle things.
You should also realize that if you create a DLL with X# and enable the option for compatible string comparisons then all comparisons between strings or between strings and usuals will be affected. However string comparisons inside usuals depend on the global setting. So if your main app uses a different setting then results may not be what you expect.
So in general: use the same setting for all your DLLs and app.

Robert