Ross,
You might want to try GThreadCop here
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=3
cba64b4-3765-49ba-8a05-11d247195e65
It will tell you if you are breaking the (UI rule).
Often this will cause deadlock.
-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Ross Diesel
Sent: Wednesday, April 20, 2005 4:48 AM
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] UI thread problems - further insight
Hi Chris
Apologies, I misintrepeted your original post.
I do create a ui thread synchronization object on the main ui thread.
This
ui sync object derives from Form and is passed to the background thread
as
ISynchronizeInvoke.
My problem is that when I do a Invoke on the sync object, it marshalls
the
call across to the main ui thread and then creates a new modeless form
(which I understand is basically what you're proposing), however this
new
form and the app mainForm are subsequently frozen and I am also unable
to
parent additional controls to the new form - Spy++ shows that the new
form
(or its window) has been created on the background thread in this
situation.
I am preparing sample code which will be posted which demonstrates what
I am
battling to convey in these posts.
regards
-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] Behalf Of Chris Day
Sent: 20 April 2005 09:25
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] UI thread problems - further insight
Okay here is your problem, you say that the background threads can't
access the mainForm by design.
YOUR DESIGN IS WRONG!!!!
Simple solution is to pass the mainForm, or some control that's been
created on the UI thread to the background thread. Then any UI work can
be sent via Invoke as I described below.
If you don't want to pass in an instance of a Form (or Control) then
define a delegate on your side which when the main form starts up
background processing it can pass it in, then your background thread
calls the delegate. The function the delegate points to (in this case on
the form) can call Invoke on itself to the UI thread. If you want I can
send some example code, but I think it is fairly straight forward.
If you still don't think you should change the design...WHAT YOU WANT TO
DO WILL NEVER EVER HAPPEN!
HTH :))
Regards,
Chris
-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Ross Diesel
Sent: Wednesday, 20 April 2005 4:57 PM
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] UI thread problems - further insight
I don't have access (by design) to mainForm from the background thread
(one
of the drawbacks of a tightly coupled event mechanism such as
delegates).
My background thread receives events from hardware devices which may
cause a
background session (on a seperate thread) to be initiated. I'm using
configuration to define the presentation workspace for each type of
session
eg a new session activated by a specific event might require a new
modeless
form with a couple of perspectives (Eclipse terminology) hosting various
views. Another session might require only a single view to be created in
the
main application form which was launched on startup - this would only
require the framework to new up an appropriate control (eg panel with
embedded web browser) and then parent it to the existing form.
My problem is that I cannot statically define the forms and their
contents
as its a presentation framework which is going to be required to be used
in
any number of ways by different customers.
regards
-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] Behalf Of Chris Day
Sent: 20 April 2005 01:02
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] UI thread problems - further insight
Is there a reason why you can't invoke a delegate on the UI thread (from
the background thread) which constructs and displays the modeless form?
private void myBackgroundThread(Form mainForm)
{
// do stuff
If (someCondition)
{
mainForm.Invoke(new OpenModelessFormDelegate(OpenModelessForm),
null);
}
// do stuff
}
private delegate void OpenModelessFormDelegate();
private void OpenModelessForm()
{
ModelessForm myModelessForm = new ModelessForm();
myModelessForm.Show();
}
-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Ross Diesel
Sent: Wednesday, 20 April 2005 12:46 AM
To: [email protected]
Subject: [ADVANCED-DOTNET] UI thread problems - further insight
Hi
Have managed to further refine the UI thread problem reported in earlier
posts.
Basically the problems manifested themselves as UI deadlock and control
parenting exceptions when trying to initiate forms creation from a
background thread using a synchronization object. The synchronization
object
is obtained by subclassing the System.Windows.Forms.Form class.
Using Spy++, it can be seen that when the synchronization object is used
from a background thread in order to create a new Form on the main UI
thread....
then, even though the synchronization object and the Forms ctor
report
the current thread as being the main UI thread, the Form is actually
being
created on the background thread.
After the ISynchronizeInvoke::EndInvoke completes (inline wait on the
IAsyncResult), both the main form (launched on startup) and the new
modeless
form fail to respond further to user input. Spy++ shows no message
processing activity on the respective windows.
Future attempts to interact with the modeless form from the background
thread either meet with an exception (cannot parent controls created on
another thread) or hang (probably because ISynchronizeInvoke::Invoke was
being used instead of ISynchronizeInvoke::BeginInvoke).
So my question now is...
Is it possably to initiate the creation of a modeless (to the main app
form)
form from a background thread, and if so, how?
thanks
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
########################################################################
####
#########
This e-mail message has been scanned for Viruses and Content and cleared
by NetIQ MailMarshal
########################################################################
####
#########
===================================
This list is hosted by DevelopMentor. http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
########################################################################
####
#########
This e-mail message has been scanned for Viruses and Content and cleared
by NetIQ MailMarshal
########################################################################
####
#########
===================================
This list is hosted by DevelopMentor. http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does
not waive confidentiality or privilege, and use is prohibited.
===================================
This list is hosted by DevelopMentor� http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
