--- In IBObjects@yahoogroups.com, "Martijn Tonies" <m.tonies@...>
wrote:

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

What if your Application exception handler just stored the data from
the error object (or better, a reference to the object itself) in a
list and then returned (as though the regular error dialog had been
shown and the user clicked OK). Then, after your library regains
control, it can look at this list and do what it needs to do.

I'd bet only the first object would be of interest because of
cascades, but at least you can then return its error data without
having to invoke a GUI.

Michael D. Spence
Mockingbird Data Systems, Inc.