Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2016-08

Testing needed for bugfix

6 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Bart

Hi,

I have tried to fix a longstanding bug w.r.t. the behaviour of the dialog and the application when setting CanClose to false in the OncanClose event of TOpenDialog.
See: http://bugs.freepascal.org/view.php?id=21147 for a description of the bug.

I need this fix tested before it can be safely merged into fixex_1_6. I have attached a sample project.

For testing you neet Lazarus trunk >= r52787 !

To test:
Unzip the attachment
Build the sample project.
Leave "OpenDialog1:TOpenDialog" seected in the radiogroup. Click the "Execute" button.

Expected behaviour:
If you cancel the dialog NO OnCanClose will be executed (this should be platform independant).
If you select a file that has an extension '.txt' (Note: case-sensitive, I'm lazy) (default filter is '*.txt') and press OK, the OnCanClose event (TForm1.OpenDialog1CanClose) is fired and the dialog closes as expected.
If you select a file with a different extension than '.txt' the OncaClose event is fires, but the dialog should not close.

Once you have closed the dialog (either by cancelling or selecting a .txt file), the applications should respond normally and you should be able to close the application.

I would exect that this now is OK under Windows.
I need testing under XP and Vista or heigher please.

Linux or MacOSX users still may hevae problems though.

Kind regards,

Bart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dlg.zip
Type: application/zip
Size: 67623 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160807/48e48e77/attachment-0001.zip>

Reply by email

Howard Page-Clark
to Bart
Bart wrote 5 lines
Hi, I have tried to fix a longstanding bug w.r.t. the behaviour of the dialog and the application when setting CanClose to false in the OncanClose event of TOpenDialog.

...

I would exect that this now is OK under Windows. I need testing under XP and Vista or heigher please. Linux or MacOSX users still may hevae problems though.

Under Linux Mint 64-bit the dialog opens and closes as you say it should for a .txt selection.
For a non-.txt selection it is impossible to close the dialog either by Cancel button or via the bordericon X close button. The dialog can only be dismissed by selecting a .txt file again.

Also I could get the project to compile only by commenting out uxtheme in the uses clause (I don't know if that skews the outcome in any way).

Howard

Reply by email

Bart
to Howard Page-Clark
Howard Page-Clark wrote
Under Linux Mint 64-bit the dialog opens and closes as you say it should for a .txt selection.

OK, fine.

B.t.w: QT or GTK2?

For a non-.txt selection it is impossible to close the dialog either by Cancel button or via the bordericon X close button. The dialog can only be dismissed by selecting a .txt file again.

Thanks for testing.
What about the OnCanClose event?
Does it get fired if you cancel the dialog?
It should not (see TFileDialog.DoCanClose).
If OnCanClose fires, can you uncomment the debugln() in TFileDialog.DoCanClose, so we can see what the value is of UserChoice at that point?

If you build the app without my fix, can you close it in that scenario? (Since I changed nothing in GTK2 or QT WS code, I expect the same behaviour)

Also I could get the project to compile only by commenting out uxtheme in the uses clause (I don't know if that skews the outcome in any way).

Sorry, you can leave that out, it was only used in the forms OnCreate at some point (but now commented out) when I was testing other problems.

Bart

Reply by email

Howard Page-Clark
to Bart
Bart wrote
B.t.w: QT or GTK2?

Same results for both GTK2 and QT

What about the OnCanClose event? Does it get fired if you cancel the dialog?

It fires for both GTK2 and QT when cancelled.

It should not (see TFileDialog.DoCanClose). If OnCanClose fires, can you uncomment the debugln() in TFileDialog.DoCanClose, so we can see what the value is of UserChoice at that point?

Ah, Perhaps I have an incorrect revision (although it is dated and built today), since TFileDialog has no DoCanClose override, and no UserChoice variable.

I'll rebuild from a download tomorrow, and test again.

Howard

Reply by email

Howard Page-Clark
to Howard Page-Clark
Howard Page-Clark wrote 7 lines
On 07/08/16 22:12, Bart wrote: > B.t.w: QT or GTK2? Same results for both GTK2 and QT > What about the OnCanClose event?

Re-testing with most recent Lazarus build today.
QT and GTK2 differ slightly.
If a .txt file is selected they behave identically. In both widgetsets the opendialog closes using either the Open or Cancel button, and with Open UserChoice is 1, and with Cancel UserChoice is 2.

In QT if a non .txt file is selected both the Open (UserChoice=1) and Cancel (UserChoice=2) buttons close the dialog. However, when the main test app is closed it then exits giving a SIGSEGV at AAE60 on my system (Mint 64-bit).

With GTK2, if a non .txt file is selected the dialog does not close either with the Open or Cancel button or the close bordericon, but OnCanClose fires and UserChoice has the values 1 (Open) or 2 (Cancel). A lock file appears named .lock.sysNameOfSelectedFile#. The only way to get the dialog to close is to select a .txt file. The main test app then closes without any error.

Howard

Reply by email

Bart
to Howard Page-Clark
Howard Page-Clark wrote 5 lines
Re-testing with most recent Lazarus build today. QT and GTK2 differ slightly. If a .txt file is selected they behave identically. In both widgetsets the opendialog closes using either the Open or Cancel button, and with Open UserChoice is 1, and with Cancel UserChoice is 2.

Note: the debugln in DoCanClose should write mrOK or mrCancel.

In QT if a non .txt file is selected both the Open (UserChoice=1) and Cancel (UserChoice=2) buttons close the dialog. However, when the main test app is closed it then exits giving a SIGSEGV at AAE60 on my system (Mint 64-bit).

That sucks, this is like Win32 did.

Show quoted text 7 lines
With GTK2, if a non .txt file is selected the dialog does not close either with the Open or Cancel button or the close bordericon, but OnCanClose fires and UserChoice has the values 1 (Open) or 2 (Cancel). A lock file appears named .lock.sysNameOfSelectedFile#. The only way to get the dialog to close is to select a .txt file. The main test app then closes without any error.

This suggest that not closing the dialog does not depend on the value that DoCanClose retruns (it should set CanClose to TRUE if UserChoice mrOK, see TFileDialog.DoCanClose).

I just found out that similar issues exist for TColorDialog in win32. Also TCommonDialog should not implement OnClose event, it is incompatible with Delphi, where this event is introduced in TOpenDialog.

Again, thanks for testing.

Bart

PS Your mail keeps up ending in my Spam folder (I'm using GMail for this list).

Reply by email