[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1084
  • Last Modified:

How to close a messageBox soon after user response on a windows form

I have a windows parent form, on which I open a MessageBox.
I need to close the MessageBox soon after user responds to the Yes or No buitton
The issue is when the user clicks No, the messagebox closes fine, but when the user clicks Yes, the MessageBox remains open until the method transferRecord() does its processing.

I need to close the MessageBox, soon after the user clicks Yes and then do the transferRecord() processing
here is my code

   private void transferPB_Click(object sender, EventArgs e)  
{
       foreach( conditon xyz)        
              {              
     DialogResult result = MessageBox.Show(this,"Do you want to transfer records with errors?","Data    Transfer",MessageBoxButtons.YesNo,MessageBoxIcon.Question,MessageBoxDefaultButton.Button1);
                             if(result   == DialogResult.Yes)
                            {
                                break;
                            }
                            else
                            {
                                //The user clicked the NO button.                              
                                return;
                            }
                       }
              transferRecord();
}
0
countrymeister
Asked:
countrymeister
1 Solution
 
Wayne Taylor (webtubbs)Commented:
Hi countrymeister,

Use Application.DoEvents()

Regards,

Wayne
0
 
Mike TomlinsonMiddle School Assistant TeacherCommented:
To be more specific, call it just before you execute transferRecord();

    Application.DoEvents();
    transferRecord();

The reason the MessageBox doesn't "go away" is the parent form must repaint itself...but it is too "busy" executing code in the transferRecord() method.  The call to DoEvents() forces the application to process all pending messages in its message queue.
0
 
Dorfer32Commented:
The earlier answers are correct: by flushing the application event queue you will hide that dialog box; however, you will still "hang" the client UI (whatever form the user returns to after that box is closed) because you are doing such a long operation on the gui thread.  To avoid this you may want to run your record transfer routine on a worker thread:

private void transferPB_Click(object sender, EventArgs e)  
{
    foreach( conditon xyz)        
    {              
    DialogResult result = MessageBox.Show(this,"Do you want to transfer records with errors?","Data    Transfer",MessageBoxButtons.YesNo,MessageBoxIcon.Question,MessageBoxDefaultButton.Button1);
        if(result   == DialogResult.Yes)
        {
            break;
        }
        else
        {
            //The user clicked the NO button.                              
            return;
        }
    }

    // Execute transfer in another thread so UI can go about its business
    new Thread(transferRecord).Start();
}
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
Mike TomlinsonMiddle School Assistant TeacherCommented:
"run your record transfer routine on a worker thread"

Then you may also need to take into account "cross thread operations" and use Delegates/Invoke() if the transferRecord() method does any updates to GUI controls...
0
 
Dorfer32Commented:
Yes, when you bring multi-threading into the picture additional concerns do come up.  Circumstantial evidence in this case would lead me to believe the original poster should be fine though...  In other words with a method name like "transferRecord" which presumably takes a while to execute I can't help but think it's transferring data around (over a network or waiting for disk or something), not updating other controls (typically fast)...  but you are of course correct if he does happen to make calls back to the form they will need to be invoked properly.  We can cross that bridge when (if) we get there...

I still consider threading out the long operation as a better solution than simply flushing the event queue.  Flushing the event queue will just cause the application to hang the moment after the dialog disappears instead of the moment before.
0
 
countrymeisterAuthor Commented:
Idle_Mind:

Thanks for the answer and the explanation on why, which is very important for a learner to know.
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now