View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005016 | JEDI VCL | 00 JVCL Components | public | 2009-11-13 16:14 | 2011-06-10 16:09 |
| Reporter | ZENsan | Assigned To | AHUser | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | Daily / GIT | ||||
| Target Version | Fixed in Version | 3.40 | |||
| 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. | ||||
| Tags | No tags attached. | ||||
|
2009-11-13 16:14
|
Projects.rar (759 bytes) |
|
|
Start attached program, and you will get a "ShowMessage" with stack trace. And after that default dialog box with "Division by zero". |
|
|
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. |
|
|
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) |
|
|
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; |
|
|
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? |
|
|
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. |
|
|
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? |
|
|
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. |
| 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 |
