Form not focusable after other Form was temporarily hidden (Linux only)

[Hartmut]

Did you override the "CreateNew" and call the CreateNew when you manually created the form or did you override the Constructor Create then made a call to the CreateNew within this construct?

Eitherway, using the Create normally involves some resource loading, like the LFM file and streaming etc.

I'm not sure if I understand what you mean.
The 3 Forms are created as detailed shown in reply #11. Please have a look.
'override' and 'Create' are nowhere used.
Because all 3 Forms are dynamic Forms, there are no LFM files.
Streaming is nowhere used in this program.

[Zvoni]

OK, could you test (on Linux):
Your Form1 (which is the Modal Form) --> Could you call it as NON-MODAL Form?
and from there your workflow --> Call Form 2, call Form 3, hide Form 1, Close Form 3, unhide Form 1, try to Activate Form 2

Just to see if the Problem is with the ModalForm or something else

[Hartmut]

Hello Zvoni, I made a provisional hack, just to open Form1 now non modal, and the problem with Form2 being not focusable after temporarily hiding Form1 now is gone. But for a couple of reasons I would not like to switch everything to use Form1 always non modal as the "solution".

So I hope this test gives you some valuable information, what the root cause of the problem could be (or not be) to find a solution, which keeps Form1 modal. As said, "1000" other things with this combination of many modal and non modal Forms work perfectly (and have been detailed tested with high effort - double for Windows and Linux) and only for this small focussing blemish (which occurs only on Linux) it would not be worth to set so much upside-down.

[jamie]

What I was referring to here was the fact that you are calling the INHERITED CreateNew.

If you are indeed calling the CreateNew for everything then why call the Inherited Createnew ?

Also, calling the Constructor CREATE I believe does a few steps like putting the form in the Screen.Forms list.

Can you check to see if your form is showing up in the Screen.Forms list ?

On windows, these focus operations are done via messages sent from the OS but on linux I don't think they are quit handled the same way .

Jamie

[Hartmut]

What I was referring to here was the fact that you are calling the INHERITED CreateNew.
If you are indeed calling the CreateNew for everything then why call the Inherited Createnew ?

I don't remember, why I added this 'inherited' in front of CreateNew(). Maybe it's redundant. From my (small) knowledge I assume, that it is automatically ignored, if no ancestor exists. I made a test without this 'inherited' in front of CreateNew() and it made no difference.

Also, calling the Constructor CREATE I believe does a few steps like putting the form in the Screen.Forms list.
Can you check to see if your form is showing up in the Screen.Forms list ?

I always use CreateNew() instead of Create() for all Forms without a .lfm file (as learned in this Forum by wp).
I checked, that all Forms are contained in Screen.Forms[].

[wp]

I wrote a little project following the steps that you gave in the first post. It creates a main form with button 1 to open modal Form1. Form1 has a button 2 to open non-modal Form2, and button 3 to perform a sequence of steps: Hide itself, show non-modal form3, start a process indicated by a timer; when the process is complete Form3 closes and Form1 is reshown. The buttons are to be clicked in the order 1-2-3.

With this project I was not able to verify your issue (inability of Form2 to react on clicks), neither on Win32, nor on gtk2, and not on qt6.

Feel free to modify the project so that it reproduces your issue.

[Hartmut]

Thank you very much wp for this demo. I feel sad because not you should spend your valuable time for creating a demo. And despite there are some differences to what I wrote the problem occurs in your demo in the same way as in my real program. This is great!

So where can be the reason, that the problem did not occur on your system?

I use Linux Ubuntu 24.04 64-bit on KDE-Desktop with X11 Window manager.
I compiled your demo with:
 - Lazarus/FPC 3.4.0/3.2.2 (gtk2 and qt5)
 - my last trunk from summer 2024 = Lazarus 3.99 (rev main_3_99-2316-g00f3d3b397) FPC 3.3.1 x86_64-linux-gtk2
 - Lazarus/FPC 2.0.10/3.2.0 (gtk2 only)
and always the problem occured the same way.

I have a friend with Ubuntu 24.04 and Gnome-Desktop. Will try to contact and ask him to test your demo there. If this is not possible in the nearer time I will install Lazarus 4.4 and try there.

