> > Yes, I can use the event, but please read the other messages about this.
> >
> > When the event is being processed, I do not have access to the original
> > calling code.
>
> Call me lazy but I don't know what other message you are referring to.

The other messages with the same subject ;-)

> 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.

Now, if IBO raises a dialog by calling Application.HandleException
(which does ShowException by default), this is wrong.

If I use the event handler to "eat" the exception, I cannot return an
error code, cause from the calling code, it looks like there WAS no
exception (= eaten).

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).

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.


Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com