Re: Controls.add() - C# Discussion Boards

7-Jan-06 9:45

What do I use instead of addressof.I am trying to p/invoke Win32 API CreateThread in a C# application.One of the API's parameter is the address of the function which the thread will execute.

leppie7-Jan-06 10:02

leppie

7-Jan-06 10:02

Ok, let me understand. You want to use an API function and you dont understand what it does? But if you do, why on earth dont you use the System.Threading.Thread class? Sigh | :sigh:

^{xacc.ide-0.1.1.4 - now with LSharp integration and scripting :)}

Bassam Saoud7-Jan-06 10:18

7-Jan-06 10:18

That is a long story...

Dave Kreskowiak7-Jan-06 13:53

7-Jan-06 13:53

And problably one based on some incorrect assumptions.

By using the unmanaged Win32 thread functions, you introduce garbage collection issues with your managed code being executed from an unmanaged thread.

There is no reason I can think of that would be good enough to justify this.

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

leppie8-Jan-06 0:11

leppie

8-Jan-06 0:11

I was really hoping he would entertain as with the 'long' story... D'Oh! | :doh:

^{xacc.ide-0.1.1.4 - now with LSharp integration and scripting :)}

Dave Kreskowiak8-Jan-06 2:49

8-Jan-06 2:49

So was I.

Bummer....

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

Bassam Saoud8-Jan-06 8:05

8-Jan-06 8:05

You want entertainment…… well you got it! :
I have a C# application that invokes COM objects. I need to stop a COM instance from executing when it executes more than a predefined amount of time. Each COM instance is assigned a thread.

System.Thread.Abort() does not achieve that result because when calling Abort() on a thread, if the thread is currently executing native code (or COM in my case), nothing will happen until the thread returns to managed code. To solve the problem I thought with the help of the forum of these solutions:

1. Creating an exe (Process) that invokes the COM and assign a thread to a function that launches that exe. When a thread aborts, I will kill the exe and stop the COM execution. This approach has worked.

2. Create a MTA COM component that spawns a native thread and the COM object with methods added to the abort the Native threads.

3. Instead of using Managed Threads, I can P/Invoke Native threads by using the CreateThread/ExitThread/TerminateThread API. Aborting threads occurs in a rare occasion.

I appreciate any useful comment.

Bassam Saoud8-Jan-06 8:08

8-Jan-06 8:08

If anyone is interested ,delegates are used instead of addressof.

Dave Kreskowiak8-Jan-06 13:17

8-Jan-06 13:17

Well, it took me looking into your message histroy to see what's you're really trying to do here. Launching multiple instances of VB6-created .DLL, COM based. Hmmmm....interesting since VB6 runtime doesn't support threading, directly anyway.

Creating a seperate .EXE will work, since each launch of the .EXE will, of course, spawn on it's own thread. This will also make any communication with the instance of the .DLL a huge PITA, since now your crossing a Process boundry. I hope this .DLL doesn't do anything useful to the form.

In my opinion, option number 2 is your best bet. Keep manangement of the unmanaged threads in a COM-based component that exposes any interface your .NET app can use to control the launching and shutdown of the VB6 component instances. This COM component can also handle communication to and from the VB6 stuff for your Managed code to.

Why do I say this? Because in your original post, that you didn't tell us anything about, it sounds like this VB6 component could be replaced sometime in the future. By creating a wrapper for the VB6 threads, you can easily replace this interface component with a different interface when the VB6 component is finally replaced by managed code.

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

Bassam Saoud8-Jan-06 21:23

8-Jan-06 21:23

I needed a quick answer to a quick question!

I am working on Options 2 and 3(Option1 is done) in parallel since they hold the same complexity which is mainly working with unmanaged threads.In both cases i am creating a wrapper to the COM either with creating COM-based component or a .net assembly or class( never figured it out yet).The problem i am facing is how to stop a thread execution.TerminateThread is not the answer(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/terminatethread.asp[^]), how to gently terminate a thread keeping in mind that the COM source code cannot be changed.Any code can only be added to the Wrapper.

Dave Kreskowiak9-Jan-06 2:15

9-Jan-06 2:15

You don't have a choice here. Either your VB6 code was written to terminate itself property on some flag, or you'll have to forcefully kill it, which will lead to memory and handle leaks.

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

Bassam Saoud9-Jan-06 3:06

9-Jan-06 3:06

Thanks man i appreciate it..

Bassam Saoud9-Jan-06 3:06