Hello,

I really need to create forms that stay on top of all other windows (yes, even other applications), but using fsStayOnTop doesn't work (there are a number of bugs about it but the situation isn't clear to me).

I found a couple of delphi suggestions (btw, on my old delphi 2.0 fsStayOnTop works fine, so I wouldn't need any of this):

1) SetWindowPos with HWND_TOPMOST
2) overriding CreateParams as suggested here
http://delphi.about.com/od/formsdialogs/l/aa073101b.htm

procedure TForm1.CreateParams(var Params: TCreateParams);
begin
   inherited CreateParams(Params);
   with Params do begin
     ExStyle := ExStyle or WS_EX_TOPMOST;
     WndParent := GetDesktopwindow;
   end;
end;

None of this works with lazarus. I saw that the only widgetset where fsStayOnTop is qt under linux, but this application needs to be a win32 one. Any suggestion on how to achieve that?

Bye

[skip]

None of this works with lazarus. I saw that the only widgetset where fsStayOnTop is qt under linux, but this application needs to be a win32 one. Any suggestion on how to achieve that?

There was bug reports about StayOnTop forms before that they must not stay on top if another application is active. That was implemented in the win32 widgetset. Now you complain because of that :) Who is right? Delphi 7 at least behave the same - it hides StayOnTop forms when application deactivates.

Maybe we need to rewrite that this piece of code and more generic solution that can satisfy both camps needs to be found. I will try to look at this problem soon.

Best regards,
Paul Ishenin.

En/na Paul Ishenin ha escrit:

Yes, I saw the bug reports, I don't know who is right or wrong, but now I just need the form to stay on top ;-) (I will spawn my app from another one when the user clicks a button, and the forms created by my application need to be visible even if the user clicks again on the other one).

Maybe we need to rewrite that this piece of code and more generic solution that can satisfy both camps needs to be found. I will try to look at this problem soon.

For the time being it'd be enough for me to know if there's an hack I can implement in my application without messing with the lcl. Thank you.

Bye

I have a little application written in Delphi which will stay on top of my web browser to give me a count down time for ebay auctions!

I think that the correct behaviour is that if the main form is fsStayOnTop then the application should stay on top of other applications.

If the main form is not fsStayOnTop then it can be hidden by another application which has focus.

Within the application, fsStayOnTop forms just stay top of other forms subject to my comment in this bug report
http://bugs.freepascal.org/view.php?id=11977

regards
Leslie

Do you believe this is easy logic and will be understanded by all application developers and their users? I think if we will have an ability to select whether forms will overlap other application or not we will implement it in a more clear way.

Best regards,
Paul Ishenin.

Hi,

I really need to create forms that stay on top of all other windows (yes, even other applications), but using fsStayOnTop doesn't work (there are a number of bugs about it but the situation isn't clear to me).

It recalls me what Raymond Chen ( http://blogs.msdn.com/oldnewthing ) said about that :

<Quote>
"How do I create a window that is never covered by any other windows, not even other topmost windows?"
Imagine if this were possible and imagine if two programs did this. Program A creates a window that is "super-topmost" and so does Program B. Now the user drags the two windows so that they overlap. What happens? You've created yourself a logical impossibility. One of those two windows must be above the other, contradicting the imaginary "super-topmost" feature.
</Quote>

The whole blog post is at
http://blogs.msdn.com/oldnewthing/archive/2005/06/07/426294.aspx and it is worth the reading.

Best regards.

En/na Inoussa OUEDRAOGO ha escrit:

Very funny, but it's not the case at hand: I just need the windows of my application to always stay on top to the windows of another application. I can do it in delphi and lazarus/qt, I just need a hack to do the same under win32.

Bye

2009/1/28 Luca Olivetti :

so what happens if the other application wants to be on top of yours?

henry

Hello Paul,

Wednesday, January 28, 2009, 10:01:39 AM, you wrote:

PI> the win32 widgetset. Now you complain because of that :) Who is right? PI> Delphi 7 at least behave the same - it hides StayOnTop forms when PI> application deactivates.

No, Delphi 7 keeps StayOnTop windows on top always (it simply sets the HWND_TOPMOST attribute to the window).

I think that there is a confusion about the StayOnTop and the "float over same application forms" options. The "float" one was added in Delphi 2005 (I think) but I can not recall the name.

PI> Maybe we need to rewrite that this piece of code and more generic PI> solution that can satisfy both camps needs to be found. I will try to PI> look at this problem soon.

Current implementation drives crazy the Windows window manager and "corrupts" the internal win windows stack, in fact I had removed that code from my own LCL compilation to avoid such problems.

The buggy effect is that when you have in example 3 windows stacked as 1, 2, 3 and you click in "2", "2" comes to front (as expected) but the new stack order is 2, 3, 1 instead 2, 1, 3 (which is the expected).

Calls to setwindowlong when application is being activated or deactivated seems to become windows crazy.

Hello Henry,

Wednesday, January 28, 2009, 5:10:47 PM, you wrote:

HV> so what happens if the other application wants to be on top of yours?

In Windows at least, topmost windows are implemented as a second windows layer, one for normal windows and other for topmost ones. If you have 2 topmost windows they work as the same as normal ones but always over the normal ones (not much clear?) :)

"logical impossibility"... in the case described above, logic dictates that neither window could overlap the other... so, if one window is dragged "over" the other, once released, it should "move" off of the other one toward the side(s) of itself with the largest area(s) not "over" the other window... when positioning, it should be possible to drag "under/over" or "through" the other window with the caveat about what would happen on release... this way you don't have to go around the other window if you want to swap positions with it...

it doesn't seem so hard or complicated to me... the actual code, on the other hand, may very well be above my current abilities in this environment ;)

imho Delphi 4 worked the other way around, stayOnTop was always on top. (and I created some programs which depended on that)

Probably the best solution is to create two flags
fsStayOnTop(Application) and fsStayOnTopGlobally.

Benito

That is what Vista is for... see a window through another... so far only the borders shine through, but maybe in Windows 7 MS manages to create fully transparent forms and you can see both super-topmost forms at the same time on the same place.....

But aside the kidding... From my Delphi7 application my customers complained about modal forms not being modal. They dissapeared behind the mainform and the user had the impression the application got frozen. This happened for example with my modal login dialog... it just wasn't visible...
Someone gave me this solution:

1. Make sure you set the dialogs formstyle to fsStayOnTop

In the declaration of the dialog, just above the 'private'section:

   procedure  CreateParams(var Params: TCreateParams); override;
which has:
procedure TdlgLogIn.CreateParams(var Params: TCreateParams);
begin
   inherited;
   Params.WndParent := TWinControl(Owner).handle;
end;

Don't know what it does exactly, but it sure helped! It survives all other applications! ;-) Well, that said, the taskmanager-form seems to use the same strong stayontop...

fwiw!

kind regards,
John

En/na Henry Vermaak ha escrit:

The other application never wants to be on top of mine. Really.

Now I found that SetWindowPos HWND_TOPMOST actually works, but its effect is undone by the LCL.
I tried to call it in a timer every 100ms (yuck, the brute-force approach) but the application (not unsurprisingly) froze. I tried to call it in the Deactivate handler (both the main form and the other forms and it has no effect.
I tried to set a timer on the Deactivate handler to fire SetWindowPos 100ms later and it works....but only once.

Maybe I'll just have to remove the calls to "RemoveStayOnTopFlags" in win32callback.inc and see what happens.

Bye

Hello Luca,

Wednesday, January 28, 2009, 9:42:18 PM, you wrote:

LO> Maybe I'll just have to remove the calls to "RemoveStayOnTopFlags" in LO> win32callback.inc and see what happens.

Look for the lines attached, more or less as my snapshot is one month old and comment such lines as in the file.

Affected file is win32callback.inc

Now you must control the StayOnTop using the HWND_TOPMOST and the setwindowlong.

2009/1/28 Luca Olivetti :

i'm sure he's saying the same about your application :) stay on top is something the window manager should handle, imo.

henry

HV> so what happens if the other application wants to be on top of yours? In Windows at least, topmost windows are implemented as a second windows layer, one for normal windows and other for topmost ones.

Which Windows version(s)?

DoDi

Probably the best solution is to create two flags fsStayOnTop(Application) and fsStayOnTopGlobally.

The first should be a property of Application, not of the forms, so that only one form can be the topmost one.

The second one depends on the capabilities of the OS and widgetset.

DoDi

IMO it makes the dialog a child window of the dialog Owner form. Child windows always stay on top of their parents (modal), as opposed to overlapped windows (modeless).

DoDi

En/na Henry Vermaak ha escrit:

There's no "he". This isn't a general purpose pc, where I'm fighting for screen space with other applications.
This pc will be running just these two apps, and I'm responsible for both, but since the development environment of the other application is not really good (actually it's a POS), I'm trying to offload some of the development to lazarus, so that when the user clicks on a button in the other app, it will spawn a lazarus app that should stay on top (because the user can click on the previous app to open another lazarus window and so on and so forth).

Bye

En/na JoshyFun ha escrit:

Affected file is win32callback.inc

Thanks, that was exactly what I had in mind. It works beautifully.

Now you must control the StayOnTop using the HWND_TOPMOST and the setwindowlong.

Setting fsStayOnTop seems to be enough.

Bye

Hello Hans-Peter,

you wrote

> HV> so what happens if the other application wants to be on top of yours? > > In Windows at least, topmost windows are implemented as a second > windows layer, one for normal windows and other for topmost ones.

HPD> Which Windows version(s)?

AFAIK all Windows versions.