[Lazarus] Win32 API replacement calls

[SteveG]

Hello lazarus,

I had attached a patch against current win32callback.inc file. This
patch removes non needed SetWindowPos calls when no StayOnTop windows
are present in the application. Currently when APPACTIVATE is being
received to deactivate the window, all StayOnTop windows are converted
to regular windows and then the next window (other application) if
manually set to top of ZOrder.

When the application is being activated StayOnTop flags are being
restored and window application moved to top of ZOrder.

This shake in windows order finally becomes my WinXP a bit crazy and
finally the windows opened after lazarus or your application start to
bring to second position in ZOrder other windows, so an example, if
you have windows 1, 2 and 3 in the stack and you activate the window
2, the new expected stack is 1,3,2 but you end up with 3,1,2.

This patch removes mostly this problem but other calls to SetWindowPos
in other places are bringing the same stack problems, but much later.
Also the patch removes the strange effect when application is being
deactivated clicking in another window, as visually you will see
(specially in slow computers) the window deactivates, activate again
and finally deactivates.

I was unable to see any possible side effect of this patch as when
StayOnTop windows are present behaviour changes to work as before the
patch.

I wish to talk with the Win32 interface maintainer in order to find a
way to remove or change the other SetWindowPos calls that affect
ZOrder to completly prevent this behavior.

PS: Is the remove of StayOnTop flags expected ? StayOnTop flags in
windows is desktop wide, so a deactivated application with StayOnTop
should keep its StayOnTop windows on top, or maybe I'm wrong ?

-- 
Best regards,
 JoshyFun
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32callback.inc.diff
Type: application/octet-stream
Size: 1485 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20080611/d298d4e2/attachment-0007.obj>