Subject: Re: GNU-WIN/32 on international versions of Windows
From: [email-masked] (Neil Readshaw)

6 Nov 1996 16:50:16 -0800
Sender: [email-masked]
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
References: <[email-masked]>
Reply-To: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0Gold (WinNT; I)
Original-To: Colin Peters <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked],
        [email-masked]
Original-Sender: [email-masked]

Colin,

Thanks for your reply, and have tried a few more things, to no avail.
Perhaps the next installment in this saga will give somebody
inspiration...

Neil.

Colin Peters wrote:
> 
> This is a guess (with perhaps some basis in fact): Maybe it's rcl.
> 
> Maybe rcl reads in your resource script and converts your strings into
> wide character equivalents (which it has to do if those files are in
> ASCII, because resource strings are UNICODE under Win32). This is good,
> but maybe it also does that to strings which are already wide character
> strings... confirm or deny Gunther?
> 
> I don't know how the "big guys" resource compilers deal with this problem.
> Unless there is some way inside the resource script of identifying the
> encoding of the strings the only thing the resource compiler can do is
> guess. Rcl, I think, guesses ASCII.

I don't see how it could be RCL, for these two reasons:

1) The text strings to be displayed in the dialog box are not kept
inside
   the resource script.  Instead, we read them from a file, and then use
   SetDlgItemText to update the resource in the dialog box.
2) I use the Microsoft Visual C++ resource compiler to generate a .RES,
   and then use rcl to put the resources into the PE format executable
   file.

I am confused though, since I thought that when we called a Windows 
API function from the GNU program, the parameters are placed on the
stack as normal, and then we call the call-gate function for the API,
which just does a jump to the real function in the appropriate, since 
it is only mapped into the address space of the application at run time.

I even tried doing a MultiByteToWideChar conversion of the offending
string before I called SetDlgItemText, but it made no improvement.  In
fact, it didn't even work on a US version of NT.  The API definition in
the Microsoft help says that SetDlgItemText takes a Microsoft TCHAR,
which is either a CHAR or WCHAR, depending on the OS being run on (CHAR
for '95, WCHAR for NT).

Another thing that I tried was to make the dialog resources explicitly
Japanese, by setting them as this language via the Microsoft development
environment.  I actually had to install another code page on my system
to do this, but the Microsoft Help was quite useful in this area.  This
also made no difference at all.

Another thing that puzzles me is that if I send other text to a GUI 
window, eg via MessageBox, or use SetWindowText to change the title of
a window, including the same window where SetDlgItemText does not
work, then there is success.  Also, DrawText works in a Window.

I am wondering now why it is only the SetDlgItemText call, or 
SetWindowText to a component of a dialog that is the problem.  What
does Gunther's RCL do when just adding resources to an executable.

Any comments ?

-- 
------------------------------------------------------------------------
Neil Readshaw                                Phone: +1 408 457 4510
DASCOM Inc.                                  Fax:   +1 408 457 0710
1509 Seabright Avenue                        Email: [email-masked]
Santa Cruz CA 95062                          WWW: http://www.dascom.com/
------------------------------------------------------------------------
-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".