Are errors occuring in tOpenDialog,execute ignored??

[Alf Christophersen]

I have an application where about 10% of users has the problem that opendialog1.execute is immediately aborted as if Esc key has been touched in some way.

But I do not get any exception report on the event.

Therefor

Is tApplication.onException handled fully in Eurekalog 5.1.12? And if
so, is such errors from system components ignored??

[admin]

Hi Christophersen,

this is really strange.

Try to do this:

1)...Close all opened Delphi/C++Builder instances;
2)...Deinstall all installed EurekaLog versions;
3)...Remove all folders containing ExceptionLog.* or ?ExceptionExpert.* files;
4)...Remove the EurekaLog folder from your Application Data folder (%AppData%)
5)...download and install the latest EurekaLog version;
6)...restart your PC.

PS: do you have try with a 6.0.20 Trial, just to see if this last version solve your issue?

I'm waiting to your feedback ASAP, OK? :)

If this doesn't work then try to create and send to me a little source demo which is able to reproduce your issue!

[Alf Christophersen]

admin wrote:
Hi Christophersen,

this is really strange.

Try to do this:

1)...Close all opened Delphi/C++Builder instances;
2)...Deinstall all installed EurekaLog versions;
3)...Remove all folders containing ExceptionLog.* or ?ExceptionExpert.* files;
4)...Remove the EurekaLog folder from your Application Data folder (%AppData%) 5)...download and install the latest EurekaLog version;
6)...restart your PC.

PS: do you have try with a 6.0.20 Trial, just to see if this last version solve your issue?

I'm waiting to your feedback ASAP, OK? :)

If this doesn't work then try to create and send to me a little source demo which is able to reproduce your issue!
Forgot to tell that I use still last version of v. 5 and this happens only now and then in computers I have no control of. Opendialog work fine on my own computer, of course.

But, as said in a thread on embarcadero.public.delphi.rtl, thread
"Strange behaviour of tOpenDialog", it might be that the Close button is placed at exact the same place as the Startbutton, but I doubt.

The behaviour is that something close the tOpenDialog immediately as if there is no ressource available, but, if so, I thought that Eurekalog would have reported this.

It's just as if a ghost close it for the users.
(Might it be a virus??)

[Alex]

Hi, Alf.

It appears that there is no exception in your case, so EurekaLog could not help you with this case (there is no exception to catch).
I recommend you to try implementing some logging, for example, by using SmartInspect - see: http://www.gurock.com/products/smartinspect/articles/integrating-smartinspect-and-eurekalog/

[Alex]

To be absolutely sure that there is no exception, try to use this:

...
try
B := OpenDialog.Execute;
except
ShowLastExceptionData; // or any other notification that you prefer
raise; // or just exit?
end;
if B then
...

As for the logging:

T1 := GetTickCount;
try
EnableLogging;
try
B := OpenDialog.Execute; // also try to log everything there: window messages, etc
finally
DisableLogging;
end;
except
...
end;
if GetTickCount - T1 < 1000 then // open dialog was closed very quickly
raise Exception.Create('The open dialog was closed unexpectedly'); // append your logged messages to the EL report here.
if B then
...

The last option is using of some sort of tracer program, but that means, that you need a user, who agrees to cooperate with you to find this bug. You need to send him a test copy of your app and a tracer. The tracer will record all lines of code (source) that your application will execute. So you can compare them with "normal" flow and spot the differences.

[Alex]

Final notice: to maximize effectiveness of EurekaLog's log files - please, refer to: http://blog.eurekalog.com/?p=122

[Alf Christophersen]

---------
T1 := GetTickCount;
try EnableLogging;
try B := OpenDialog.Execute; // also try to log everything there: window messages, etc finally DisableLogging;
end;
except ...
end;
if GetTickCount - T1 < 1000 then // open dialog was closed very quickly raise Exception.Create('The open dialog was closed unexpectedly'); // append your logged messages to the EL report here.

Anyway, even without the logging, this should be a good way to detect
that something strange happened :-) If set to 300 or less (I guess the value would be far less than 300 since the dialog is seemingly visible for just a blink.

If I remember correctly, if the problem is that as depicted in an answer in the other thread that the message of keyup is caught by the dialog,
and the dialog moves around each time opened, I can repeat the opening
of the dialog until it is okbutton away from the mouse so it won't catch the mouseup signal.

:-)

(Think me have to wrire a general procedure thar do that testing
everywhere with the opendialog as parameter :-)

[Alex]

Hi.

Check if the customers have Vista or Win7.

On my Vista there is auto-move mouse cursor to Ok button of several dialogs. There were no such behaviour on WinXP.
I don't know, but may be user simple make double click on your button? First click launches a dialog, and second click closes it, since mouse were located to Ok button.

[Alf Christophersen]

Alex wrote:
Hi.

Check if the customers have Vista or Win7.

On my Vista there is auto-move mouse cursor to Ok button of several dialogs. There were no such behaviour on WinXP.
I don't know, but may be user simple make double click on your button? First click launches a dialog, and second click closes it, since mouse were located to Ok button.
I think all uses XP :-)

And yes, I think many uses double clicks :-(

So maybe a message about "Don't double click on me" would also be a good idea :-)

[Alf Christophersen]

Alf Christophersen wrote:
Alex wrote:
Hi.

Check if the customers have Vista or Win7.

On my Vista there is auto-move mouse cursor to Ok button of several dialogs. There were no such behaviour on WinXP.
I don't know, but may be user simple make double click on your button?
First click launches a dialog, and second click closes it, since mouse were located to Ok button.
I think all uses XP :-)

And yes, I think many uses double clicks :-(

So maybe a message about "Don't double click on me" would also be a good idea :-) Well, now I have exchanged opening with a routine that tries to open the dialog again after 500 ms if the dialog closes by quit before 250 ms has gone, and then display a message about check if the Esc is pressed down.

I guess Vista users only get it working after first closing by that
automove.

Misunderstood your question. Maybe when I think about it, several of
them uses Vista.