Writing Visual Basic 6.0 forms and controls into Win32 resource files (.res. rc)
Klaus Woersdoerfer
(contains 21 controls) into Win32 resource files (.rc, .res) to give these
resource files (satellite DLLs) to translators (Asian languages). The
translator then sees the dialogs and is able to adapt the size of the
controls adequate to the length of the strings in the languages.
One solution for this problem ist the tool TsiWin32Dialog.dll from Michael
S. Kaplan supplied on the CD to his book "Internationalization with Visual
Basic". An Add-in writes all VB intrinsic controls into an resource file
(with mapping of VB controls to Win32 controls) and additional code modules
load the resource files during runtime and resize and redraw the VB forms
and controls due to the information from the resource file.
But this tool fails in two ways with my application. It would be fine to
have the source code to fix a bug and enhance it to support UniToolbox
controls. I asked the author by mail but he didn't answer.
Is the source code of TsiWin32Dialog.dll public available any where?
Does anyone know another tool with this functionality?
Thank you for any help.
Klaus
J French
I am going to suggest something else, it is the method that I have
used (originally a long time ago) and recommended to other people, but
also one that I've seen in commercial shareware.
Initially code in your local language, but 'front' every string
assignment to captions etc with a function called 'Lex'
eg: Command1.Caption = Lex( "EXIT" )
That function burrows off into a sort of INI file and either gets the
translation (if present) or adds itself to the list of phrases in the
INI file. (Let us call these 'INI' files .LNG files)
Your translators can then edit the pseudo INI file, and check what
they have done.
You could then distribute .Lng files with your App, bury them in the
EXE as resource strings or do as I would do, append them to the end of
the EXE
A particularly nice touch is to put a simple editing facility within
the App, with a 'flip language' and 'refresh' button that only turns
up when the App is in Translation Mode.
Unless one has a truly vast number of string constants, the overhead
is pretty trivial (it was not even a problem under DOS where one had
well under 640kb to play with)
The performance hit will be better than burrowing off to resource
files for everything, and if you don't do that then you'll be getting
everything from just one big resouce string anyway.
Another advantage is that you will be able to understand your own
code, since you will be programming in your native language.
Control sizing problems, can be left to your ingenuity, one can always
enhance a very simple concept.
HTH