[ros-dev] regression on 2nd stage setup

[Timo Kreuzer]

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