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 ?

Correct. Can you attach another patch in more usual format which tortoise svn or another svn tool do. I dont understand your format and my tools too.

This needs to be tested in application with StayOnTop forms.

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.

This things needs to be rewriteen in more generic way since not only win32 but other widgetsets should do the same clearing/restoring stayontop on activate/deactivate.

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 ?

Yes, it is expected. 1) Who needs another application windows when he doesnot working with it? 2) This is delphi compatible 3) We have many complains when we did not do so in bug-tracker.

Best regards,
Paul Ishenin.

Hello Paul,

you wrote

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

PI> Correct. Can you attach another patch in more usual format which PI> tortoise svn or another svn tool do. I dont understand your format and PI> my tools too.

I had used the diff.exe present in lazarus bin folder. I can not use Tortoise because svn.lazarus is not rechable using my DSL, it is a common problem with some ISPs. One connect works and the next one will not and wait forever, the behavior is completly random. Since a week ago everything seens to work but I'll wait a few days to verify that everything is fine.

To manually apply the patch simply remove lines starting with "<" and replace them using lines marked with ">". I had attached the same diff using RCS format. Basically it simply check that
WindowsInfo.StayOnTopList have something, if empty it does not apply the SetWindowPos.

> 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. >

PI> This needs to be tested in application with StayOnTop forms.

I had tested it, but please do it too.

PI> This things needs to be rewriteen in more generic way since not only PI> win32 but other widgetsets should do the same clearing/restoring PI> stayontop on activate/deactivate.

To my needs at least (I'm not using stayontop windows) this patch solves 80% of the problems, but there are other SetWindowPos which changes the ZOrder that I think that could be prevented (SWP_NOZORDER) without impact but as I do not know exaclty the purpose of that call I can not verify that everything works as before (apparently works as before).

> 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 ? >

PI> Yes, it is expected. 1) Who needs another application windows when he PI> doesnot working with it? 2) This is delphi compatible 3) We have many PI> complains when we did not do so in bug-tracker.

1) In the past I wrote a little application that uses StayOnTop system wide window as a drop target ;) Of couse it must be visible everytime.
2) Nothing to say :) That's important (never checked against Delphi).
3) he, he, he... sure :)

Have you tried the SVN2 mirror?

I found the main SVN very unreilable too, but never had any problem with svn2. (http://svn2.freepascal.org/svn/lazarus/trunk)

- Leslie -

Quick question: is this related to problem with MessageDlg or ShowMessage called from form shown modally ? I see in latest Lazarus SVN that each time I'm doing it focus is not returned properly to the modally shown form (it looks like a lost focus)

regards
Boguslaw

Hello Boguslaw,

Thursday, June 12, 2008, 6:42:13 PM, you wrote:

BB> Quick question: is this related to problem with MessageDlg or BB> ShowMessage called from form shown modally ? I see in latest Lazarus SVN BB> that each time I'm doing it focus is not returned properly to the BB> modally shown form (it looks like a lost focus)

Not sure, but the patched code was there since a lot of time and my patch has not been applied.

When applied it could have some effect over that situations as it prevent some kind of window stack mix but as far as I know the stack mix is only affecting applications, not windows inside the same application.