Complex Threading - 3-rd Party DLL Which Require Hardware Components And Special Software Installs

The problem I have is very complex and relates to an 3-rd party DLL which require hardware components and special software installs, so unfortunately, I can't post any code so the problem can be replicated. What I can do is provide a very detailed text description and ask for some opinions...

So, here goes...I'm doing a project that uses an old DLL that exposes functions that communicate with a specialized program and call these all the time. I've imported the functions using <DLLImport> tags. The functions themselves return a int > 0 if it run ok and <= 0 if it failed. Part of the problem is that only one function can be performed at a time and if several commands are activated in short amount of time, the connection to the DLL stops working and all function calls return fails. Initially I've had problems using threading with this DLL until I removed it all (some functions would not perform at all, others returned fails, etc.).

My program communicates with the DLL with no problem... All calls are normally returned and executed and everything works perfect... UNTIL the user clicks a little too fast.

So, the user has a form on which he activates these function calls, and if he doesn't wait long enough for the first call to the functions to end, the DLL connection 'fails', after which the program has to be restarted (reinstancing the class containing the <DLLImports> doesn't help for some reason?).

After a week of testing and GoogleFixing, I've tried almost everything:

1) I've made the functions calling DLLs store a bool variable Working and then wait for that to be free - this didn't help as apparently the connection breaks before even coming to the code, which suggests a threading problem (explained further down)

2) I've tried adding <STAThread> to DLL function declarations

3) I've tried messing around with <DLLImport> attributes

4) I've added SyncLock to function calls

5) I've added a loop with sleep on the calling code to make it to 'wait' for the work to end

All of these didn't help, just showed that the DLL connection fails even WITHOUT repeated calls to the DLL... So, the only thing that did help is disabling the controls starting the calling process on the form...

For example:

CODE:

This is of course a stupid way to treat the problem's symptoms (the source eludes me) and inpractical since the calls are made from about 40 different places in the code and I'd have to disable ALL forms/controls starting this calls to be fully safe, which is nearly impossible in practice.

So, entering any code already causes a problem, which is why I've came to the conclusion that this is a threading problem...

I execute all the function calls from the Main Thread (like I said, all past threading was removed due to problems communicating with DLL), yet for some reason the form keeps the focus and the user can click away (most likely because the DLL is working at the time and the form keeps the focus?), either messing around with the Main Thread or creating a new one which seems to break the DLL.

So, assuming that no one comes up with a magical one-line solution at least answering these questions would be very helpful:

1) Is there a way to fully disable control over the program to the user in a simple way while the code is executing (something like Application.enabled = false)?

2) Can Main Thread be disabled from reacting at other points in the program in some way until a code finishes?

3) How can <DLLImport> lines be restarted if reinstancing the class containing them doesn't help (I'm seeing this as a memory/cache problem of some sort, since after program restart, everything works fine)?