--- In IBObjects@yahoogroups.com, "Support List" <supportlist@...> wrote:

>
> Dany,
>
> > I would like my GUI application to use a separate thread to connect to the
> > database (FB 2.0, FB 2.1). I have seen this done in other environments
> > with FireBird.
> >
> > The idea is to show a "Connecting..." dialogue/window in which the user
> > may abort the operation at *any* time instantaneously. The connecting
> > thread would then be aborted. An animation may be shown during the phase
> > where the connecting thread is waiting for the FB client library and the
> > main thread with the window may receive windows messages normally.
> >
> > In most Delphi + fbclient application I see the application is totally
> > unresponsive during connection and the annoying thing is for the user to
> > wait for the time out. I do not want to change the time out.
> >
> > This application already has a ConnectionDataModule with session and
> > connection component. The module is referenced by a lot of datamodules
> > after a successful connect. It is written so that in the (near) future I
> > might decide to provide each datamodule with it's own
> > ConnectionDataModule. But this is a bit besides the point at the moment.
> >
> > My problem is that my delphi+threading expirience is a little meagre,
> > though I have used threads both in applications and in services, so I'm
> > not asking for the basics.
> >
> > One approach that I'm thinking about is to create a connection thread and
> > let that thread create the ConnectionDataModule. If things fail or are
> > aborted the thread should exit and return an error to the main thread. If
> > things go well, however I would ideally like the thread to "hand over" the
> > complete datamodule object with all the state data to the main thread.
> >
> > Is this even possible? Does anyone have any idea of how to go about this
> > task?
>
> You should be able to have a complete data module instance serviced by a
> thread other than the main thread and for it to be handed over to your main
> application once it has gone through all of its initiation procedures. You
> would need to hand over the instance as a whole such that all other aspects
> of your application would work with that instance as necessary. This module
> would need to have its own explicit instance of TIB_Session on it that all
> other components would utilize as their IB_Session instance.

Sound great that you (or anyone) sees this as a feasible approach. I'll start mucking around at "my leisure" :)

> I'm not quite sure how you would coordinate an immediate interruption to
> cancel it. Likely you would just hide your splash screen and then set a flag
> to tell it to totally remove itself from the process. This could take some
> time if the thread is actively engaged in an API call of some kind. If it
> was a long-running one there is a facility to notify the server to cancel it
> and return an errcode accordingly. This could be something to look into. I
> have yet to surface all of this in a convenient way in IBO but it is just a
> simple API call with the statement handle so it wouldn't require much.

Well, if the thread .Create()'s the DM then it should be possible simply to abort it or let it whine away? Maybe this will be the more difficult stuff. As I understood it one can abort/destroy a thread. Or maybe this thread will wait for the API (in my case IBO as a consequence) to finish. In that case as you imply, it might be marked as something to be disposed of. I do not think that would be a problem because it's only when the connection has been (thoroughly - metadata read and all) established that the DM would be passed from the thread to the main GUI thread/application. At that point the rest of the app will consider itself as connected.

My "role model" in all this is Sinatica Monitor (http://www.sinatica.com/). It's connection process is dandy and abortable (it's a VS app but that should not have anything to do with anything really). I have it confirmed from the author that the connection is done in a separate thread.

>
> Hope this helps,
> Jason
>

Yes - a lot, because it gives me confidence to move ahead, thanks.

/Dany

Oh, and related to this is an somewhat old post of mine that did not get any attention at all, it has the subject line "". Any comments on that?