Input Data from Form [RESOLVED]

Say that I want a button on my main form to open up a new window for the user to input data, then transfer that data back to the main form, what is the most efficient way?

Example, user clicks "move to distance" button and a form would pop up saying "input distance" with one button that says "Go!" or something. Whatever distance they input would get put back into the main form for processing.

C# Code:

using (Form2 f2 = new Form2())
{
    // Set properties of f2 here to pass initial data.
 
    if (f2.ShowDialog() == System.Windows.Forms.DialogResult.OK)
    {
        // The user pressed the OK button.
        // Get properties of f2 here to get final data.
    }
}

I'm not sure that I completely understand.

If you dont mind, I have a couple questions.

1. Where would that code go? The main form?
2. What is "using" I haven't used that yet (no pun intended :p )
3. The properties that you say I would get/set are properties that I would make as properties of Form2? Is that the intention?
4. I'm not clear on when these properties will be updated based on the information entered in the text box(es)? on Form2? Would I do that inside Form2? Should Form2 have textbox(es) at all for the info, or is it input another way?

I think I would understand this better if I knew what Form.ShowDialog did. I will go play with it now.

Thanks for your help!

1. It would go wherever you need it to go. E.g. if you want to dispay this form on a Button Click then it goes in the Click event handler of that Button.

2. "using" is a C# key word and, like all C# key words, you can find out all about it from the MSDN library.

3. Yes, you would declare those properties yourself as required.

4. You need to add the controls and properties that are appropriate to the circumstances. Every situation would be different so it's up to you what you do in your situation.

I had no idea that you could use "using" in that way. That is really cool!

This worked great, thanks alot. Much easier and more efficient than what I had!

I have one last question. Can you explain what happens when you invoke the .ShowDialog() of a Form? I realize that it opens the form, but what happens when you have that "if" statement right there looking for the dialog result? Does the program hang there waiting on a response from ShowDialog()? I mean, it waits as long as you take to fill out the Form2 and report the dialog result as OK, but I'm not sure what is happening while it is waiting? Does my question makes sense? I think it is because ShowDialog() is called from within the if and until a dialog result of some kind is returned, the if statement is not evaluated. If this is true, what is going on in the main form during this time? Are events still running (ie timers or something?)? Also, if you do not send any dialog result, does it send a default one as the form is closed? ie you just close Form2 and do not send OK or anything?

Thanks!

The ShowDialog method blocks until the dialogue is dismissed, which is the whole idea. A modal dialogue is supposed to deny access to its caller, so nothing happens in the calling form until ShowDialog returns. It's impossible to not return a value from ShowDialog. If you don't explicitly set the DialogResult of the form then when you call Close it is set to Cancel implicitly.

ShowDialog opens the dialogue on the same thread as the calling form. One thread can only do one thing at a time. If events are raised in the calling form then they are queued until the current event has been processed fully. VB.NET is an event-driven language, so you will have called ShowDialog from an event handler or a method that was called from an event handler. Until that event handler completes no others can be executed.

Thanks for your help. I understand it much much better now.

So, not that I really need to, but if I wanted to... If I put a timer (on the form that I .ShowDialog of) that is enabled upon load and only exectues "DoEvents", would this process the events from the main form (and any events on the thread for that matter). Would this be a "workaround" so to speak?

A workaround for what exactly? There are not going to be any events raised as a result of user input because the user can't access the caller, only the dialogue. I just did a quick test and Tick events of a Timer are still raised and handled in the caller, so there isn't much more that you'd have to worry about.

Quote:

---

Originally Posted by jmcilhinney

A workaround for what exactly? There are not going to be any events raised as a result of user input because the user can't access the caller, only the dialogue. I just did a quick test and Tick events of a Timer are still raised and handled in the caller, so there isn't much more that you'd have to worry about.

---

Sorry, I was under the impression that tick events were not going to be running. I should have checked.

Thanks! :wave: