pinvoke causes loss of modal dialog modality?

[Guest]

have a 3rd party .Net dll that wraps a set of further unmanaged dll's. The
..Net DLL basically uses pinvoke to wrap the calls. The low level dlls
provide an API to talk to a complex device which appears as a USB hub (with a
scanner, flash drive and some other bits and pieces).

Using a VB.Net windows app, we call the main unmanaged API function (lets
call it doStuff() ) and then call messagebox.show to pop up a modal results
dialog. This works OK UNLESS the client app loses while dostuff() is runnning
(takes about 5 - 10 seconds)

If this happens the modal dialog pops up but isn't modal! You can then click
the 'Dostuff' button on the app and call doStuff() again. It's either
resulting in multiple threads of execution or recursive calls to
on_dostuff_clicked ??

This only appears to happen when the client app loses focus while execution
is in the unmanaged code. If it doesn't then the modal is modal.

Anyone come across anything like this before ? Is there any way of
isolating the call to the 3rd party API so it doesn't mess up the calling app?

Cheers,

Rob J

 

[Mehdi]

Using a VB.Net windows app, we call the main unmanaged API function (lets
call it doStuff() ) and then call messagebox.show to pop up a modal results
dialog. This works OK UNLESS the client app loses while dostuff() is runnning
(takes about 5 - 10 seconds)

If this happens the modal dialog pops up but isn't modal! You can then click
the 'Dostuff' button on the app and call doStuff() again. It's either
resulting in multiple threads of execution or recursive calls to
on_dostuff_clicked ??
Anyone come across anything like this before ? Is there any way of
isolating the call to the 3rd party API so it doesn't mess up the calling app?

I do not think that your pinvoke calls have anything to do with the modal
messagebox being not modal anymore. From what you are saying, you have a
form with a Dostuff button on it. When the user clicks this button, your
are calling the doStuff() wrapper method and then MessageBox.Show(), is
that right? It seems a bit strange to me since you are saying that
doStuff() takes 5-10 seconds to execute which means that your app is frozen
during 5-10 seconds whenever the user clicks on the Dostuff button, not
something the users usually appreciate. Are you sure that you are not
starting a thread to do the processing and calling the MessageBox.Show from
this other thread? Also, are you passing a reference to your main form
('Me') as the owner parameter when you are calling MessageBox.Show?

 

[Guest]

I don't want the user to be able to do anything while this eternal API
executes.
I make the call via the supplied .Net API (which in turn pInvokes).
messagebox.show is called immediatly afterwards.

Now for something REALLY odd...

If I run 'Process Explorer' (an exclellent, free sysinternals utility) I can
see the .Net thread count (Under .Net CLR Locks&Threads). If I comment out
the 'messagebox.show' then the thread count is correct and unchanging. IF I
call messagebox.show after the 3rd Party API call the thread count increases
by one each time!!

Now, why on earth would adding a message box call after a (abtracted)
pinvoke cause an extra thread to be created ??