Mark Hammond schrieb: > The problem is that the connection server is getting an interface object on > one thread (the main thread as part of the Advise call) - but the new > threads you create are using these objects without marshalling the objects. > > ie, your new threads are referencing objects "owned" by another thread. > This is why the calls are being delivered to VB on the wrong thread. If you > marshalled the objects to the new thread, that marshalling would ensure VB > received the call on the correct thread. > > You marshall the COM object by using CoMarshalInterThreadInterfaceInStream > and CoGetInterfaceAndReleaseStream. > > win32com.server.connect wasn't really designed for this case - > 'self.connections' can only be used directly or indirectly by thead the > Advise call was made on. Each thread must have its own copy of the > interfaces in self.connections, passed to it via > CoMarshalInterThreadInterfaceInStream. This will be tricky to work with new > connections established after the thread has started. One option may be a > queue - the "main" thread could queue CoMarshalInterThreadInterfaceInStream > wrapped objects, and the worker thread could dequeue the objects and call > CoGetInterfaceAndReleaseStream before attempting to use the object. > > If you could make sensible modifications to win32com.server.connect to > support that scenario, I'd be happy to integrate them. You may find it > easier to "fork" that class for your own purposes though. >
Another (easier, imo) option would be to use the Global Interface Table. Once that is wrapped in win32com. Thomas _______________________________________________ Python-win32 mailing list Python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
