ShowDialog Being Skipped

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a method that gets a screen of user input. The method has this in it:

public static bool getscrn(ScreenData SD)
{
GetForm form1 = new GetForm(SD);
form1.ShowDialog();
if (form1.DialogResult == DialogResult.OK)
return true;
else
return false;
}

Generally this works fine, the user enters their input into the screen,
presses OK or cancel, and the application keeps running. But sometimes it
fails, if there are two calls in a row, like this:

if(getscrn(SD1)){
var=true;
}
if(getscrn(SD2){
etc.
}

In this case, sometimes, if the user pressed Cancel on the first getscrn()
call, then the second call fails, it flashes the input screen up for a
moment, then returns to the application, with a status as if the user had
pressed Cancel in the second call also. If they press OK in the first call,
everything is fine, the second asks for input. And in some of my
applications, it works after a Cancel, in others it fails. If I put a
MessageBox.Show() in between the getscrn() calls, everything is always fine,
it waits for the MessageBox response and the getscrn() response.

So something seems to be being set in the first call, that is affecting the
second call, but I can not figure out what. There is no static data in
GetForm(), I dispose of the resources before getscrn() is complete.

Any suggestions about what the problem could be would be appreciated. Thanks.
 
Hi Richard,

Thank you for posting.

I wonder what the "ScreenData" is? Is it a class that you have generated,
or something else?

For the further research, would you please send me a sample project? To get
my actual email, please remove the "online" from my displayed email
address. Thanks.



Sincerely,
Linda Liu
Microsoft Online Community Support

====================================================
When responding to posts,please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
====================================================
 
Richard MSL said:
I have a method that gets a screen of user input. The method has this in
it:

public static bool getscrn(ScreenData SD)
{
GetForm form1 = new GetForm(SD);
form1.ShowDialog();
if (form1.DialogResult == DialogResult.OK)
return true;
else
return false;
}
Click to expand...

You could simplify this as follows:

\\\
public static bool GetScreen(ScreenData SD)
{
using (GetForm form1 = new GetForm(SD)
{
return (form1.ShowDialog() == DialogResult.OK);
}
}
///
Generally this works fine, the user enters their input into the screen,
presses OK or cancel, and the application keeps running. But sometimes it
fails, if there are two calls in a row, like this:

if(getscrn(SD1)){
var=true;
}
if(getscrn(SD2){
etc.
}
Click to expand...

Are you using different threads which call the method?
 
Thanks for replying. Yes, ScreenData is a class that contains the information
about what fields to input from the user. I am not using multiple threads,
though my project contains C, C++ and C# code, the input is done in the C#
section, the application is in C. I am not ready to make a sample project, as
it works in some of my instances and fails in others, I am first going to
reduce it down to see what is required to produce the error. I just wondered
if anyone had some suggestions about what existing condition could make a
ShowDialog() call fail. I will work on it some more, and may get back to you.
Thanks again.
 
Hi Richard,

Thank you for your response.

I have set up a project for test based on your code. The only difference
between my code and yours is the removal of the ScreenData parameter in the
getscrn() static method. It works fine whether I presses OK or Cancel in
the first getscrn() call. The application keeps running and the second form
appears.

I think the problem might be due to the use of the ScreenData class.

I haven't found any document on what condition could make a ShowDialog()
call fail yet.

I am looking forward to your further feedback.


Sincerely,
Linda Liu
Microsoft Online Community Support

====================================================
When responding to posts,please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
====================================================
 
Thanks. I have further determined that it is related to my ComboBox class,
when there is a ComboBox in the first call, then the second one fails. I am
going to rewrite my ComboBox class, which I had to do anyway, that should
likely deal with it.
 
The problem comes from my implementation of my ComboBox. It is from when the
user presses Esc, and the ComboBox is not dropped down. In that situation, I
want the form to close, as if the user had clicked the Cancel button. Here is
my KeyDown method, that detects that they pressed Esc, and that the combo box
was not dropped down:

private void TComboKeyDown(object sender, KeyEventArgs e)
{

if (e.KeyCode == Keys.Escape)
{
MinoCombo ACombo = (MinoCombo)sender;
if (ACombo.DroppedDown == false)
{
this.ParentForm.Close();
// this.CausesValidation = false; // does nothing.

}
}
}
The problem is that the ParentForm.Close() gives me the behavior that I
want, except that it also causes the next input screen to close also, without
accepting input. The CausesValidation does nothing, if I use that instead,
the user presses Esc, and nothing happens, the focus is still in the
ComboBox. I have also tried to InvokeOnClick the Cancel button, it does the
same thing as ParentForm.Close(); it closes the form, but also the next one.

If you can tell me a way to close the current form, without affecting the
next one, I would appreciate it. Thanks.
 
Hi Richard,

Thank you for posting.

Have a try replacing the sentence "this.ParentForm.Close()" in the
TComboKeyDown() method with the sentence "this.DialogResult =
DialogResult.Cancel".

Hope this is helpful to you.

If you have any concerns or need anything else, please don't hesitate to
let me know.


Sincerely,
Linda Liu
Microsoft Online Community Support

====================================================
When responding to posts,please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
====================================================
 
Thanks for the suggestion, I tried it and found that it had the same effect,
the next ShowDialog() was skipped. I assume that I have something in my
implementation of the form, or of the custom control in the form, that is not
set up properly. I am going to move to a small test case and see if I can
work it out that way. Thanks again.
 
Richard MSL said:
Thanks for the suggestion, I tried it and found that it had the same
effect,
the next ShowDialog() was skipped. I assume that I have something in my
implementation of the form, or of the custom control in the form, that is
not
set up properly. I am going to move to a small test case and see if I can
work it out that way. Thanks again.
Click to expand...

Just a wild guess - try adding "e.Handled = true; " if you're closing the
form (I'm just wondering if the Esc is somehow left hanging around and so
gets processed by the second form).

Chris Jobson
 
Hi Richard,

I am interesting in this issue. Would you mind letting me know how you are
going on about this problem? If you need further assistance, feel free to
let me know. I will be more than happy to be of assistance.

Have a great day!


Sincerely,
Linda Liu
Microsoft Online Community Support

====================================================
When responding to posts,please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
====================================================
 
Thanks. I have not had a chance to return to it, I have become sidetracked
dealing with .NET security to make my application run on a network. It
appears that I will not be able to work on it for a week or so, but when I
do, I will let you know what I find.
 
Hi Richard,

You're welcome!


Sincerely,
Linda Liu
Microsoft Online Community Support

====================================================
When responding to posts,please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
====================================================
 
Back
Top