On bpls and assistants

[altxt]

Hi madshi,
I just started using madExcept and got a couple of questions.

1. My code is a project group with projects nested inside. One of them compiles to an executable, the others are bpls and get loaded into the process of the exe project at runtime. How do I use madExcept to get stack traces for the entire code base? Do I need to enable madExcept (via Project menu) in all projects, or enabling it in exe only is enough?
- If exe is enough, where does madExcept get the symbol information for the bpls?
- And if all the bpls need to have madExcept enabled, do they need to include (use) madExcept units, or do they only need the patching by the IDE plugin or the command-line tool? Can they inherit madExcept's settings from the exe?

2. I need to let the user suppress repeat exceptions. I could not find a way to add logic & controls to madExcept's native exception box, so I used an 'assistant' and a custom form inside it instead. This works fine, I added a checkbox and wrote a test to only show the form if that particular exception was not seen earlier by the process. However, I could not find a way to close the form and the assistant from code - their ModalResult properties are read-only and there is no Close() or similar method in the docs. So a user needs to first press one of the custom buttons (I've hidden the default Continue/Skip/Abort buttons since they don't make much sense for a single form) and then click X to close the form. Not very friendly... Can you help me with this?

That was actually more than two questions, sorry )) And thanks for making madExcept!

[altxt]

On my second question, PostMessage(GetActiveWindow(), WM_CLOSE, 0, 0) seems to work just fine

[madshi]

I suppose you're using the RTL and VCL runtime packages in your EXE and in all your BPLs, so none of them have the RTL/VCL linked in? Or do you have the RTL/VCL linked into the EXE, and only the BPLs use the RTL/VCL BPLs?

Generally my suggestion would be to link madExcept into the EXE by checking the 3 "linker options" checkboxes here:

http://help.madshi.net/madExceptSettings1.htm

For your BPLs you will most probably only need to let madExcept add the function names and line numbers to your BPLs. You can do that by just checking "link in function names and line numbers" and leaving the other 2 linker options unchecked.

[altxt]

Thank you, that's exactly what I was looking for. And yes, I am using runtime packages in all projects.

[altxt]

Another question on bpls.
madExcept seems to treat exceptions that cross bpl boundaries as unhandled, even though there is a handler in another module. I attach a demo project group. With madExcept disabled, the standard exception box never shows up, as all exceptions are handled (handlers use ShowMessage() for notification). With madExcept enabled in exe, the exception that is not handled inside the bpl and should be caught in the exe produces madExcept's exception box.
I am using Delphi XE6 Update 1 and madExcept 4.0.16.
Is there a way to restore the usual flow of exceptions? I'd really like to process them in other packages than they were originally thrown from.

[madshi]

Can you please upload a bug report of this situation? Might make it easier for me to see what's going on than to try to compile a multi-project demo project. Thanks!

[altxt]

Sure, here it is

[altxt]

Any news on the subject? Madshi, were you able to reproduce the problem? Please tell if you need further information.

[madshi]

There's a special handler in madExcept that hooks into the "LoadPackage()" function and activates madExcept for all unhandled crashes that happen during LoadPackage(). The main purpose of this is to make such crashes visible because otherwise they might get lost somewhere in some Delphi versions.

There's a relatively easy way to work around this issue: You can create a little exception handler like this:

Code: Select all

procedure IgnorePackageLoadExceptions(const exceptIntf: IMEException; var handled: boolean);
begin
  if exceptIntf.Source = esInitializePackage then
    handled := true;
end;

initialization
  RegisterExceptionHandler(IgnorePackageLoadExceptions, stDontSync, epQuickFiltering);
end.

Hope that helps?

[altxt]

Hooking into package load at esInitializePackage works, but you sample is suppressing the exception. How can I let it go to the appropriate try/except handler? I tried
exceptIntf.CallHandlers:=true;
and
exceptIntf.ShowSetting:=ssNothing;
but the handler did not fire.

[madshi]

The way the code is currently written, madExcept always catches and handles the exception, so there's no way to pass it to the original handler, unfortunately. However, I suppose that your call to LoadPackage should fail in this situation, so if all else fails, you could check the result of LoadPackage and if it failed, you could manually raise another exception right after LoadPackage. Does that help?

I'm not sure what the appropriate try/except handler is doing. Can you maybe just copy that code to the exception callback I suggested in my previous comment?

[altxt]

I just tried it, and, unfortunately, it does not work. LoadPackage() can only fail if the nested LoadLibrary() fails, otherwise it returns a module handle regardless of what happens in initialization sections of units packaged into the bpl (or an exception, but madExcept swallows it). I guess I'll have to move the throwing code from initialization to a global function (basically, it checks whether the end user has permission to use the package).
The good news is that exceptions thrown by "normal" methods in packageds units are caught by a handler in the exe just like they should be, so the problem is not as severe as I initially thought.
Thanks for your help!

[madshi]

So you can work with the way it currently is?

[altxt]

Yeah, though it took some time to refactor code in a way that does not introduce unnecessary coupling. Luckily, the framework used in the project provided a means to that.