> > Call me lazy but I don't know what other message you are referring to.
>
> The other messages with the same subject ;-)

I delete messages as I go. I'm learning to live with fewer carry-ons.

> > What kind of access to the original calling code do you require?
>
> The thing is -- the IBO code is called from within a library that should
> never raise a dialog, but it should return the error codes.

I presume you are in control of that library and as such are you not in
control of the Application instance in that library?

You should do the plumbing in your library that your application requires.

Yes, by default a dialog box may appear as a result of an exception, but it
is your responsibility as a programmer to hook in and provide more
appropriate behavior if the default is unsatisfactory.

As I see it I have no other hook to tie into other than the
Application.HandleException hook. Please tell me if I am failing to see a
more appropriate alternative.

> So, I would like to have IBO leaving all exception handling to the calling
> application, not do it yourself (that is, for exception that you don't
> know how to handle).

Exceptions are not automatically propagated to the application that calls
the library. As I recall things get pretty messed up if an exception
remains unhandled in a library.

I believe there is rather benign handling of the Abort method built in to
the VCL that would avoid problems that otherwise would result.

> I've been looking through the code and there are several calls to
> Application.HandleException -> some of them could make sense, as they
> are used in methods that explicitly use GUI items (eg: CommitWithConfirm
> (or what was it)). For others, however, it does not make sense at all.
> eg, in a Sys<something>Commit, IBO cannot know if it's being used by
> a GUI application or something else, so it should never ever expect to
> use a GUI and act accordingly. But given that I do not fully know the
> internals and some of these calls to HandleException are in a loop, I
> expect
> that you figured the code could continue after the call to HandleException
> and the user has clicked the dialog. IMO, this needs to be changed.

The only safe thing I can think of is to have code along the lines of:

If IsLibrary then
SysUtils.Abort
else
Application.HandleException();


Another possibility is to put a HandleException method on the TIB_Session
class which will allow a programmer to easily override all of IBO's
exception handling and it would default to use the
Application.HandleException of another hook were not provided.

Hopefully we will get somewhere!

Jason Wharton