Would anybody know how to ensure a Laz form is brought to top, even if Laz app doesnt currently have focus ?

eg - an alert msg/form to be forced to top/front every x seconds until acknowledged. Needs to be brought to top/front again even if user clicks on window behind and covers it.

An external app (console run) would do if no code is known.

Using Kubuntu 9.04 -

Thanks - SteveG

AForm.BringToFront ?

Best regards,
Paul Ishenin.

On windows, BringToFront will make the title of the program flashes on the taskbar.

Ant?nio

2009/10/29 Paul Ishenin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20091029/44ed7a07/attachment.html>

I have tried all (I think) permutations of Form.BringToFront / OnTop / MakeVisible / etc I can find.
It would seem under KDE (at least) if your app doesnt have focus, your forms dont pull to front on standard commands ?
Even under Windows I needed to call the API directly to help out here - just dont know how to do the same with linux

2009/10/29 SteveG :

Which widgetset? It may depend on your window manager, but for gtk something like gtk_window_present() should work. Don't know about Qt. XRaiseWindow should do the job for all widgetsets, but that's more work.

Henry

SteveG wrote

eg - an alert msg/form to be forced to top/front every x seconds until acknowledged. Needs to be brought to top/front again even if user clicks on

On a side note:
Be warned, users HATE that! It would drive me nuts as well.

2009/10/29 Graeme Geldenhuys :

Definitely. It's considered a Very Bad Thing and you'd probably also find that sane window managers prevent other applications from stealing the focus. Rather use the notification area for this (I think there's a standard interface for it).

Henry

Have to agree with both here :)
but in this case I have to override as its a dedicated touchscreen app, and anything I have to say is important :)

Problems occur with touchscreens (especially when mobile) of multiple taps hiding things you dont even know happened.

Being an embedded app system, the taskbar/notification area's are fully hidden
- no fiddling fingers allowed.

The apps I am 'overriding' are also under my control, but are having issues deciding whos boss when I need an alert message shown from a non-focused 'watchdog' app

AFAIR on Windows it's IMO a matter of configuration, whether an application can "steal the focus". Does your OS have a similar option?

DoDi

I will do a bit of research on this - still much to learn regarding linux Thanks

SteveG wrote

I will do a bit of research on this - still much to learn regarding linux Thanks

A window which should not be influenced by the window manager must have the override_redirect attribute set on X. MSEgui has tmseform.optionswindow wo_popup for that purpose. I assume Lazarus has a similar window style?

Martin

2009/10/30 Martin Schreiber :

A window which should not be influenced by the window manager must have the override_redirect attribute set on X. MSEgui has tmseform.optionswindow

But as far as I know, even if the window has the override_redirect flag set, there is no guarantee that it will pop to the front.

XraiseWindow() should do.

2009/10/30 Martin Schreiber :

Yes, but that applies to all windows, not only override_redirect enabled windows. :) But yes I see your point. The developer has more control over the override_redirect window because the window manager will not interfere with it.

Window manager will possibly not honour XraiseWindow for a normal window because of focus stealing prevention.

Switch off focus steeling prevention.

This does indeed work (thank you).

Now just to push a little harder, it would be nice if I could find how to bring my form to the top (therefore visible above all others), but not necessarily steal the kybd entry focus until clicked on.

I believe in Windows this is accomplished with the 'StayOnTop' (or similar from memory) - The form remains on top of all apps, not just my own

I think the way Lazarus handles the display order of an application's forms needs to be looked at.
There is an open bug report here
http://bugs.freepascal.org/view.php?id=11977

Setting fsStayOnTop does not work in cases where you use a constructor like
MyForm:= TSomeForm.Create(Application);

because the form does not get added to the Application's FormList. If it is not in the FormList it does not get drawn in the correct order.

For a work around you should use
    Application.CreateForm(TSomeForm, MyForm);
instead of
    MyForm:= TSomeForm.Create(Application);

A fix to the LCL forms.pp would be to refactor the code

    if not Assigned(FFormList) then
      FFormList := TList.Create;
    FFormList.Add(AForm);

out of TApplication.CreateForm and put it into a separate method

this bit into TApplication.Create
      FFormList := TList.Create;

and then

procedure TApplication.AddForm(AForm: TForm);
begin
  if (FFormList.IndexOf(AForm) < 0) then
    FFormList.Add(AForm);
end;

To ensure the form gets added to the Applications FormList, the TForm constructor should include

  if (AOwner is TApplication) then
    TApplication(AOwner).AddForm(Self);

I am short of time at the moment can someone look at making a patch?