Hi Alexandre,
Any reason this wasn't applied, or is it still in the queue?
On Wed, 2003-03-19 at 14:08, Mike Hearn wrote:
As per Dimis suggestion, here is a more streamlined version of the patch.
ChangeLog:
- Make IsWindowUnicode check dialog wndprocs
Mike Hearn m.hearn@signal.qinetiq.com writes:
Hi Alexandre,
Any reason this wasn't applied, or is it still in the queue?
I'm not sure it's correct for subclassed windows. I'm going to do some tests on Windows.
Alexandre Julliard julliard@winehq.com writes:
Mike Hearn m.hearn@signal.qinetiq.com writes:
Hi Alexandre,
Any reason this wasn't applied, or is it still in the queue?
I'm not sure it's correct for subclassed windows. I'm going to do some tests on Windows.
OK I tested this, and I see no evidence that IsWindowUnicode takes into account the dlgproc under Windows. So I'm afraid the patch is wrong.
OK I tested this, and I see no evidence that IsWindowUnicode takes into account the dlgproc under Windows. So I'm afraid the patch is wrong.
Hmmm. Perhaps then IsWindowUnicode doesn't work in Windows by checking the window proc at all? MSDN doesn't mention such a thing.
Possibly the character set of the window is stored as an extra field in the WND struct, and set manually by the window/dialog creation functions. Would that be an acceptable way to implement this?
Mike Hearn m.hearn@signal.qinetiq.com writes:
Possibly the character set of the window is stored as an extra field in the WND struct, and set manually by the window/dialog creation functions. Would that be an acceptable way to implement this?
No, I think IsWindowUnicode is just fine the way it is. The problem IMO is that dialog windows are always created first as Unicode, even for CreateDialogA. This will need some restructuring of the dialog code.
On 27 Mar 2003, Alexandre Julliard wrote:
No, I think IsWindowUnicode is just fine the way it is. The problem IMO is that dialog windows are always created first as Unicode, even for CreateDialogA.
Interesting. Can you test this assumption on Windows? If we should do that, maybe we should track it as a TODO or a bug, no? Seems pretty important...
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Interesting. Can you test this assumption on Windows? If we should do that, maybe we should track it as a TODO or a bug, no? Seems pretty important...
It's not that important because the message translation will take care of it in most cases, so it's only border cases like IsWindowUnicode that are affected. But yes it's definitely a bug.
No, I think IsWindowUnicode is just fine the way it is. The problem IMO is that dialog windows are always created first as Unicode, even for CreateDialogA. This will need some restructuring of the dialog code.
Do you mean they are created as Unicode first in Windows, or in Wine?
If you mean in Windows, then how do you go about changing the set of a dialog once it's been created? I'm a bit confused as to exactly what we're meant to do with the wndproc for a dialog anyway - set it equal to the dlgproc? I'm not even sure why Windows has two separate fields for this :(
Are there any docs on exactly how Windows manages the character sets of dialogs? If it's on MSDN then I've not encountered it in my travels. Once I understand exactly what has to be done, I'm happy to file a bug and work on it myself, solving this will resolve a lot of irritating buglets, mostly involving preferences dialogs in apps like winamp, IE6, trillian etc.
thanks -mike
Mike Hearn mike@theoretic.com writes:
Do you mean they are created as Unicode first in Windows, or in Wine?
In Wine; since dialog templates are Unicode we always call CreateWindowExW to avoid having to convert the template back to ASCII, but it seems we shouldn't. I'll work on a fix.
If you mean in Windows, then how do you go about changing the set of a dialog once it's been created? I'm a bit confused as to exactly what we're meant to do with the wndproc for a dialog anyway - set it equal to the dlgproc? I'm not even sure why Windows has two separate fields for this :(
The wndproc for a dialog is (usually) set to DefDlgProcA/W, which in turns call the dlgproc. It's a bit confusing I agree...
Hi,
In Wine; since dialog templates are Unicode we always call CreateWindowExW
to
avoid having to convert the template back to ASCII, but it seems we
shouldn't.
I'll work on a fix.
Can you confirm this "bug" also caused all my trouble here? http://www.winehq.com/hypermail/wine-devel/2003/03/0194.html
Thanks, Florian
"Florian Schirmer" jolt@tuxbox.org writes:
Can you confirm this "bug" also caused all my trouble here? http://www.winehq.com/hypermail/wine-devel/2003/03/0194.html
Not really; fixing the dialog issue may well hide the bug, but I think there's another problem here, WM_GETTEXT is supposed to be translated correctly no matter what the type of window is. Could you please generate some more traces, like a +relay,+message?
Can you confirm this "bug" also caused all my trouble here? http://www.winehq.com/hypermail/wine-devel/2003/03/0194.html
Well, can't really confirm without further testing with the app, but it does look quite similar yes. I suppose wait until Alexandre has written a fix then try it again... A<->W crossovers seem to be caused by all sorts of things though, so it might not be the same problem.
Thanks, Florian
-
Alexandre Julliard -
Dimitrie O. Paun -
Florian Schirmer -
Mike Hearn -
Mike Hearn