1

I have seen a few postings that are similar to this question, but this has a subtle difference. I have a program, the user interface of which can sit behind other programs, but it has a child form that is displayed in the top left corner that displays results, this part of the monitor is duplicated and is displayed to the public, it is a "scoreboard". I want this "results" form to sit on top of everything (Taskmanager is OK, I can live with that). Any other applications that would be run will not be trying to climb to the top, eg "Word", "IE", "Excel" etc.

If I set the parent "SetWindowPos" to "TopMost" and the child also to "TopMost", both of my windows are on top, however, the user interface form also sits over anything. If the user needs to start another application, our form will sit over it, making the other application unusable, however, it will sit under our results form. We cannot use a timer to move it to the top as it will be covered until the timer fires, this is not allowed to happen.

If I only set the results form to topmost, it does not stay at the top of everything. It appears that the parent must also be topmost? Is there a way of getting around this and make the child on top, but its parent can sit below? Or does the parent have to be topmost in order to have children also topmost? The parent can not sit over the child as I grab the move event and prevent it moving over the child.

I am programming in Delphi, so any answers would be best in Delphi, but anything more generic is quite ok, I expect it would be a call to Windows anyway.

Thanks

TrevorH
  • 49
  • 4
  • *Any other applications that would be run will not be trying to climb to the top* - You can't reliably enforce this because of the [What if Two Programs did this - rule](http://blogs.msdn.com/b/oldnewthing/archive/2011/03/10/10138969.aspx) – Lieven Keersmaekers Nov 09 '15 at 07:38
  • Thanks for your thought, as I indicated in Tom's posting, this is in fact the case after some testing of his suggestion. Even though the "two programs" are in fact ours, co-ordinating their "on top" status will require more thought. – TrevorH Nov 11 '15 at 21:11

1 Answers1

2

If I understand you correctly, your program has a main form (MainForm) and a results form (ResultsForm) and probably some other ones too, but those should 'behave' normally.

The MainForm should also behave normally, that is, move to the background if other applications are activated but the ResultsForm should always stay on top of all other forms, also those of other applications.

The following is tested in Windows 7 only, so may or may not work with other OS's. I will later today test with Windows 10.

First outcomment any previous attempts that might interfere. Leave MainForm.FormStyle as the default fsNormal. Set ResultsForm.FormStyle to fsStayOnTop.

Then add a TApplicationEvents to ResultsForm and add an event handler for OnDeactivate:

procedure TResultsForm.ApplicationEvents1Deactivate(Sender: TObject);
begin
  SetForegroundWindow(Handle);
end;

The ResultsForm will now stay on top of other windows, also of other applications.

Caveat: If you start a second instance (or if some other application is doing the same trick) you will end up in a loop where the apps are fighting for being on top.

Tom Brunberg
  • 20,312
  • 8
  • 37
  • 54
  • Yes, your understanding is correct! I tried it this morning, but realised a "problem" that I hadn't realised, as in your caveat. We DO have other apps that may be fighting. When a score is made, eg. cricket a 6 is scored, we display a video on top of the results form. So I would have to allow this form to come "more" to the front! But still leave the results on top of everything else. When the video finishes, its form will close and the results will need to be "on top" again. So the handling of "on top" is already looking harder than I thought. – TrevorH Nov 11 '15 at 21:07
  • @Trevor Heh, I'm not surprised ;) But the good thing is that it is only your applications that might fight for the screen, so you can create a screen police that disables some 'onTop' and allows another one. To temporarily disable, just nil the `OnDeactivate` event and reset again later. – Tom Brunberg Nov 11 '15 at 21:25