[RESOLVED] .ShowDialog() causing annoyances

[Vectris]

I'm making a program and it requires a Form to show that requires an action before the user can go back to the main Form. Of course to do this I am using .ShowDialog(), but unfortunately I have found out that ShowDialog() has some annoying querks.

Firstly, any time I pressed a button it would exit the entire application. After loads of googling I finally found out that you have to use

Me.DialogResult = None

At the end of each button click in order to keep the Form from closing.

But secondly, anything that I do to the Form is saved! So for instance I have a listbox that I populate with some code during the Form's Load Event. Well after I close it, if I bring the Form back up the items in the ListBox quadruples! I don't know why it's times 4 but I know that if I clear the items on each load it stops this. So whenever I use .ShowDialog() stuff is leftover on the form even after I .Close() it.

While I can find impractical ways around it, such as the Me.DialogResult and resetting all the Forms properties on load, I would like to know if there is anything I can do to prevent those two problems, any work around or other options.

Also I have tried just plain Show and everything works perfectly, it's just that then the user can switch to the main form with the second window still open, which is why I was using .ShowDialog in the first place.

code
At first I had this

QuickLoadForm.ShowDialog()

Then I looked at the MSDN Library and changed it to this

        Dim instance As Form = QuickLoadForm
        Dim returnValue As DialogResult
        returnValue = instance.ShowDialog()

I still have the problem however and I'm guessing that Modal forms are supposed to behave like that. But saving all the forms settings is really annoying and doesn't make any sense to me so if someone knows how to turn that off I'd appreciate it.

EDIT: Well I should of finished reading the MSDN Article

Close method is not called by the .NET Framework when the user clicks the close form button of a dialog box or sets the value of the DialogResult property. Instead the form is hidden and can be shown again without creating a new instance of the dialog box. Because a form displayed as a dialog box is not closed, you must call the Dispose method of the form when the form is no longer needed by your application.

I'm tried it out and putting Me.Dispose() on the Form Close event fixed "save form properties" problem


However I still would like to know if there is an easy way to set the DialogResult so that you don't have to use:

Me.DialogResult = None

at the end of every button click. I tried using it on the Form Load but it still exits on any click.

[Icyculyr]

You don't have to use Me.DialogResult=None after each button is clicked, I have shown many Dialogs via ShowDialog() and have never had this problem, the likely thing I can see (if created in the designer), is that the property "DialogResult" of your button (not the form) is set to "Cancel" in which anytime you click the button, it will close the form.

If that is not the case, simply set the DialogResult value of your form you are showing to none, and only change it right as your OK button is clicked.

If the problem persists I'd probably have to see more of your code to get a better understanding of what is going on.

I don't actually use the designer anymore, I do everything in code in my Form1_Load, from creating buttons, to other forms, VS doesn't lag as much, and it's much simpler =)

Kind Regards

[jmcilhinney]

There's absolutely no need to set the DialogResult property of the form to None because it is None to start with and it will always be None until you set it to some other value. If you're finding that you have to set it to None then it can only be because you're setting it to some other value beforehand. If you aren't doing it explicitly in code then it's presumably because you have set the DialogResult property of the Buttons. I'm guessing that you had one Button with it's DialogResult property set and then you copied that Button rather than adding new ones.

Setting the DialogResult property of a Button means that clicking that Button will set the form's DialogResult property to that value. Note that, if you select a Button as the form's CancelButton, its DialogResult property will be set to Cancel by default. Selecting a Button as the form's AcceptButton does not affect the Button's DialogResult property.

Unless you specifically want to use the same instance over and over, this is how you should show a dialogue:

Using dialogue As New SomeForm
    If dialogue.ShowDialog() = Windows.Forms.DialogResult.OK Then
        'Process the affirmative response.
    End If
End Using

If the user's response can be values other than OK and Cancel then you might use a Select Case instead of an If.

In the dialogue itself, if there's a Cancel button the it should be selected as the form's CancelButton and its DialogResult wil be set to Cancel by default. If there's an OK button and you will definitely close the form when it's clicked then you should set its DialogResult property to OK. If the form may or may not close, e.g. you need to validate data, then leave the OK button's DialogResult as None and then explicitly set the form's DialogResult property in the Click event handler if you want the form to close.

[Vectris]

Change the "DialogResult" of the button worked perfectly! Thanks Icyculyr.

[Vectris]

If you're finding that you have to set it to None then it can only be because you're setting it to some other value beforehand. If you aren't doing it explicitly in code then it's presumably because you have set the DialogResult property of the Buttons. I'm guessing that you had one Button with it's DialogResult property set and then you copied that Button rather than adding new ones.

Setting the DialogResult property of a Button means that clicking that Button will set the form's DialogResult property to that value. Note that, if you select a Button as the form's CancelButton, its DialogResult property will be set to Cancel by default. Selecting a Button as the form's AcceptButton does not affect the Button's DialogResult property.

That's exactly what happened. I have a ccancelButton (2 cs to avoid conflic) and I did actually set it as the Form's CancelButton which changed the Dialog Result. Then I copied it to make another button and that was causing my problem.

Thank You both.

[jmcilhinney]

I don't actually use the designer anymore, I do everything in code in my Form1_Load, from creating buttons, to other forms, VS doesn't lag as much, and it's much simpler

Sounds a bit Amish to me. If you like to do that then more power to you but there's no way it's simpler. If I want OK and Cancel Buttons on my form I just double-click in the Toolbox twice, drag the Buttons until the snap lines position them automatically, edit the Text of each, select both and set the Anchor together and then select them as the form's AcceptButton and CancelButton. There's no way that it's simpler to write the code to do that by hand. For a start, you have to do some calculations to determine the Location of each Button when, in the designer, the snap lines will do it for you.

[Icyculyr]

Haha, in small apps it's easier to use the designer, however in large apps, where lots of content changes often, you'd have 100+ controls on the designer, I prefer code =)

Kind Regards

[SJWhiteley]

Haha, in small apps it's easier to use the designer, however in large apps, where lots of content changes often, you'd have 100+ controls on the designer, I prefer code =)

Kind Regards

I suppose if no-one else is going to debug it, then more power to you.

100+ controls on a form sounds like a design issue rather than a 'large app'. I've found that once you get to around 50 odd controls, things are starting to get cumbersome. Usually, I'd break things down into functionality and make a single control for that function.

[techgnome]

that's what we've done.... grouped together functionality into user controls.... so the form itself typically only has a dozen controls, tops....
Can make things annoying when you are trying to track down where certain functionality exists, but after a while, you learn how it's all put together.

-tg

[Icyculyr]

I see, but if your designing a large scale app, where many different components are required, that cannot be used for other things, stuff gets messy.. I don't know if there's a way to clean it up but I've never been able to.

Kind Regards

[jmcilhinney]

I see, but if your designing a large scale app, where many different components are required, that cannot be used for other things, stuff gets messy.. I don't know if there's a way to clean it up but I've never been able to.

Kind Regards

Large-sclae apps should generally have more forms, not more controls on the same number of forms. I think you probably need to spend more time on the design. It's very unlikely that you couldn't break that logic up into multiple forms or UserControls that could be created and destroyed as needed. The only thing I can think of offhand that would require so many controls would be something like a sound mixer, but who'd build that in VB.NET anyway?