🚀 go-pugleaf

Hi Jens:

>>
But if what you are saying is correct, one will never know what stringtable
(= language) will be chosen on a user's machine...?
<<

Well, yes and no.   NT should work correctly all the time, it's Win95 where
the problem is.  Since my last post, the VB tech support got back to me with
a bit more details.  Apparantly, OSR2 is working the way it is *supposed* to
work (i.e. earlier versions were not working correctly, even if they did
load the proper strings <g>).

The way it was explained to me (or I how I now understand it), is that Win95
will first look for the lang id in the same family of the version of the
installed Windows, regardless of what the user has chosen in the Regional
settings. For example, if Win95 US English version is installed, and your
resource file has English (Canadian), English (British), and English (US),
in that order, as the string tables, because Win95 is US english then it
will load your US Eng resource table ( I have not tested this yet, but am
planning on it in the near future).  If no English string tables exist, then
it will use the first table it finds in resource.   If you were to have US
Win95 installed, and the resource file contained French (Canadian) and
English (Canadian), in that order (French being the default/first table in
the resource), Win95 will load the English (Canadian) string table because
it is the same language family as the installed US Win95.

>
Right now I'm using the multi-language stringtable while developing, since I
can then do both languages at the same time. Then I make a copy of the
.RES-file, delete one of the tables, and compile....! And then I add the
original .RES-file again for on-going development.
<

That is basically what VBTech Support suggested I do.

I believe I have convinced Tech Support of the need to change VB itself  to
better handle the string resources (based on the regional settings) than the
default for Win95.  Whether or not VB development can do this (or feels it
is warranted) I have no idea.

Doug.