Since a few days I noticed that you can't use TAB anymore to cycle through controls. I noticed that when using Forte Agent, because I can't use the keyboard to switch from To: to Subject and so on. Any ideas what has been changed?
On Sat, 17 May 2003 23:05:17 +0200, you wrote:
Since a few days I noticed that you can't use TAB anymore to cycle through controls. I noticed that when using Forte Agent, because I can't use the keyboard to switch from To: to Subject and so on. Any ideas what has been changed?
Vitaliy's edit patch again. Vitaliy: here is another case where windows does not return the DLGC_WANTMESSAGE flag.
Changelog: controls/ : edit.c revert the WM_GETDLGCODE handling patch completely this time. It breaks too much.
Rein.
I am looking into it. It looks odd, but windows, at least Win2k, does return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE always! But there is something more going on here. Windows checks for wParam, and if it's not null adds 0x4 to some window/class flag. If this flag is set, control does not react to [ENTER].
I'm trying to find out what this flag is and what wParam is, since it is "currently unused" according to MSDN.
Here is a part of code from windows:
if (wParam) wnd[0x62] |= 0x4; return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE;
Vitaliy Margolen
Sunday, May 18, 2003, 5:12:32, Vitaliy Margolen wrote:
On Sat, 17 May 2003 23:05:17 +0200, you wrote:
Since a few days I noticed that you can't use TAB anymore to cycle through controls. I noticed that when using Forte Agent, because I can't use the keyboard to switch from To: to Subject and so on. Any ideas what has been changed?
Vitaliy's edit patch again. Vitaliy: here is another case where windows does not return the DLGC_WANTMESSAGE flag.
Changelog: controls/ : edit.c revert the WM_GETDLGCODE handling patch completely this time. It breaks too much.
Rein.
On Sun, 18 May 2003 11:54:36 -0600, you wrote:
I am looking into it. It looks odd, but windows, at least Win2k, does return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE always!
Uhh, this is the output of spy++ under win2000, which corresponds to the broken TAB response in Agent:
| <00201> 00030218 P WM_KEYDOWN nVirtKey:VK_TAB cRepeat:1 ScanCode:0F fExtended:0 fAltDown:0 fRepeat:0 fUp:0 [wParam:00000009 lParam:000F0001 time:4:47:52.206] | <00202> 00030218 S ..................WM_GETDLGCODE wParam:00000009 lParam:0012F434 | <00203> 00030218 R ..................WM_GETDLGCODE fuDlgCode:DLGC_WANTARROWS | DLGC_HASSETSEL | DLGC_WANTCHARS [lResult:00000089]
(00030218 is the hwnd of the editcontrol). In my previous email there where two other examples where windows did not return the DLGC_WANTMESSAGE flag. If I did not mention it then: that was with Win2K.
But there is something more going on here. Windows checks for wParam, and if it's not null adds 0x4 to some window/class flag. If this flag is set, control does not react to [ENTER].
I'm trying to find out what this flag is and what wParam is, since it is "currently unused" according to MSDN.
Here is a part of code from windows:
if (wParam) wnd[0x62] |= 0x4; return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE;
Nice for a parameter that is not supposed to be used ;-) Anyway I see that two of my cases have a non NULL wparam , but still don't return DLGC_WANTMESSAGE.
Perhaps you can put a small example on the net that is giving you the problems?
Rein.
Ok, how about this: 77e492b5 837d1800 cmp dword ptr [ebp+0x18],0x0 77e492b9 7407 jz user32!MLEditWndProc+0x223 (77e492c2) 77e492bb 8b450c mov eax,[ebp+0xc] 77e492be 80486204 or byte ptr [eax+0x62],0x4 77e492c2 b88d000000 mov eax,0x8d ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 77e492c7 e9fa09ffff jmp user32!MLEditWndProc+0x6c6 (77e39cc6)
This is part of the EditWndProc from w2k. I'm not saying you are wrong. We both wrong and M$ right :-)
BTW What application is not working? I tested TAB on number of programs I have (word, excel, custom DB app) and TAB working in all of them. :-O
Here is a simple program which with only one edit and a button. Edit should capture both {Return] & [Tab]. Sorry for the size - that's the smallest I could make it. http://www.kievinfo.com/MemoTest.exe
Sunday, May 18, 2003, 12:46:11 PM, you wrote:
On Sun, 18 May 2003 11:54:36 -0600, you wrote:
I am looking into it. It looks odd, but windows, at least Win2k, does return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE always!
Uhh, this is the output of spy++ under win2000, which corresponds to the broken TAB response in Agent:
| <00201> 00030218 P WM_KEYDOWN nVirtKey:VK_TAB cRepeat:1 ScanCode:0F fExtended:0 fAltDown:0 fRepeat:0 fUp:0 [wParam:00000009 lParam:000F0001 time:4:47:52.206] | <00202> 00030218 S ..................WM_GETDLGCODE wParam:00000009 lParam:0012F434 | <00203> 00030218 R ..................WM_GETDLGCODE fuDlgCode:DLGC_WANTARROWS | DLGC_HASSETSEL | DLGC_WANTCHARS [lResult:00000089]
(00030218 is the hwnd of the editcontrol). In my previous email there where two other examples where windows did not return the DLGC_WANTMESSAGE flag. If I did not mention it then: that was with Win2K.
But there is something more going on here. Windows checks for wParam, and if it's not null adds 0x4 to some window/class flag. If this flag is set, control does not react to [ENTER].
I'm trying to find out what this flag is and what wParam is, since it is "currently unused" according to MSDN.
Here is a part of code from windows:
if (wParam) wnd[0x62] |= 0x4; return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE;
Nice for a parameter that is not supposed to be used ;-) Anyway I see that two of my cases have a non NULL wparam , but still don't return DLGC_WANTMESSAGE.
Perhaps you can put a small example on the net that is giving you the problems?
Rein.
On Sun, 2003-05-18 at 22:29, Vitaliy Margolen wrote:
Ok, how about this: 77e492b5 837d1800 cmp dword ptr [ebp+0x18],0x0 77e492b9 7407 jz user32!MLEditWndProc+0x223 (77e492c2) 77e492bb 8b450c mov eax,[ebp+0xc] 77e492be 80486204 or byte ptr [eax+0x62],0x4 77e492c2 b88d000000 mov eax,0x8d ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 77e492c7 e9fa09ffff jmp user32!MLEditWndProc+0x6c6 (77e39cc6)
This is part of the EditWndProc from w2k. I'm not saying you are wrong. We both wrong and M$ right :-)
BTW What application is not working? I tested TAB on number of programs I have (word, excel, custom DB app) and TAB working in all of them. :-O
here is a little bug report:
Vitaliy, with your patch it breaks emule, In the search edit box (where you type what you're looking for) if you press enter, emule think it has been pressed twice. Without your patch it was ok
Here is a simple program which with only one edit and a button. Edit should capture both {Return] & [Tab]. Sorry for the size - that's the smallest I could make it. http://www.kievinfo.com/MemoTest.exe
Sunday, May 18, 2003, 12:46:11 PM, you wrote:
On Sun, 18 May 2003 11:54:36 -0600, you wrote:
I am looking into it. It looks odd, but windows, at least Win2k, does return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE always!
Uhh, this is the output of spy++ under win2000, which corresponds to the broken TAB response in Agent:
| <00201> 00030218 P WM_KEYDOWN nVirtKey:VK_TAB cRepeat:1 ScanCode:0F fExtended:0 fAltDown:0 fRepeat:0 fUp:0 [wParam:00000009 lParam:000F0001 time:4:47:52.206] | <00202> 00030218 S ..................WM_GETDLGCODE wParam:00000009 lParam:0012F434 | <00203> 00030218 R ..................WM_GETDLGCODE fuDlgCode:DLGC_WANTARROWS | DLGC_HASSETSEL | DLGC_WANTCHARS [lResult:00000089]
(00030218 is the hwnd of the editcontrol). In my previous email there where two other examples where windows did not return the DLGC_WANTMESSAGE flag. If I did not mention it then: that was with Win2K.
But there is something more going on here. Windows checks for wParam, and if it's not null adds 0x4 to some window/class flag. If this flag is set, control does not react to [ENTER].
I'm trying to find out what this flag is and what wParam is, since it is "currently unused" according to MSDN.
Here is a part of code from windows:
if (wParam) wnd[0x62] |= 0x4; return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE;
Nice for a parameter that is not supposed to be used ;-) Anyway I see that two of my cases have a non NULL wparam , but still don't return DLGC_WANTMESSAGE.
Perhaps you can put a small example on the net that is giving you the problems?
Rein.
a+
Max
It looks like some other programs got broke too. This email program I'm using (The Bat) now has some problems with Tabs. Obviously the patch I submited is wrong.
Sunday, May 18, 2003, 3:16:40 PM, you wrote:
On Sun, 2003-05-18 at 22:29, Vitaliy Margolen wrote:
Ok, how about this: 77e492b5 837d1800 cmp dword ptr [ebp+0x18],0x0 77e492b9 7407 jz user32!MLEditWndProc+0x223 (77e492c2) 77e492bb 8b450c mov eax,[ebp+0xc] 77e492be 80486204 or byte ptr [eax+0x62],0x4 77e492c2 b88d000000 mov eax,0x8d ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 77e492c7 e9fa09ffff jmp user32!MLEditWndProc+0x6c6 (77e39cc6)
This is part of the EditWndProc from w2k. I'm not saying you are wrong. We both wrong and M$ right :-)
BTW What application is not working? I tested TAB on number of programs I have (word, excel, custom DB app) and TAB working in all of them. :-O
here is a little bug report:
Vitaliy, with your patch it breaks emule, In the search edit box (where you type what you're looking for) if you press enter, emule think it has been pressed twice. Without your patch it was ok
Here is a simple program which with only one edit and a button. Edit should capture both {Return] & [Tab]. Sorry for the size - that's the smallest I could make it. http://www.kievinfo.com/MemoTest.exe
Sunday, May 18, 2003, 12:46:11 PM, you wrote:
On Sun, 18 May 2003 11:54:36 -0600, you wrote:
I am looking into it. It looks odd, but windows, at least Win2k, does return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE always!
Uhh, this is the output of spy++ under win2000, which corresponds to the broken TAB response in Agent:
| <00201> 00030218 P WM_KEYDOWN nVirtKey:VK_TAB cRepeat:1 ScanCode:0F fExtended:0 fAltDown:0 fRepeat:0 fUp:0 [wParam:00000009 lParam:000F0001 time:4:47:52.206] | <00202> 00030218 S ..................WM_GETDLGCODE wParam:00000009 lParam:0012F434 | <00203> 00030218 R ..................WM_GETDLGCODE fuDlgCode:DLGC_WANTARROWS | DLGC_HASSETSEL | DLGC_WANTCHARS [lResult:00000089]
(00030218 is the hwnd of the editcontrol). In my previous email there where two other examples where windows did not return the DLGC_WANTMESSAGE flag. If I did not mention it then: that was with Win2K.
But there is something more going on here. Windows checks for wParam, and if it's not null adds 0x4 to some window/class flag. If this flag is set, control does not react to [ENTER].
I'm trying to find out what this flag is and what wParam is, since it is "currently unused" according to MSDN.
Here is a part of code from windows:
if (wParam) wnd[0x62] |= 0x4; return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE;
Nice for a parameter that is not supposed to be used ;-) Anyway I see that two of my cases have a non NULL wparam , but still don't return DLGC_WANTMESSAGE.
Perhaps you can put a small example on the net that is giving you the problems?
Rein.
a+
Max
On Sun, May 18, 2003 at 02:29:03PM -0600, Vitaliy Margolen wrote:
Ok, how about this: 77e492b5 837d1800 cmp dword ptr [ebp+0x18],0x0 77e492b9 7407 jz user32!MLEditWndProc+0x223 (77e492c2) 77e492bb 8b450c mov eax,[ebp+0xc] 77e492be 80486204 or byte ptr [eax+0x62],0x4 77e492c2 b88d000000 mov eax,0x8d ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 77e492c7 e9fa09ffff jmp user32!MLEditWndProc+0x6c6 (77e39cc6)
Isn't it a bit dangerous that people who disassemble M$-Code also submit patches to wine?
Ciao Jörg -- Joerg Mayer jmayer@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.
On Sun, 18 May 2003 23:45:12 +0200, Joerg Mayer jmayer@loplof.de wrote:
Isn't it a bit dangerous that people who disassemble M$-Code also submit patches to wine?
I was also curious about that and asked in the newsgroup but I got no really usefull answer so far. In Germany and Austria there shouldn't be a problem with this ( as long as the new EU-Urheberrechtsgesetz is not in force). But it could become a problem in the US and other countries.
Maybe wine should move it's servers to Russia? :)
If you want to be able to really support games then there has to be a lot of work in reverse engineering in order to get the copyprotection in place. Otherwise wine will be only able to run cracked versions.
I was thinking about this too. AS far as Russia's laws go, they de permit reverse engineering for a propose of interoperability when there is not enough information provided. Besides, how else could you find this "undocumented features"? I would even say "completely opposite from what documentation say".
Sunday, May 18, 2003, 3:55:26 PM, you wrote:
On Sun, 18 May 2003 23:45:12 +0200, Joerg Mayer jmayer@loplof.de wrote:
Isn't it a bit dangerous that people who disassemble M$-Code also submit patches to wine?
I was also curious about that and asked in the newsgroup but I got no really usefull answer so far. In Germany and Austria there shouldn't be a problem with this ( as long as the new EU-Urheberrechtsgesetz is not in force). But it could become a problem in the US and other countries.
Maybe wine should move it's servers to Russia? :)
If you want to be able to really support games then there has to be a lot of work in reverse engineering in order to get the copyprotection in place. Otherwise wine will be only able to run cracked versions.
"Vitaliy Margolen" wine-devel@kievinfo.com wrote:
Besides, how else could you find this "undocumented features"? I would even say "completely opposite from what documentation say".
Simply: by writing a test program. If you can't reproduce the targeted behaviour by a test, then it's very unlikely that there is an application that depends on that. Otherwise your efforts are useless.
On Mon, 19 May 2003 08:51:32 +0900, "Dmitry Timoshkov" dmitry@baikal.ru wrote:
Simply: by writing a test program. If you can't reproduce the targeted behaviour by a test, then it's very unlikely that there is an application that depends on that. Otherwise your efforts are useless.
But this works only for functions that are undeocumented. How can you write a test program for a function that is nowhere documented? You wouldn even know about it untill a programm breaks because it requires it and then you have to do some reverese engineering for that. At least in the application to determine what it expects from the function.
"Gerhard W. Gruber" sparhawk@gmx.at wrote:
Simply: by writing a test program. If you can't reproduce the targeted behaviour by a test, then it's very unlikely that there is an application that depends on that. Otherwise your efforts are useless.
But this works only for functions that are undeocumented. How can you write a test program for a function that is nowhere documented? You wouldn even know about it untill a programm breaks because it requires it and then you have to do some reverese engineering for that. At least in the application to determine what it expects from the function.
First of all we were talking about not documented functionality, not functions. This clearly can be done with a test application. One of the regression testing framework primary goal is to test for that kind of things as well.
With undocumented functions I'd primarily rely on the documentation found on the net, next - inspecting Wine relay traces with a native dll, and only as a latest resort - look at the disassembly (in the countries where this isn't prohibitted).
Isn't it a bit dangerous that people who disassemble M$-Code also submit patches to wine?
IANAL but I don't think so, as Vitaliy isn't taking code, it's simply being used to ensure compatability. No copyright is being broken here.
On the other hand, too late now if it is :D keep on truckin' -mike
On Sun, 18 May 2003 14:29:03 -0600, you wrote:
BTW What application is not working? I tested TAB on number of programs I have (word, excel, custom DB app) and TAB working in all of them. :-O
Forte Agent newsreader, about every dialog including the messsage compose window suffers from this.
Rein.
On Sun, 18 May 2003 11:54:36 -0600, you wrote:
I am looking into it. It looks odd, but windows, at least Win2k, does return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE always! But there is something more going on here. Windows checks for wParam, and if it's not null adds 0x4 to some window/class flag. If this flag is set, control does not react to [ENTER].
I'm trying to find out what this flag is and what wParam is, since it is "currently unused" according to MSDN.
Here is a part of code from windows:
if (wParam) wnd[0x62] |= 0x4; return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE;
OK, I looked at it now, tried your example program and did some tests. What you say is more or less true, but only for a multiline edit control. Since our EditWndProc is called for both single as multiline edit controls we must test for it. This patch fixes your example and doesn't seem to affect my programs. What do you think?
Changelog: controls/ : edit.c A WM_GETDLGCODE message always returns the DLGC_WANTMESSAGE flag for multi-line edit controls.
Rein.
This one does the trick! Interesting enough I had the same thing in my tree. I was just running different apps to see if it still works before submitting the patch.
Only one last question remains "What wParam is doing there? And what that other flag does?" When that flag is set, edit control does not react to [enter]. At the same time [enter] is not making it to the default button. So I guess we'll see what's gonna break after this patch will make it into the CVS tree. :-)
Vitaliy Margolen
Wednesday, May 21, 2003, 10:59:14, Vitaliy Margolen wrote:
On Sun, 18 May 2003 11:54:36 -0600, you wrote:
I am looking into it. It looks odd, but windows, at least Win2k, does return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE always! But there is something more going on here. Windows checks for wParam, and if it's not null adds 0x4 to some window/class flag. If this flag is set, control does not react to [ENTER].
I'm trying to find out what this flag is and what wParam is, since it is "currently unused" according to MSDN.
Here is a part of code from windows:
if (wParam) wnd[0x62] |= 0x4; return DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_WANTMESSAGE;
OK, I looked at it now, tried your example program and did some tests. What you say is more or less true, but only for a multiline edit control. Since our EditWndProc is called for both single as multiline edit controls we must test for it. This patch fixes your example and doesn't seem to affect my programs. What do you think?
Changelog: controls/ : edit.c A WM_GETDLGCODE message always returns the DLGC_WANTMESSAGE flag for multi-line edit controls.
Rein.
On Wed, 21 May 2003 19:04:05 -0600, you wrote:
This one does the trick! Interesting enough I had the same thing in my tree. I was just running different apps to see if it still works before submitting the patch.
Only one last question remains "What wParam is doing there? And what that other flag does?" When that flag is set, edit control does not react to [enter]. At the same time [enter] is not making it to the default button.
I would not worry too much about this. We are not trying to make identical code as Windows, we are trying to build the functionality that windows applications require. For all we know, such piece of code might be a leftover from Windows 1.0, that has been left in because also Microsoft did not know what it would break if removed.
So I guess we'll see what's gonna break after this patch will make it into the CVS tree. :-)
That is the perfect chance to put undocumented functionality in: find an application that needs it, understand what and why, think out a solution and implement it.
Rein.
On Wed, 21 May 2003 19:04:05 -0600, Vitaliy Margolen wine-patch@kievinfo.com wrote:
Only one last question remains "What wParam is doing there? And what that other flag does?" When that flag is set, edit control does not react to [enter]. At the same time [enter] is not making it to the default button. So I guess we'll see what's gonna break
Could it be that it sets the control to Multiline? This would be one of the types of control where it doesn't make sense to intercept [enter] and interpret it as a key instead.
-
Dmitry Timoshkov -
Gerhard W. Gruber -
Joerg Mayer -
Maxime Bellengé -
Mike Hearn -
Rein Klazes -
Vitaliy Margolen -
Vitaliy Margolen