Hi to all,
well i've a little about vb thread behaviour when creating a new instance of an object
If we've imported a dll activex that contains only one object that support both thread apartment
what happens when vb executes the new object1 statment?

The thread is already registered into the subsystem COM as STA?
When instancing a new object thats compatible with the STA (the client apartment) this thread is locked into its STA with the instance it created right ?
What happens if in the following line we try to create another instance of the object (this is not an exe activex but a standard exe) ?
The actual thread is already locked into a STA with the previous instance of the object so what do vb and com do ?

Tnx a lot
NikDH
Posted on 2002-03-04 20:39:16 by NikDH
If I read you right, the client app in VB doesn't create a new thread before calling the new object method, so it just creates another instance of the object. They run independently, consequatively, meaning a method in one object must return before a method in the other object is called.

A dll contains classes, and a class may generally make as many objects as you with it too.
Posted on 2002-03-04 23:48:50 by Ernie

If I read you right, the client app in VB doesn't create a new thread before calling the new object method, so it just creates another instance of the object. They run independently, consequatively, meaning a method in one object must return before a method in the other object is called.


Hi ernie,
but if a thread already stays in a STA can the same thread stay in another STA with another instance of the object ?

Tnx a lot
NikDH
Posted on 2002-03-05 08:38:39 by NikDH
From what your describing, the main app/thread creates an object, then another instance of that object, does not create any more threads.

Yes, they both run quite happily in the same thread. It's the same as dropping two command button objects on a form. The two instances run independently of each other.
Posted on 2002-03-05 22:59:57 by Ernie

Yes, they both run quite happily in the same thread. It's the same as dropping two command button objects on a form. The two instances run independently of each other.


Hi ernie,
well i've a little doubt more about how those 2 button in the same thread fire event
Being in the same thread doesnt create problem in calling their methods of coz
but how they fire their events ?
They cant install a wndproc coz it would mean they should implement cycle to dispatch msgs in queue and that would mean they should create another thread
coz GetMessage() is blocking
So when u add a button to a form the button asks the form it stays in to be notified of all window msgs so it can fire its events?
How is it implemented ?

Tnx a lot
NikDH
Posted on 2002-03-07 03:46:21 by NikDH
COM objects can source or sink events by using (remarkably enough) COM Interfaces.

The event source (typically the server) will impliment IConnectionPoint to advertise it has outgoing (sources) events. A client can QueryInterface for this to hook itself up.

A client hooks itself up by sending an interface pointer to the server, so the server knows where to send the events. When the client is done receiving events, it can tear down the interface connection.

You might want to check out some tuts on sinking and sourcing events (in wonderful win32asm code). MSDN will have other info too on IConnectionPoint.
Posted on 2002-03-07 15:14:35 by Ernie