is this the right way to do multithreading

[alexl]

I derive an object from a Form and instantiate it like this

//sc is the instance of an object derived from Form

Thread t = new Thread(() =>
{
IntPtr dummy = sc.Handle;
//above statement creates the window

Application.Run();
});

then when I want to call a method of sc from the other thread I do

sc.BeginInvoke (....);

thanks

 

[Peter Duniho]

I derive an object from a Form and instantiate it like this

//sc is the instance of an object derived from Form

Thread t = new Thread(() =>
{
IntPtr dummy = sc.Handle;
//above statement creates the window

Application.Run();
});

then when I want to call a method of sc from the other thread I do

sc.BeginInvoke (....);

You can do it that way. But there's nothing in your question that
suggests that you _should_ do it that way.

Typically, you would just use the main thread that already is created
for a Forms application as the owner thread for all GUI objects (e.g.
Form subclasses). Then non-GUI code can execute on other threads, using
Control.Invoke() or Control.BeginInvoke() to access the GUI objects.

The code snippet you posted will create a new thread, force the creation
of the Form subclass's window handle in the new thread, and then start a
message pump loop to handle messages in that thread. But a) for that
code to work, you have to be very careful that the Form subclass's
window handle isn't created earlier, and b) it's unclear what benefit
you expect to get by forcing the Form subclass to be owned by a new
thread rather than the one that would normally be used.

Pete

 

[alexl]

thanks for your answer.

it's unclear what benefit
you expect to get by forcing the Form subclass to be owned by a new
thread rather than the one that would normally be used.

I am using a sdk that uses COM so I thought I have to keep its thread
separate. The sdk in question is UCCApi. thanks