Stay-on-top for just our app?

[Tom F 83]

Has anyone here have any experience making stay on top forms NOT be on top of other apps?

An approach was blogged about in 2004 (blog link, download link). (Thanks, twm)

We'd LOVE to have our stay-on-top forms stay on top of our app, but NOT stay on top of other apps. But, we're nervous using the code this post links to, because we don't know enough to determine its quality and safety.

I'm interested to hear how YOU are dealing with this if you are.

 

 

REPLY

 



 

[Dennis07 1]

This should happen by default if you are using the latest version of Delphi. What version are you using?

[David Schwartz 426]

D10.2.3 does this by default, as Dennis07 says. Rather a PITA for my present needs.

Edited November 19, 2018 by David Schwartz

[Tom F 83]

David,

 

I’m aware that Delphi is supposed to do that. 

 

My my problem is that with our 50,000-line current Delphi app it doesn’t. 

[David Heffernan 2345]

What you are looking for is the default behaviour. Clearly there is something in your code that changes this.

 

The solution is not to ask for some new code to make this work for you. The solution is for you to remove or fix whatever it is in your code that has broken this behaviour.

 

Start a brand new VCL app.  This will come with a main form.  Create a second form, and show it.  Note how the second form can never be behind the main form.

[Tom F 83]

Quote

The solution is not to ask for some new code to make this work for you. The solution is for you to remove or fix whatever it is in your code that has broken this behaviour.

Thank you all for your suggestions and feedback.

I am aware that my application is not performing as expected and that the VCL should handle this properly.  A small sample program, as was suggested, works fine.

I was not asking for new code. I was asking for suggestions on what I might be doing wrong.  My apologies if I didn't make that clear in my OP.

I'm running the current Tokyo 10.3 Update 3.  My app is 45,000 LOC, so it's difficult to scale back to a small test program.

fsStayOnTop works fine inside my app, but often times the on top forms are on top of other apps that I bring to the front.

See the attached video. Interestingly, as seen in the video, it seems that every other time I cover it with another app it burns through in front of them.

The on top forms are created with their parent form in the TForm.Create() statement.

Any suggestions on how to diagnose this?

 

[David Heffernan 2345]

Scale it back to a small test program. As for what's wrong, the thing that keeps the window on top is the window owner property. In VCL that's known as popup parent.

 

I know you want a quick answer but sometimes you have to work a bit. Make that minimal test program and the answer will be easy to find. 

[Marco Cantu 78]

AFAIK, StayOnTop works differently from a primary windows or a secondary one, the VCL calls different APIs in different scenarios -- stay on top of everything else or stay on top of other forms of the same app. Worse case scenario, you can still call SetWindowsPos....

[Lars Fosdal 1792]

You can also consider handling the application wide WM_ACTIVATEAPP where WParam = 0 when you lose focus  and 1 when you get focus- and then explicitly hide/restore your floating forms.

[Attila Kovacs 629]

Look at your video and see how the focus is changing on your application meanwhile you minimize/restore the "other" application.

Your SOT (stay on top) window has the initial focus, then your mainform then your SOT again etc.. etc...

 

The same happens at me (Berlin U2), however it will always stay behind the "other" app, but my SOT form comes behind its parent every other time when the "other" app is in the foreground.

 

Now, adding this code to the test app makes it behave every time the same, the SOT form is sent to the back, to the very back, and on activating to the foreground:

 

(I've no clue if hwnd 0 is the correct value to mark it as empty, but you can introduce a boolean for it)

 

It's hard to say more because I can't reproduce it, but it reminds me to the ancient "modal window behind it's parent window" malfunction, which was resolved by @Gert Scholten by setting the popupparent for the modal window.

 

Let me know if you found out something.

 

Btw, is this some Inductively coupled plasma spectroscope?

 

var
  Form1: TForm1;
  actvfrmhdl: HWND;

implementation

{$R *.dfm}

uses
  Unit2;

procedure TForm1.ac(Sender: TObject);
begin
  if actvfrmhdl <> 0 then
    SetActiveWindow(actvfrmhdl);
end;

procedure TForm1.da(Sender: TObject);
begin
  actvfrmhdl := Screen.ActiveForm.Handle;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  actvfrmhdl := 0;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  form2.show;
  application.OnDeactivate := da;
  application.OnActivate := ac;
end;

 

Edited November 20, 2018 by Attila Kovacs

[Tom F 83]

I have determined that this problem is being caused by DisplayFusion, a wonderful program to handle multiple monitors and multiple task bars. 

If I disable DisplayFusion from adding title bar icons to any application, (these are buttons that allow one to easily move a window to another monitor), the problem goes away.

I have contacted them for support.

I have been using this program for many years and really value the various screen management tools it provides, especially title bar buttons and a task bar on each monitor that shows only the apps that are running on that monitor.

I'd hate to not have the DisplayFusion tools available (and frankly would probably to use it even with the nuisance of non-modal windows burning through in the debugger), so I'm really hoping they will come up with a fix.

Thanks to everyone here for their support and suggestions.