View Issue Details

IDProjectCategoryView StatusLast Update
0005016JEDI VCL00 JVCL Componentspublic2011-06-10 16:09
ReporterZENsanAssigned ToAHUser 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product VersionDaily / GIT 
Target VersionFixed in Version3.40 
Summary0005016: JvDebugHandler now always call default exception handler even when OnOtherDestination
DescriptionJvDebugHandler now always call default exception handler even when OnOtherDestination is assigned.
TagsNo tags attached.

Activities

2009-11-13 16:14

 

Projects.rar (759 bytes)

ZENsan

2009-11-13 16:15

reporter   ~0016872

Start attached program, and you will get a "ShowMessage" with stack trace. And after that default dialog box with "Division by zero".

ZENsan

2009-11-13 16:18

reporter   ~0016873

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

2009-11-14 13:34

developer   ~0016874

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.

2009-11-17 17:18

 

Projects.zip (1,054 bytes)

ZENsan

2009-11-17 17:27

reporter   ~0016890

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);
begin
  ShowMessage('Error');
  CallOriginalHandler := False;
end;

ZENsan

2009-11-17 17:28

reporter   ~0016891

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

2009-11-17 22:38

developer   ~0016892

Last edited: 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

2009-11-18 11:34

reporter   ~0016893

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

2009-11-18 11:38

reporter   ~0016894

I updated from the SVN and now it is working.
And also about Projects.zip - 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: Projects.zip
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