Delphi fsStayOnTop oddity

Here is the deal. Main form set to fsNormal. This main form is maximized full screen with a floating toolbar. Toolbar is normal form with style set to fsStayOnTop.

Most fo the time this works as expected. The mainform displays and the toolbar floats over on top of it.

Sometimes (this is a bugger to find a reproducible set of steps) when alt-tabbing to and from other apps (or when clicking the Delphi app icon on the taskbar) the following symptoms can happen:

1. When alt-tabbing away from the Delphi app the floating topmost fsStayOnTop form stays on top of the other app开发者_StackOverflows. So if I alt-tab to Firefox then the floating menu stays on top of Firefox too.

2. When alt-tabbing from another app to the Delphi app the floating menu is not visible (as it is behind the fsNormal mainform).

Is this a known bug or are there any hacks to force it to work? This also seems to happen most when multiple copies of the app are running (they have no interaction between them and should be running in their own windows "sandbox").

It is as if Delphi gets confused which window is meant to be on top and swaps them or changes the floating form to stayontopofeverything mode.

Or have I misunderstood fsStayOnTop? I am assuming setting a form style to fsStayOnTop makes it stay on top of all other forms within the current app and not all windows across other running apps.

---

A bit more info and possible solution.

Set the floatingform to fsnormal.

When the mainform.activate event fires call floatingform.bringtofront.

But I also use stayontop for all of the other app dialogs. When multiple copies of the app are running then the dialogs show the same problem (ie if app1 has a dialog open and is alt-tabbed away from the the dialog may stay on top of all other programs).

---

I don't know of a bug in this area.

Let me first explain how the process works:

Delphi first uses fsStayOnTop style during the creation of the window that holds the form, by invoking win32 function SetWindowPos with HWND_TOPMOST parameter.

See http://msdn.microsoft.com/en-us/library/ms633545(VS.85).aspx for a detailed explanation of SetWindowPos.

Everytime the application is deactivated or minimized, Delphi enumerates all the topmost forms to normalize the forms (normalize is the term that vcl uses to mean that the windows that are topmost are turned to not being topmost) and it keeps an internal list of all of the windows that were topmost at that moment.

Everytime the application is activated or restored, Delphi uses the information stored in the list of topmost windows, to restore all the topmost forms (using setWindowPos with HWND_TOPMOST parameter)

So to me the problems seems to be in the way that Delphi stores the information while enumerating the windows when the application is minimized.

I would hack into the minimize or deactivate function and check if the topmost windows list (it is on Application.FTopMostList) are correctly listed.

---

I had a similar problem and this link help me a lot: Delphi: Balloon Form with fsStayOnTop not working in Win7

When I call the Application.NormalizeTopMosts() function then the topmost forms behave as I expect.