From: readshaw AT cplabs DOT com (Neil Readshaw) Subject: Re: GNU-WIN/32 on international versions of Windows 6 Nov 1996 16:50:16 -0800 Sender: daemon AT cygnus DOT com Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <32811C1C.70A2.cygnus.gnu-win32@dascom.com> References: <199611060828 DOT RAA23346 AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp> Reply-To: readshaw AT cplabs DOT com 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 Original-CC: readshaw AT cplabs DOT com, orre AT nada DOT kth DOT se, gunther DOT ebert AT ixos-leipzig DOT de, gnu-win32 AT cygnus DOT com Original-Sender: owner-gnu-win32 AT cygnus DOT com 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: readshaw AT dascom DOT com Santa Cruz CA 95062 WWW: http://www.dascom.com/ ------------------------------------------------------------------------ - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".