GreatLord told me about a regression that might be caused by one of my patches. In fact it was two patches working together:
1.) 25410, win32k: Make NtUserSetFocus accept NULL window. This patch is correct. Win XP behaves the same way.
2.) 25412, user32.dll: remove focus from window, when it gets disabled I have tested this and compared results to XP, I am sure it works the same on XP. On XP when you disable a control you will hear a sound when trying to use tab / arrow keys after that. Focus is not moved to another control.
The regression coming from those patches is that on 2nd stage setup keyboard focus is removed from the Back/Next buttons. I found one problem in comctl32: When using PropSheet_SetWizButtons() the appropriate button will be set as defpushbutton, but not recieve focus. This can be corrected with a small patch, wich would solve most of the regression. But it introduces another bug: On 2nd stage AckPage (2nd page) the focus should be set to username edit control. But it would be set to Next button, even if SetFocus(<usernameeditcontrol>) was called after calling PropSheet_SetWizButtons() So I compiled syssetup as an exe to work on XP and tried to find out how it works on XP. On XP syssetup behaves the way that I think it should. More testing gave me the following result: The propsheet sets the focus automatically to the first editcontrol (maybe other controls, too, didn't test) that was defined in the resource. It is independed from the control ID and position of the control. Only thing that is important is the position at wich the control was defined in the rc file.
So my question: How dows windows know the position of the control inside the resource? Do we have something like that implemented in ROS?
Any help appreaceated.
Another minor thing: XP displays no focus rect (dotted rect on buttons that have focus) until a tab / arrow key was used. Then it stays. It's only a visual enhancement, but it woud be nice to also have this. Does anyone know how win does this?
BTW: Should I patch comctl32 to fix that regression, or send a patch to wine? I also have another patch for the updown control that behaves incorrect with wine code.
And another thing: I first tried to execute syssetup.dll on XP with rundll32 (rundll32.exe syssetup.dll,InstallWizard), but it said it could not find InstallWizard. Can someone tell me why it does not work?
Greetings, Timo
-
Timo Kreuzer