StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
4654833
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
2
CommunityOwnedDate
CreationDate
2011-01-11T06:27:35.317
FavoriteCount
0
LastActivityDate
2011-01-11T06:27:35.317
LastEditDate
LastEditorUserId
0
OwnerUserId
2230
ParentId
4604928
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
Yes. This is common issue in Windows Forms applications, and for that matter in native Windows applications (e.g. those written in C/C++ against the native Windows API). You have different pieces here, but it's the same problem. Let me give you some background: First, you need to know that .NET Events are nothing but a convenient wrap around delegates, intended to make it easy to define methods in your class which "others will implement, and your class will call". Note the difference between that and 'normal' methods, which are those "your class implements and others will call". The key observation is that Events don't know anything about threading. If you think about it, you will realize that that is also true of VB6 events. The second thing you need to know is that Windows controls, which is what VB6 uses, as well as controls in .NET's Windows.Forms world (and WPF for that matter) are bound by what's called thread affinity: they can ONLY be accessed from the thread that created them. Note that Forms (both Windows/VB6 and .NET Forms) are controls themselves (albeit very complicated ones) so this is all true for Forms. Put the two facts together... and you will immediately see what's going on. When your working thread code raises the event, it's just calling the event listener method directly, and it does so from the wrong thread. The moment the event listener method in VB6 (running from the working thread instead of the VB6 main thread) touches any Windows control in your VB6 form, "puff". In the .NET Windows.Forms world, Microsoft did all the really hard work for you. Every Control object (including the Form object) comes with a method called <code>Invoke()</code>. If a working thread has to communicate something to a form/control, it does not manipulate the controls directly. Instead, the form that hosts the control must implement an appropriate delegate, and the working thread calls the form's <code>Invoke()</code> method with that delegate as an argument and possibly some data parameters. <code>Control.Invoke()</code> then takes care of all the threading messiness and makes sure the delegate is called from the thread that created the form and its controls. Finally, the delegate method implemented by the form takes care of manipulating the form's controls on behalf of the working thread. Calling the delegate method directly from a working thread instead of using the <code>Control.Invoke()</code> method is a sure-fire way of crashing the application. Now, I confess: my immediate reaction when I read your question was "Yeah, I know exactly what's going on; I'll just explain..." and then I realized that I only had a faint idea of how the .NET framework actually handles this internally. And then I thought some more, and realized that this was not a simple task at all. No problem! I just loaded <code>System.Windows.Forms.DLL</code> in Reflector to quickly check out the implementation of <code>Control.Invoke()</code>... and felt all the blood drained out of my face. There is some serious ninjitzu going on in there. Go ahead and take a look for yourself. When you are done, you will understand the why of Hans's suggestion -- and that is my suggestion as well: Create a hidden .NET Form. Make sure you <code>new</code> the form from the thread used by VB6. Use the methodology I described above and have the working thread call a delegate in the hidden form via <code>Invoke()</code>. Then the delegate can raise your Event. Everyhing will then work correctly. I know. It sounds crazy overkill to create a hidden window just to change the thread used to call a function; but it's not. You should know that that's exactly how COM handles communications between VB6-style COM objects (called STA objects) and multi-threaded COM objects. Whether or not the extra benefit is worth the hassle, only you can decide. Good Luck. References: <ul> <li>The <a href="http://msdn.microsoft.com/en-us/library/a1hetckb.aspx" rel="nofollow">MSDN topic</a> for <code>Control.Invoke()</code> has an example in VB.NET that can be quickly distilled down to what you need. Add a comment to this response if you have difficulties parsing the example and I'll try to help.</li> </ul>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhat is the correct/best method for threading in a COM exposed assembly?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USEuro Micelli
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POWhat is the correct/best method for threading in a COM exposed assembly?
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COThank you so much for such a detailed answer Euro Micelli, it was exactly the kind of information I was looking for. The extra hassle–annoying though it will be–is definitely going to be worth it. It seems like a lot of effort just to implement a progress bar and a "busy" indicator within the VB6 application, but I think there is little worse than having an application appearing to hang while it does something time consuming.
 singulars
 PostPostId
 PO
 UserUserId
 USAntagony
2. COAnyway, I've now got a basic test working, albeit with one peculiarity: when I call the Invoke method in the working thread, it raises the error *"Invoke or BeginInvoke cannot be called on a control until the window handle has been created."* If I stopped execution after creating the new form and queried it's handle, it returned a valid value; if I then continued execution it worked okay. So I've put a line in dimensioning a variable to the form's handle and that seems to fix it, but I'm not sure if that's the right thing to do. What do you think?
 singulars
 PostPostId
 PO
 UserUserId
 USAntagony

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.