Here again a detailed description, how the problem occurs with your demo on my system:
 - in MainForm press the only button to open modal Form1 (it's named Form2, don't worry)
 - in Form1 press button "2" to open non modal Form2
 - now I can click on both Forms as often as I want and always the clicked Form gets the Focus and I can use it without any restrictions (I can both Forms resize, move, minimize, maximize and close)
 - in Form1 press button "3" to open non modal Form3, which hides Form1 temporarily and after some seconds closes Form3 automatically and shows Form1 again

From now on I cannot set the Focus (via mouse) to still open Form2 any longer:
 - the Focus then always stays on Form1
 - I cannot close Form2 (via it's Icon in upper right corner)
 - but I can still resize, move, minimize and maximize Form2
 - and if I cover Form2 partly by another Window (with the MainForm of the demo or a Window of another program), then by clicking on Form2 it comes to front (but without getting the Focus).
As said, this problem does not occur on Windows.

Above behavior of Form2 is exactly the same behavior, which I described in reply #8 (marked there in blue), if a program first opens a non modal Form2 and after that opens a modal Form5.
Again my question from there: Is it possible, that the problem occurs, because (after modal Form1 was temporarily hidden) the program "thinks", that a new modal Form was opened (because it behaves that way)?

Can you (or someone else) reproduce the problem with above description on Linux?
If yes/no, please tell us your detailed OS- and Lazarus version.

[zeljko]

When modal window is hidden application should dec modalcount and it should not "think" that there are more modal windows, actually such hidden modal window drop it's handle afair (but not sure 100%). If wp's project is ok I'll test with it.

[wp]

Thanks for confirming that the issue can be reproduced by my demo. Now I understand that I deviated from your instructions, I did not click on Form2 after Form3 has closed, but only while Form3 was open. Following your steps now exactly, here are my observations on some of my virtual machines:

• OpenSUSE KDE/x11, Laz 4.4 + FPC 3.2.2, as well as Laz-main (very recent) + FPC 3.2.2
  
  • gtk2/qt5/qt6 --> your observation (Form2 cannot get focus any more, cannot be closed by 'x')
  • gt3: The border of Form2 is painted as if it were focused, but it cannot be closed by the 'x'.
• Manjaro XFCE 26.0/x11: Laz 4.4 + FPC 3.2.2, as well as Laz/main + FPC 3.2.2
  
  • qt5: your observation
  • qt6: When Form3 closes, Form1 shortly flashes up, and then remains invisible, maybe even destroyed(?). Form2 works normally, it can be dragged and closed by 'x'. Form1 can be closed, event while Form2 is open.
• Ubuntu 22.04/GNOME: Laz 2.2.6 + FPC 3.2.2
  
  • gtk2: Normal behaviour, no bug
• Ubuntu 24.04 GNOME/wayland
  
  • Laz 4.4 + FPC 3.2. / gtk2: Normal behaviour, no bug
  • Laz main + FPC 3.2.2 / gtk2:  Normal behaviour, no bug
  • Laz main + FPC 3.2.2 / gtk3: Your observation. Additionally: Form2 cannot be dragged and closed after Button2 click (before Form3 was opened).
  • Laz main + FPC 3.2.2 / qt5: Your observation.
• macOS Monterey, Laz main + FPC 3.2.2: Normal behaviour, no bug
• Windows 11, Laz main + FPC 3.2.2 (32 bit): Normal behaviour, no bug

[Hartmut]

Thanks a lot wp for those detailed tests. Sorry if my description, at which time to click on not focusable Form2 was not clear enough.

Meanwhile I made some tests on Ubuntu 24.04 with GNOME-Desktop with Wayland and X11, both with your demo and with my "real program". In all 4 cases the problem did not occur. I had compiled with Lazarus/FPC 3.4.0/3.2.2 and gtk2.

Together with your results it seems not so easy to say, who is the "bad guy":
 - for gtk2 it seems to work with GNOME-Desktop (X11 and Wayland), but not with KDE-Desktop (X11)
 - gtk3 seems never to work
 - qt5 seems never to work
 - qt6 seems never to work

I have no idea to guess, if this problem would have to be fixed outside of the LCL in the Linux widgetsets or/and inside the LCL (and if it's worth the effort).

But I assume, that there will be no solution for Ubuntu 24.04 with KDE-Desktop (with reliable effort) in the foreseeable future. If nobody contradicts in the next days I will implement the "emergency solution" described in my very 1st post.

Again thank you very much to all who helped to investigate this problem.