By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,505 Members | 1,206 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,505 IT Pros & Developers. It's quick & easy.

Addhandler in a Multithreading class and the events raised in seperate threads, how to get to the caller thread?

P: n/a
Hello,

I have a problem and I can't get the solution for it :(

I have a com dll, which i imported as a reference. The com object is
part of a class which is multithreaded and will create seperate objects
which we can and must control. On these com objects I added the events
via AddHandler. This is working great, I can see that my threads are
raising events through the com object.

Now the following problem arises: These events will run in a seperate
process and will not pass the correct objects (out of the caller
threads), so I can not see wich event is raised by which thread. When I
add data to a global var, it will be overwritten by the last call we
have made, so this is not accurate too. Can I make connection to the
caller thread (on the event which has been called)? Can you point me in
the right direction, I think it's possible, but...

ohhh, I've tried to call the com object with the WithEvents statement,
but this will overwrite the eventhandler....

Thanks in advace!!

Daan

Jul 29 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Can anybody please help me with this issue?

da**@dnc.nu wrote:
Hello,

I have a problem and I can't get the solution for it :(

I have a com dll, which i imported as a reference. The com object is
part of a class which is multithreaded and will create seperate objects
which we can and must control. On these com objects I added the events
via AddHandler. This is working great, I can see that my threads are
raising events through the com object.

Now the following problem arises: These events will run in a seperate
process and will not pass the correct objects (out of the caller
threads), so I can not see wich event is raised by which thread. When I
add data to a global var, it will be overwritten by the last call we
have made, so this is not accurate too. Can I make connection to the
caller thread (on the event which has been called)? Can you point me in
the right direction, I think it's possible, but...

ohhh, I've tried to call the com object with the WithEvents statement,
but this will overwrite the eventhandler....

Thanks in advace!!

Daan
Aug 1 '06 #2

P: n/a
da**@dnc.nu wrote:
Can anybody please help me with this issue?
Well, I'll give it a go, but this isn't really my area...
>
da**@dnc.nu wrote:
>Hello,

I have a problem and I can't get the solution for it :(

I have a com dll, which i imported as a reference. The com object is
part of a class which is multithreaded and will create seperate objects
which we can and must control. On these com objects I added the events
via AddHandler. This is working great, I can see that my threads are
raising events through the com object.

Now the following problem arises: These events will run in a seperate
process and will not pass the correct objects (out of the caller
threads), so I can not see wich event is raised by which thread. When I
add data to a global var, it will be overwritten by the last call we
have made, so this is not accurate too. Can I make connection to the
caller thread (on the event which has been called)? Can you point me in
the right direction, I think it's possible, but...
I don't know how much this is an interop problem and how much it is a
multi-threading problem. Therefore I can only suggest fixing the
threading issues: have locks for each object that is shared or
accessible from more than one threads, and religiously SyncLock before
doing anything to these objects. Then try again, and see if you still
get problems. If you do, it's something on the interop side. If you
don't, then great, we've just done a practical demonstration of the
importance of controlling access to contended resources.

Tell you what, maybe you could mock up a .NET component that exposes the
same behavior as the com component, and plug that in, to see if it's
interop or threading that's the problem?

--
Larry Lard
la*******@googlemail.com
The address is real, but unread - please reply to the group
For VB and C# questions - tell us which version
Aug 1 '06 #3

P: n/a
Hi Larry,

Synclock would be a problem because of the asynchronous way events are
raised by the com object... We synclock the first object, the events
raised knows it has something to do with the first lock object, we
release the synclock, than the second object is created with a
synclock. Now the issue rise, what if when events are fired for the
first object, it will retrieve the information for the lock, and the
wrong information is handled

I think I can code to the solution when I know how to get to the caller
thread, then I can receive the correct object.

Thanks!

Larry Lard wrote:
da**@dnc.nu wrote:
Can anybody please help me with this issue?

Well, I'll give it a go, but this isn't really my area...

da**@dnc.nu wrote:
Hello,

I have a problem and I can't get the solution for it :(

I have a com dll, which i imported as a reference. The com object is
part of a class which is multithreaded and will create seperate objects
which we can and must control. On these com objects I added the events
via AddHandler. This is working great, I can see that my threads are
raising events through the com object.

Now the following problem arises: These events will run in a seperate
process and will not pass the correct objects (out of the caller
threads), so I can not see wich event is raised by which thread. When I
add data to a global var, it will be overwritten by the last call we
have made, so this is not accurate too. Can I make connection to the
caller thread (on the event which has been called)? Can you point me in
the right direction, I think it's possible, but...

I don't know how much this is an interop problem and how much it is a
multi-threading problem. Therefore I can only suggest fixing the
threading issues: have locks for each object that is shared or
accessible from more than one threads, and religiously SyncLock before
doing anything to these objects. Then try again, and see if you still
get problems. If you do, it's something on the interop side. If you
don't, then great, we've just done a practical demonstration of the
importance of controlling access to contended resources.

Tell you what, maybe you could mock up a .NET component that exposes the
same behavior as the com component, and plug that in, to see if it's
interop or threading that's the problem?

--
Larry Lard
la*******@googlemail.com
The address is real, but unread - please reply to the group
For VB and C# questions - tell us which version
Aug 1 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.