Problem with FindDialog

[devEric69]

Hello,

I have a very simple problem: the call "FindDialog1.Execute" from a 3rd window (red button of the small zipped project) doesn't work: so, no search is possible from there.

Nevertheless, Findialog1.OnFind is assigned vith an existing method's procedure. But the caption-'find' button of the dialog, never triggers its OnClick event, i.e. the code finddialog.inc (line 520) below seems to have no effect:

Code: Pascal  [Select][+][-]

1. FindButton.OnClick := @FindClick;

I have two problems:
- first, I don't understand the cause of my second call bug "FindDialog1.Execute".
- and I would like to understand how to debug this with GDB, or another method.

I've tried to follow the address contained in FindDialog1.OnFind (by tracing the FindDialog1.FOnFind field, or other expressions, but without success).
Then, I wanted to use another method, in a "interpreted language" way, i.e. to follow the variations of pointer assignment in general, by "dumping" the content of the objects in a terminal console or in a text file: I tried to transform the object into a json (thinking about "deep cloning"), or to dump it with TMemoryStream in a log: but only the published or public properties are retrieved, not the method pointers.

If someone understands this bug, can he explain me the methodology he will have used to debug this (GDB, dumping functionality, ...)?

Best regards.

[sash]

Can't see nether 3rd window nor red button.

[devEric69]

Hello,

this "path" must be followed: mainForm > button "Show IniFile" > button "Nothing to search. Now, show referential" > button with red caption "FindDialog doesn't work, here".

[sash]

There's something wrong with your layout/anchors/sizing color.
I didn't sort it out, but pretty sure there are some clashes between caller/owner forms.
Can't you just simplify both layout, code and calls structure?

Also, for modal forms, use try-finally

Code: Pascal  [Select][+][-]

1. with TYourModalForm.Create(nil) do
2.   try
3.     if ShowModal = mrOk then
4.       Whatever();
5.   finally
6.     Free;
7.   end;
8.  
9.   // and inside YourModalForm, don't use Close, instead use
10.   ModalResult := mrOk;
11.  

[devEric69]

There's something wrong with your layout/anchors/sizing color.

It's code that I extracted from a larger project, just to reproduce the problem.

Can't you just simplify both layout, code and calls structure?
Also, for modal forms, use try-finally

Okay, I'm rebuilding a demo with simplified code and calls.

[wp]

Your demo works correctly for me (Win 10, Laz trunk/fpc 3.0.4, Laz 2.0.6/fpc 3.0.4). You only must set HideSelection of both memos to false.

In order to debug the issue I added a breakpoint to the first line of TfrmReferentielIni.FindDialog1Find. In a test run, I noticed that the application does stop here - therefore, your assumption that the OnFind event handler is not called is not correct. After some searching I noticed that TMemo seems to belong to the group of controls with the property HideSelection which unfortunately defaults to true (the others are TListBox and TTreeView). Changing the property value solved the issue by making the found text visible in the memo.

I don't understand why you say that issue does not occur in the main form. Here we have the same problem: Set Memo1.HideSelection = false - that's all.

[devEric69]

@wp: thank you for the answer.

I've rebuilt and posted a new demo with simplified code and calls, and I've removed the container controls (TPanel, TGroupBox, etc), and set all the TMemo.HideSelection property to false.

==> the second TFindDialog of the second modal window *still* does nothing.

@sash: can you please confirm, if you still have this problem on your OS (Ubuntu too), or not?


edit: this demo works on Win7 32 bits, with Laz. 2.0.2 + FPC 3.0.4.

[wp]

I tried the new demo in
- Window 10 -> works
- Mint Linux/qt --> works
- Manjaro Linux/qt5 --> works
- Manjaro Linux/gtk2 --> DOES NOT WORK
- Mint/gtk2 --> DOES NOT WORK.

[lucamar]

Not only "does nothing": it shows up but is completely unresponsive. I can confirm (on this Ubuntu 12.04 box), though I haven't yet looked to find why.

ETA:
I think I know what's the problem: too many modal dialogs. IIRC, GTK gets a little "lost" when an application opens more than two modal dialogs/forms in cascade, as you're doing, but I'll have to test a little to make sure of it.

EATA:
The attached (Q&D) project demonstrates the issue. Seems to be, indeed, due to the modal "cascade". HTH

[winni]

Hi!

Suse Linux/gtk2 : Does NOT work.


Winni

[winni]

showModal is defined as : blocking all other Forms until the modal form is closed. It is total blocking, so this "error" is a normal behaviour.

The question is now: why does it work in some OS/WidgetSets? This is against the definition.

Winni

[lucamar]

The question is now: why does it work in some OS/WidgetSets? This is against the definition.

My guess is that other widgetsets are happy with however many modal forms you want to show; they will just set the last one as "active". GTK, though, seems to be stricter: it'll show whatever you tell it but only the first modal form will respond; as if it were using a FIFO rather than LIFO list for them, roughly speaking.

[devEric69]

[snip] as if GTK were using a FIFO rather than LIFO list for them, roughly speaking.

All right, I understood globally, the problem due specifically to GTK.

==> Now, should I create a bug report (in Mantis)?

[lucamar]

==> Now, should I create a bug report (in Mantis)?

Maybe, but first check if there's already one. I kind of remember having seen this issue raised more than once.

[devEric69]

All right (bug report created: https://bugs.freepascal.org/view.php?id=36485 ).