VB crash
-
Hi all, I have developed a ATL in-proc server (dll) that exposes some COM objects, and these have some events. I have to fire events in a separate working thread I spin when the library is loaded. So the event consumer is serviced in another thread. When I use this in a VB6.0 application all works well but if I attempt to debug the event, placing a breakpoint in the event sub, the breakpoint is hit, but then the VB IDE crashes and suddenly disappear. I registered the COM object apartment as BOTH. So what is the problem? Could you please help me? Many thanks and HAPPY NEW YEAR !!!! Regars, Andrea
-
Hi all, I have developed a ATL in-proc server (dll) that exposes some COM objects, and these have some events. I have to fire events in a separate working thread I spin when the library is loaded. So the event consumer is serviced in another thread. When I use this in a VB6.0 application all works well but if I attempt to debug the event, placing a breakpoint in the event sub, the breakpoint is hit, but then the VB IDE crashes and suddenly disappear. I registered the COM object apartment as BOTH. So what is the problem? Could you please help me? Many thanks and HAPPY NEW YEAR !!!! Regars, Andrea
In short : The interface pointer used by your worker thread to fire the events is not valid for the worker thread. In length (there are numerous resources on the web that discusses this problem): http://www.mvps.org/vcfaq/com/1.htm[^] It's doesn't matter that the object is martked 'Both'. VB instansiates it in an STA. In detail: When you fire the event in your worker thread that thread executes native VB code. VB assumues that the thread that calls it is always the same thread (the same requirement as for the STA). VB tries to get data in the TLS but since it is the wrong thread that calls VB, VB will sometimes throw access violation (if you're lucky). If the object would've been marked 'Free' (an MTA object) then VB (or rather the COM-runtime) is forced to instansiate the COM object in the MTA. If the worker thread then also enters the MTA (by calling CoInitializeEx with argument COINIT_MULTITHREADED) then it's legal for the worker thread to fire the events in the way the VC 6 wizard generates the event-firing code. In this case COM will automatically put up proxy/stub pairs between the VB and your object ensuring that it's the correct thread that calls the VB code. The drawbacks are: 1. Performance (every call is marshalled and will force a thread switch, few calls = no problem, many calls = large performance hit) 2. You must secure your object for concurrent access (but since it was marked 'Both' it should've been secure already 3. An MTA object _can not_ be an ActiveX object (that is a COM object with UI) A peculiar detail is: 1. When the VB code calls your object the COM runtime will pump the message loop.