Threading issue with multiple forms

[Earl]

I think I see the problem, not as sure I see an easy answer ....

..Net 2.0 CF app with a handful of forms. On the splash form, I have a
notification control. In the module, I have an incoming message stream. When
I get a message, I show the notification control ... this is where the
problem lies.

How I see it:
Thread T1 starts when frmSplash is activated
Thread T2 starts when the message component is created in the module
Thread T3 starts when the notification is called from the module message

My understanding of 2.0 is that this sort of freeze can occur if a "UI
element is not called on the thread where it was created".

Back to the problem: Once the notification appears, it will not fire the
responsesubmitted event when I click on the URL. I've tested the
notification and responsesubmitted event and the event fires properly if
called from the form where it occurs (frmSplash). But this is without the
message stream coming from the module. Any threading experts see my issue?

 

[Guest]

Just as with CF 1.0, the desktop framework, or even unmanaged code, all
calls which involve a Window (and all controls are Windows) must be done
from the creation thread, which is typically the process' primary thread.

Your problem may be a bit different, as CF 2.0 with thro an exception if it
detects you're breaking this rule.

In this case, the notification is likely coming back as a message posted to
the creator's message pump. If you used ShowDialog, that generates it's own
pump, and one the dialog is no long there, neither is its pump. The message
comes in, but with a target hWnd that doesn't match any hWnd in the app, so
the framework assumes it's not for our current app and ignores it. You can
test this by creating the notification from your main Form or through an
IMessageFilter.

-Chris

 

[Earl]

Thanks Chris. That is definitely on the right track to my problem, but I'm
unsure how to fix it. I've tried a delegate using Control.Invoke, but that
does not solve the problem. I indeed had tested this by calling the
notification from within the main (splash) form and it functioned properly.

The creator's message pump is from an IPWorks component, and does run on its
own thread. Their documentation is quite sparse in this regard and I've
found no documentation on point (their techs are quite helpful to their best
ability tho, so I do recommend them highly as a company, this issue
notwithstanding). They basically say to use a delegate with Control.Invoke
to move off of their thread to the main UI thread, but this is apparently
either not the issue or I'm not seeing it clearly.

I've also tried to create the notification control completely in code, with
a Friends WithEvents declaration in the module and then creating a new
notification object at the moment I enter the notification display code.
Again, the control works perfectly if called by the main splash form
directly, but will not fire the ResponseSubmitted event if called via the
module/message code.

Do you have a recommendation for restructuring the code that might alleviate
this complexity or any other workaround?

 

[Guest]

Without knowing how it's architected I can't say for sure. I can say that
if you don't use Invoke and it doesn't throw an exception, then the Invoke
is not needed and is not the problem. I think it's simply a message pump
issue. Again, I'd be inclined to add an IMessageFilter to my app and see if
the message ever comes in at all. If it does, then decide how to handle it
then (probably just in the filter).

Then if you're going far enough to add an IMessageFilter, you could use the
SDF's notification stuff as well.

-Chris

 

[Dick Grier]

Hi,
They basically say to use a delegate with Control.Invoke
to move off of their thread to the main UI thread, but this is apparently
either not the issue or I'm not seeing it clearly.
<<

Show the syntax that you are using (I do have IPWorks, so I might be able to
test something). You will need to marshal using .Invoke on some sort of
delegate routine.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[Earl]

I am not familiar with IMessageFilter. Looking it up in the VS2005
documentation is not terribly helpful, but I have been digging thru some
posts and I see a lot of references to the OpenNetCF package also. I have
not installed that onto the IDE, but I'm guessing this would be helpful in
this regard?

 

[Paul G. Tobey [eMVP]]

IMessageFilter is part of OpenNETCF SDF, *not* the Compact Framework itself.

Paul T.