Project JEDI - Issue Tracker
Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0005016 [JEDI VCL] 00 JVCL Components major always 2009-11-13 16:14 2011-06-10 16:09
Reporter ZENsan View Status public  
Assigned To AHUser
Priority normal Resolution fixed  
Status resolved   Product Version Daily / GIT
Summary 0005016: JvDebugHandler now always call default exception handler even when OnOtherDestination
Description JvDebugHandler now always call default exception handler even when OnOtherDestination is assigned.
Additional Information
Tags No tags attached.
Attached Files rar file icon Projects.rar [^] (759 bytes) 2009-11-13 16:14
zip file icon [^] (1,054 bytes) 2009-11-17 17:18

- Relationships

-  Notes
ZENsan (reporter)
2009-11-13 16:15

Start attached program, and you will get a "ShowMessage" with stack trace. And after that default dialog box with "Division by zero".
ZENsan (reporter)
2009-11-13 16:18

And the diference is that for this project it happens as I described. But for other project, when JvAppEvents unit is included in the project before the unit where JvDebugHandler is used then first is shown default exception form and only then called onotherdestination.
AHUser (developer)
2009-11-14 13:34

The problem is not JvAppEvents it is Delphi's AppEvnts.pas unit that is used by JvAppEvents and JvDebugHandler.

The original implementation of JvDebugHandler set the Application.OnException event. But when the unit AppEvnts (EMBT's to be clear here) is included there was a fight over the Application.OnException event. And that is the point when the order of the included units became important. If TJvDebugHandler was "installed" first, the AppEvnts multicaster overwrote the OnException event and JvDebugHandler was "disabled".
With the lastest changes to JvDebugHandler the debug handler uses the AppEvnts unit itself to install the OnException event. That way the order in which you include the AppEvnts and JvDebugHandler unit becomes irrelevant.

And now the problem with JvAppEvent. Because the JvDebugHandler uses AppEvnts.pas the JvAppEvent introduces the "unit ordering" problem. This can be easily fixed by changing JvDebugHandler to use JvAppEvent instead of AppEvnts.

The remaining problem with the default exception handler dialog seems to me "as designed". That was the behavior before my last changes and is the same behavior now. It is controlled by the UnhandledExceptionsOnly property.
If that implementation is wrong than it was wrong all the time. I'm open to any suggestions on how this component should work.
ZENsan (reporter)
2009-11-17 17:27

Like it is now. The component do not works at all!
One ot two months ago it worked perfectly. I never seen the default exception handler and this is the right way as it must work (I think so). Ans as it worked all the time before. But now the appeaareance was changed and it is absolutely useless.

When exception occurs component must call OnOtherDestination and as addition can give possibility to setup parameter like "CallOldHandler" or something like that. if you set it to True (by default False) then old handler is also called:

procedure TfrmMain.DebugHandlerOtherDestination(Sender: TObject; CallOriginalHandler: Boolean);
  CallOriginalHandler := False;
ZENsan (reporter)
2009-11-17 17:28

Attached sample demonstrates that component is not working at all.
And before some months it was ok. Why do we need to change appeareance which was there for years?
AHUser (developer)
2009-11-17 22:38
edited on: 2009-11-17 22:47

I have changed the implementation of TJvAppEvents to only install the OnException handler if it is assigned. This should fix the unit ordering problem because TJvAppEvents.DoException doesn't show any default exception dialog anymore.

> Why do we need to change appeareance which was there for years?

Hooking Application.OnException isn't a good idea because there will always be another component that also hooks it, like TApplicationEvents.

The only question that remains is if we should revert my changes to JvDebugHandler.pas what will reopen Mantis 0005003 and we would need a new fix for it. I'm open to all ideas.

ZENsan (reporter)
2009-11-18 11:34

So what about my suggestion to make it optional to call default handler?
Or add that as property (for example "property CallDefaulthandler: Boolean") to component.
If the problem is in the unit order, we can easy add and notification about that like it is done in FastMM4.pas (must be first unit in project).

What you think?
ZENsan (reporter)
2009-11-18 11:38

I updated from the SVN and now it is working.
And also about - there is my fault (I assigned Application.OnException := nil). For some time before it solved a problem). But now it works like it must be.

- Issue History
Date Modified Username Field Change
2009-11-13 16:14 ZENsan New Issue
2009-11-13 16:14 ZENsan File Added: Projects.rar
2009-11-13 16:15 ZENsan Note Added: 0016872
2009-11-13 16:18 ZENsan Note Added: 0016873
2009-11-14 13:34 AHUser Note Added: 0016874
2009-11-14 21:30 AHUser Assigned To => AHUser
2009-11-14 21:30 AHUser Status new => confirmed
2009-11-17 17:18 ZENsan File Added:
2009-11-17 17:27 ZENsan Note Added: 0016890
2009-11-17 17:28 ZENsan Note Added: 0016891
2009-11-17 22:38 AHUser Note Added: 0016892
2009-11-17 22:38 AHUser Note Edited: 0016892
2009-11-17 22:47 AHUser Note Edited: 0016892
2009-11-18 11:34 ZENsan Note Added: 0016893
2009-11-18 11:38 ZENsan Note Added: 0016894
2009-11-19 23:00 AHUser Status confirmed => resolved
2009-11-19 23:00 AHUser Fixed in Version => Daily / SVN
2009-11-19 23:00 AHUser Resolution open => fixed
2011-06-10 16:09 obones Fixed in Version Daily / SVN => 3.40

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker