Threadlock on a Modeless Dialog

[Carmine]

I'm currently writing a small program that churns on a repetitive task
while displaying a progress & cancel modeless dialog. I've been having
problems due to threadlocking, and I was wondering if anyone could
give me some advice.

Basically when I create the modeless dialog, I'm assuming that C#
under the covers will be implicitly creating a new thread for the
modeless dialog's message pump. Thus I protect the state determiners
with a mutex and a semaphore. But when the main application waits for
the user to push the "Close" button on the dialog the modeless dialog
stops refreshing, as if causing the main app thread to wait stopped
the message pump for the modeless dialog. So it seems like my first
assumption was wrong - .NET doesn't create a new thread to pump the
modeless dialog.

So here are the questions I have:

1) If there is a second thread for the modeless dialog, why is it
freezing?

2) Can you direct me towards a successful modeless progress dialog?

Thanks in advance. :) Here's an overview of the application, in
pseudo-code:

public AppMainClass
{
public bool m_bCancelled;

public void DoWork()
{
// Show a modeless progress dialog.
Progress_Form oProgressDialog = new Progress_Form( this );

oProgressDialog .Show();

bool bDone = false;

while ( bDone == false )
{
// Do work...

// Check if they hit the cancel button.
if ( m_bCancelled == true )
{
bDone = true;
}
}

// Tell the modeless dialog to convert to a "Finished" dialog,
// regardless of whether we've been cancelled or not.

// Wait to close.
oProgressDialog .WaitForClose() ;

// Close the dialog.
oProgressDialog .Close();
}
}
ProgressDialog
{
private Mutex m_oCloseLock;
private AutoResetEvent m_oCloseSignal;
private void FinishButtonCli cked(object sender, System.EventArg s e)
{
// Enter the mutex.
m_oCloseLock.Wa itOne();

// If we're set to close,
if ( FinishButton.Te xt == "Close" )
{
// Release the semaphore to WaitForClose();
m_oCloseSignal. Set();
}
else
{
// Set us as closing required.
m_AppMainClass. InterruptProces sing();
}

// Release the mutex.
m_oCloseLock.Re leaseMutex();
}

public void WaitForClose()
{
// We've been instructed to close.
m_oCloseLock.Wa itOne();

// Change the cancel button text.
FinishButton.Te xt = "Close";

// Release the lock.
m_oCloseLock.Re leaseMutex();

// Block on the semaphore.
// NOTE - THIS IS WHERE THE MODELESS DIALOG FREEZES.
m_oCloseSignal. WaitOne();
}
}

[Joel Hendrix [MSFT]]

You're correct that a message pump isn't set up for you automatically when
you create your modeless dialog. The approach I would recommend would be
to do all of your intensive work on a backround thread that periodically
communicates to the UI thread with progress update. Here's some
pseudo-code on how this would work.

public class MainApp
{
public void FunctionThatInv okesIntensiveWo rk()
{
Thread worker = new Thread(new ThreadStart(Wor kerFunction));
DialogThatDispl aysUpdate update = new DialogThatDispl aysUpdate();
update.Show();
worker.Start();
}

public void WorkerFunction( )
{
while (intensiveWorkN otFinished)
{
// do more work
// communicate back to the UI thread the status of the operation
}
}
}

Here's a great article that discusses this very topic:

http://msdn.microsoft.com/msdnmag/is...g/default.aspx

hth

-Joel
--------------------

From: ca***********@y ahoo.com (Carmine)
Newsgroups: microsoft.publi c.dotnet.langua ges.csharp
Subject: Threadlock on a Modeless Dialog
Date: 28 Jun 2004 13:35:26 -0700
Organization : http://groups.google.com
Lines: 104
Message-ID: <5b************ **************@ posting.google. com>
NNTP-Posting-Host: 65.78.25.41
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google. com 1088454927 28894 127.0.0.1 (28 Jun 2004 20:35:27 GMT)X-Complaints-To: gr**********@go ogle.com
NNTP-Posting-Date: Mon, 28 Jun 2004 20:35:27 +0000 (UTC)
Path: cpmsftngxa10.ph x.gbl!TK2MSFTNG XA01.phx.gbl!cp msftngxa06.phx. gbl!TK2MSFTNGP0 8
.phx.gbl!newsfe ed00.sul.t-online.de!t-online.de!borde r2.nntp.dca.gig anews.co
m!border1.nntp. dca.giganews.co m!nntp.giganews .com!news.glorb .com!postnews2. g
oogle.com!not-for-mailXref: cpmsftngxa10.ph x.gbl microsoft.publi c.dotnet.langua ges.csharp:2547 26
X-Tomcat-NG: microsoft.publi c.dotnet.langua ges.csharp

I'm currently writing a small program that churns on a repetitive task
while displaying a progress & cancel modeless dialog. I've been having
problems due to threadlocking, and I was wondering if anyone could
give me some advice.

Basically when I create the modeless dialog, I'm assuming that C#
under the covers will be implicitly creating a new thread for the
modeless dialog's message pump. Thus I protect the state determiners
with a mutex and a semaphore. But when the main application waits for
the user to push the "Close" button on the dialog the modeless dialog
stops refreshing, as if causing the main app thread to wait stopped
the message pump for the modeless dialog. So it seems like my first
assumption was wrong - .NET doesn't create a new thread to pump the
modeless dialog.

So here are the questions I have:

1) If there is a second thread for the modeless dialog, why is it
freezing?

2) Can you direct me towards a successful modeless progress dialog?

Thanks in advance. :) Here's an overview of the application, in
pseudo-code:

public AppMainClass
{
public bool m_bCancelled;

public void DoWork()
{
// Show a modeless progress dialog.
Progress_Form oProgressDialog = new Progress_Form( this );

oProgressDialog .Show();

bool bDone = false;

while ( bDone == false )
{
// Do work...

// Check if they hit the cancel button.
if ( m_bCancelled == true )
{
bDone = true;
}
}

// Tell the modeless dialog to convert to a "Finished" dialog,
// regardless of whether we've been cancelled or not.

// Wait to close.
oProgressDialog .WaitForClose() ;

// Close the dialog.
oProgressDialog .Close();
}
}
ProgressDial og
{
private Mutex m_oCloseLock;
private AutoResetEvent m_oCloseSignal;
private void FinishButtonCli cked(object sender, System.EventArg s e)
{
// Enter the mutex.
m_oCloseLock.Wa itOne();

// If we're set to close,
if ( FinishButton.Te xt == "Close" )
{
// Release the semaphore to WaitForClose();
m_oCloseSignal. Set();
}
else
{
// Set us as closing required.
m_AppMainClass. InterruptProces sing();
}

// Release the mutex.
m_oCloseLock.Re leaseMutex();
}

public void WaitForClose()
{
// We've been instructed to close.
m_oCloseLock.Wa itOne();

// Change the cancel button text.
FinishButton.Te xt = "Close";

// Release the lock.
m_oCloseLock.Re leaseMutex();

// Block on the semaphore.
// NOTE - THIS IS WHERE THE MODELESS DIALOG FREEZES.
m_oCloseSignal. WaitOne();
}
}

This reply is provided AS IS, without warranty (express or implied).