FormStyle = fsStayOnTop not implemented in Linux ?

[Bart]

Setting FormStyle := fsStayOnTop in Linux seems to have no effect at all.
Is this a Windows only feature (as in does Linux not support this, I am a Linux newbie), or is it a bug / not yet implemented?

Actually what I want is this:
- I show a form (dialog) non-modal
- I want to keep it above the application/form from which it is called and not disappear behind the calling app/form when it looses focus (it's Z-order has to be higher).

This can be achieved in Delphi by setting the formstyle to fsStayOnTop. The dialog then stays on top of the application, but not on top of all windows and this is the effect I'm looking for.
In Lazarus/Win32 the dialog stays on top of every window, which looks rather silly.
(I posted this as bug #8471 in the Lazarus bugtracker)
In Lazarus/Linux it realy does nothing at all.

Why do I need this?
I'm in the process of patching the TFindDialog and TReplaceDialog, which at the moment are broken (bug #8370). I'm almost there, but this is rather annoying. I want the dialog to behave like it does in Delphi, that is non-modal and on top of the application.

If setting the FormStyle is not the way to go, because it is not platform independent, how to achieve the same effect in code?

Bart

[Danail]

I am just using
 Form2.ShowModal;
 and it works on the way you want it. I don't know why it is not hapening with your Linux.

[Bart]

Yes with ShowModal the form is on top.
However I want it to stay on top with a non-Modal dialog, that's the whole point. I do not want the dialog in this case to be a Modal one.

Bart

[RudieD]

I think he means like in Word where you can type in the document while your search dialog is visible and stays on top.

Have you tried to create the Dialog form with the main form as Parent ?

[Bart]

I think he means like in Word where you can type in the document while your search dialog is visible and stays on top.

Yes, that is exactly what I mean.

Have you tried to create the Dialog form with the main form as Parent ?

No, I havent. I don't think forms have a parent property (no Delphi or Lazrus available here to check this)? But even if it has, since this form is a private form of TFindDialog/TReplaceDialog and these do not have a Parent property, the form cannot know what the parent should be.

Anyhow fsStayOnTop does not seem to do anything at all (not even for the main form) in my Lazarus/Linux (Laz 0.9.20/Suse 10.0), and my original question remains: does something lik a StayOnTop not exist in Linux/GTK or is it simply not implemented (yet)?

Bart

[Bart]

Hi RudieD,

Have you tried to create the Dialog form with the main form as Parent ?

I tried it.
In Delphi 3 this makes the dialog behave as if it is Modal: as soon as you show the form, the mainform gets inaccesible until you close the dialog.

In Lazarus (win32) this creates an AV on programstart if you set the mainform as parent. If you set another control on the mainform as parent, the dialog never shows and the program freezes, so you'll have to kill it.

This seems not the way to go then.
Anyhow I don't feel that a TFindDialog or TReplageDialog should have a parent.

Bart

[RudieD]

I don't think the the dialog should stay visible because it might hide a part of the form. I think the best way for you is maybe to create your own search form (not dialog).

[Bart]

I think it should stay visible for several reasons
1. the find/replacedialog of delphi act like this
2. for the end-user this simplifies things. You can search, edit, search again
3. most office-line applications do it this way, so the user expects this behaviour

But that's just my opinion ;-)

Bart

[Zomis]

I agree with Bart. Even though the dialog might hide a part of the form, it's moveable so the user can move it to cover another part of the form.

[RudieD]

Then it should not be a Dialog but a form that you can decide when to hide / destroy it ? If you show the Save Dialog then user must first finish saving before continuing. Create a Search/Replace Form with a Procedure in the Interface that you can call (ShowSearchReplace(aSynEdit:TSynEdit)).

[Bart]

Then it should not be a Dialog but a form that you can decide when to hide / destroy it ?

Isn't that just a matter of semantics?
I don't think that a dialog needs to be modal, just in order to call it a dialog.

If you have Delphi execute a finddialog (or do a find in MS Word or OpenOffice.org) and a non-modal find or replace form appears, which I tend to call a dialog. This is what I'm after.

If you show the Save Dialog then user must first finish saving before continuing.

The FileOpen dialog's purpose is to let the user make one (and only one) choice, only one time (we do not want the user to press "save" and after that "cancel", that would not make sense would it). So in this case make it modal and check modalresult to see what  the user wants.
A find/replace dialog however gives the user the possibility to find text, alter it if he wants, find next occurence, change direction in finding etc.
I find this feature rather helpull and so do many other end-users.

Since I make most of my software for either myself, or for almost computer-illetarates, I tend to give the user what he/she expects.
In the Windows environment that is the behaviour I described above.
But I'm repeating myself and my arguments.

... (ShowSearchReplace(aSynEdit:TSynEdit)

Code: [Select]

SynMemo1.ShowSearchReplace;

utest.pas(159,12) Error: identifier idents no member "ShowSearchReplace"

Let's agree that we can disagree on wether or not we want a non-modal dialog.
Say I want a non-modal dialog/form that stay's on top of all windows from it's own application, but not on top of all windows on the desktop.

Does anyone have any idea as how to achieve this, OS/WindowManager independently?

Bart