none
How can I wait for user input on a form? RRS feed

  • Question

  • I'm trying to get my head around what is, to me, a reasonably simple task, but I can't see a reasonably simple solution in the VB documentation.

    I have a form on which a user makes some changes and then presses an OK or Cancel button when finished. The form has to remain open after the button is pressed, so a Dialog isn't the answer. I've looked through the Async documentation, but this appears to be restricted to .NET API calls to Web or file I/O and doesn't seem to give any hint on how to write your own asynchronous task (or have I missed something here?). I can probably do it using a separate thread, but it shouldn't be necessary as there's only one section of code running at once.

    What obvious solution have I missed please?


    Peter

    Monday, December 18, 2017 7:30 PM

All replies

  • I'm trying to get my head around what is, to me, a reasonably simple task, but I can't see a reasonably simple solution in the VB documentation.

    When the user clicks a button on a form, the code included in that button click event handler is executed.  The form will not close unless that method includes code to close the form (which it might for a Cancel, for example).  Async or threading doesn't affect that.  If your form is closing when you don't want it to close then there is some code being executed in that button click event handler to close it.

    Monday, December 18, 2017 7:45 PM
  • It is not clear what you are asking. If you don't get help with the problem you want help with then please clarify what you are trying to ask.


    Sam Hobbs
    SimpleSamples.Info

    Monday, December 18, 2017 8:26 PM
  • I'm trying to get my head around what is, to me, a reasonably simple task, but I can't see a reasonably simple solution in the VB documentation.

    I have a form on which a user makes some changes and then presses an OK or Cancel button when finished. The form has to remain open after the button is pressed, so a Dialog isn't the answer. I've looked through the Async documentation, but this appears to be restricted to .NET API calls to Web or file I/O and doesn't seem to give any hint on how to write your own asynchronous task (or have I missed something here?). I can probably do it using a separate thread, but it shouldn't be necessary as there's only one section of code running at once.

    What obvious solution have I missed please?


    Peter

    The form should never close unless you have code that exist the form. You could after the user chooses their selection reload or refresh the form. I wrote a little game that ask for user inputs and a very basic battle system and the game never closes unless the user chooses to close the game.
    Monday, December 18, 2017 8:48 PM
  • You don't say whether this is for Windows Forms, WPF or UWP or something else. This should be in the forum for one of those but you should at least specify which one.

    There is no such thing as "Ok" and "Cancel" buttons unless you create them and use those names.

    I don't understand why you say a dialog would not work; you say the window must remain open and that is what a dialog is; the only difference between modeless (non-dialog) and modal (dialog) is whether the other windows in the application should be used.



    Sam Hobbs
    SimpleSamples.Info

    Monday, December 18, 2017 9:02 PM
  • I'm trying to get my head around what is, to me, a reasonably simple task, but I can't see a reasonably simple solution in the VB documentation.

    I have a form on which a user makes some changes and then presses an OK or Cancel button when finished. The form has to remain open after the button is pressed, so a Dialog isn't the answer. I've looked through the Async documentation, but this appears to be restricted to .NET API calls to Web or file I/O and doesn't seem to give any hint on how to write your own asynchronous task (or have I missed something here?). I can probably do it using a separate thread, but it shouldn't be necessary as there's only one section of code running at once.

    What obvious solution have I missed please?


    Peter

    Peter,

    Everything you've described there - up to the part about needing the form to remain open - describes a typical dialog form being shown modally.

    Explain how this one is to be different?

    Normally the "OK" button is disabled until all of the minimum details have been filled in. Is that not the case here?


    "A problem well stated is a problem half solved.” - Charles F. Kettering

    Monday, December 18, 2017 9:43 PM
  • I'm trying to get my head around what is, to me, a reasonably simple task, but I can't see a reasonably simple solution in the VB documentation.

    I have a form on which a user makes some changes and then presses an OK or Cancel button when finished. The form has to remain open after the button is pressed, so a Dialog isn't the answer. I've looked through the Async documentation, but this appears to be restricted to .NET API calls to Web or file I/O and doesn't seem to give any hint on how to write your own asynchronous task (or have I missed something here?). I can probably do it using a separate thread, but it shouldn't be necessary as there's only one section of code running at once.

    What obvious solution have I missed please?


    Peter

    Hi ptoye,

    You said that when you press ok or cancel button, you want to the form remain open, why the form closed when you press ok or cancel button, I guess that you make some code to close the form in button event. Can you provide your code here, so I can understand you want to do.

    Best Regards,

    Cherry


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, December 19, 2017 7:52 AM
    Moderator
  • OK, I haven't been explicit enough, and many people here have answered a different question from the one I meant to answer. Sorry. I'll try again:

    My program has a Windows form which contains a number of items on it (inherited from Button) which a user can click to select various options in any combination. At a certain point (in an inner loop in a subroutine that is called from a number of different places) I want to:

    1) Display a second form (NOT a dialog) which contains text asking the user to make their selection and OK and Cancel buttons. It can't be a dialog because the user then can't do Step 2.

    2) When the user has clicked on whatever buttons they want on the first form, they click the OK or Cancel on the second form as required.

    3) The code then checks what the user has done and acts on it. One of these things will be to hide the second form with the OK/Cancel buttons, but that's the easy bit!

    The problem I have is that the main program needs to suspend itself after step (1) and resume in step (3). At that point it needs the program state at the point of suspension. This is standard real-time processing, and I need a way of doing it. The pseudo-code would be something like:

    Main program:

    OKButtonForm.Show()

    Waitfor Trigger 'This is the bit I don't get

    Continue processing

    OK Button handler:

    OKButtonForm.Hide()

    Process user's input

    Fire trigger  ' The other bit I don't get

    Does this make more sense? I'm sure it's there in the documentation, but I haven't found it, probably because I'm not using the right search term


    Peter




    • Edited by ptoye Wednesday, December 20, 2017 10:01 AM Clarification
    Tuesday, December 19, 2017 9:29 AM
  • OK, I haven't been explicit enough, and many people here have answered a different question from the one I meant to answer. Sorry. I'll try again:

    My program has a Windows form which contains a number of items on it (inherited from Button) which a user can click to select various options in any combination. At a certain point (in an inner loop in a subroutine that is called from a number of different places) I want to:

    1) Display a second form (NOT a dialog) which contains text asking the user to make their selection and OK and Cancel buttons. It can't be a dialog because the user then can't do Step 2.

    2) When the user has clicked on whatever buttons they want, they click the OK or Cancel as required.

    3) The code then checks what the user has done and acts on it. One of these things will be to hide the second form with the OK/Cancel buttons, but that's the easy bit!

    The problem I have is that the main program needs to suspend itself after step (1) and resume in step (3). At that point it needs the program state at the point of suspension. This is standard real-time processing, and I need a way of doing it. The pseudo-code would be something like:

    Main program:

    OKButtonForm.Show()

    Waitfor Trigger 'This is the bit I don't get

    Continue processing

    OK Button handler:

    OKButtonForm.Hide()

    Process user's input

    Fire trigger  ' The other bit I don't get

    Does this make more sense? I'm sure it's there in the documentation, but I haven't found it, probably because I'm not using the right search term


    Peter



    When you want to do this kind of things, you should first learn about the internal message routing between the OS en the programs. It is called the windows messaging system. (Nothing to do with mail). It exist as long as windows exist and Forms is complete build on it. Based on that the DialogForm is created. If you want to do it your way, then you do something they did not succeed in a general way at Microsoft. 

    https://msdn.microsoft.com/en-us/library/windows/desktop/ms644927(v=vs.85).aspx

    Be aware that the problem lays if a program is not responding. 

    That is the reason that most use a showdialog form because no user is in fact recognizes you did spent 90% of your time making this possible. 


    Success
    Cor

    Tuesday, December 19, 2017 10:12 AM
  • 1) Display a second form (NOT a dialog) which contains text asking the user to make their selection and OK and Cancel buttons. It can't be a dialog because the user then can't do Step 2.

    What you have described is exactly how a dialog form works.

    The problem might be that you are assuming that the OKButton form is no longer accessible after it is closed, so the user selections on that form ar not available to the calling form code.  That isn't a problem if you show the form as a dialog. The form close in the OK or Cancel button hides the form but does not dispose of the form instance.  The calling program can reference the OKButton form instance controls and properties to get the user selections and process accordingly when that code resumes when the dialog is closed.

    Tuesday, December 19, 2017 11:55 AM
  • Everything you've described there - up to the part about needing the form to remain open - describes a typical dialog form being shown modally.

    Explain how this one is to be different?

    Normally the "OK" button is disabled until all of the minimum details have been filled in. Is that not the case here?


    "A problem well stated is a problem half solved.” - Charles F. Kettering

    I agree with the first sentence. But I thought that a Dialog had to be modal - so the user couldn't do the selection on the basic form until they'd filled in whatever was on the Dialog form. But the basic form has to persist after OK/Cancel has been pressed, so I can't combine the two. The .NET documentation doesn't seem to mention arbitrary dialogs, and RunDialog() doesn't have a parameter to specify that it's not modal.

    Think of a draughts (checkers in the US) game. When it's their turn, the user has to select a piece, make a move or moves with it, and press "OK". The OK/Cancel form will disappear but the board remains. That's the effect I want.


    Peter

    Tuesday, December 19, 2017 3:52 PM
  •  But I thought that a Dialog had to be modal - so the user couldn't do the selection on the basic form until they'd filled in whatever was on the Dialog form. But the basic form has to persist after OK/Cancel has been pressed, so I can't combine the two. The .NET documentation doesn't seem to mention arbitrary dialogs, and RunDialog() doesn't have a parameter to specify that it's not modal.

    Think of a draughts (checkers in the US) game. When it's their turn, the user has to select a piece, make a move or moves with it, and press "OK". The OK/Cancel form will disappear but the board remains. That's the effect I want.


    Peter

    Peter,

    Did you try it or do you assume it, hundred of millions have used it, but with you it seems to be different?

    However, if it is a game than a simple area which you use for this is much more simple. For instance a status control on a form

    By the way, a dialog form is like I wrote before simple a form which is not shown with show but with showdialog.


    Success
    Cor

    Tuesday, December 19, 2017 4:07 PM
  • When you want to do this kind of things, you should first learn about the internal message routing between the OS en the programs. It is called the windows messaging system. (Nothing to do with mail). It exist as long as windows exist and Forms is complete build on it. Based on that the DialogForm is created. If you want to do it your way, then you do something they did not succeed in a general way at Microsoft. 

    https://msdn.microsoft.com/en-us/library/windows/desktop/ms644927(v=vs.85).aspx

    Be aware that the problem lays if a program is not responding. 

    That is the reason that most use a showdialog form because no user is in fact recognizes you did spent 90% of your time making this possible. 


    Success
    Cor

    I didn't think that I was trying to anything particularly complicated! If you look at my reply to Frank's question you'll see the sort of thing I'm trying to do.

    If I can't do it using a pre-defined Dialog box, it looks as if I will have to read https://msdn.microsoft.com/en-us/library/windows/desktop/ms632588(v=vs.85).aspx first. SO I may be some time...

    I'm afraid that I don't understand your last paragraph.


    Peter

    Tuesday, December 19, 2017 4:11 PM

  • The OK/Cancel form will disappear but the board remains. That's the effect I want.


    Peter

    That does sound like you want to set it up modelessly but it's tough row to hoe if you go that route. The calling form doesn't stop and wait (like it will if it's shown modally).

    "A problem well stated is a problem half solved.” - Charles F. Kettering

    Tuesday, December 19, 2017 4:26 PM
  • That does sound like you want to set it up modelessly but it's tough row to hoe if you go that route. The calling form doesn't stop and wait (like it will if it's shown modally).

    "A problem well stated is a problem half solved.” - Charles F. Kettering

    I'm finding this hard to believe. Someone else must have needed this sort of behaviour in the past - surely it's not that uncommon? It's not even as if I should have to play with threads, as there's only one piece of code active at any one time (and in practice, not much of that, given that the machine's waiting for the user for most of its time.

    I don't want to lose control of the main form, because that's the one with the buttons that will be clicked to make the user's selections (or checker moves if you prefer) so I need the handler for the click events. I just want to suspend the program which creates the form until an OK/Cancel button's been pressed. I could probably put those buttons on the main form somewhere, but from the UI point of view that's not a good idea, and I don't think it would help the programming anyway. In theory I could remember exactly what the program was doing when it asks for the user input, and return from the event handler which had been called (the whole program's event-driven by user actions) at the base of the stack. But that's exactly what my suspension idea does.

    I've a nasty feeling that I'm going to have to take Cor's advice and read up on Windows messaging...


    Peter

    Tuesday, December 19, 2017 5:16 PM
  • Peter,

    I guess maybe I'm not fully understanding but if it's waiting on the user, that sure sounds like it should be modal.


    "A problem well stated is a problem half solved.” - Charles F. Kettering

    Tuesday, December 19, 2017 5:20 PM
  • I guess maybe I'm not fully understanding but if it's waiting on the user, that sure sounds like it should be modal.

    "A problem well stated is a problem half solved.” - Charles F. Kettering


    Ah, but have you stated the question well? What is "it"? The basic form can be modal or not. The form with the buttons on has to be non-modal or the user can't click the buttons on the basic form. At least, that's how I understand modality. Am I wrong? I hope so.

    Peter

    Tuesday, December 19, 2017 6:54 PM

  • Ah, but have you stated the question well? What is "it"? The basic form can be modal or not. The form with the buttons on has to be non-modal or the user can't click the buttons on the basic form. At least, that's how I understand modality. Am I wrong? I hope so.

    Peter

    It sounds like you have a good handle on it.

    Usually a modeless form is used for something like a toolbar.


    "A problem well stated is a problem half solved.” - Charles F. Kettering

    Tuesday, December 19, 2017 6:56 PM
  • It sounds like you have a good handle on it.

    Usually a modeless form is used for something like a toolbar.


    "A problem well stated is a problem half solved.” - Charles F. Kettering

    Thanks, but what I was hoping for was a solution, not a handle! I hadn't realised it would be so complex. That's why my original posting was written in terms of asynchronous processing, as the Async and Await keywords seemed to be exactly what I wanted if only I knew how to write the relevant Task. https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/concepts/async/ and its follow-ons don't give any hint on how to do this; they just use the pre-defined tasks which get a response from the web or a file system. User input doesn't get a look-in.

    Please don't tell me that I've found a hole in VB and .NET!


    Peter

    Tuesday, December 19, 2017 7:19 PM
  • I agree with the first sentence. But I thought that a Dialog had to be modal - so the user couldn't do the selection on the basic form until they'd filled in whatever was on the Dialog form. But the basic form has to persist after OK/Cancel has been pressed, so I can't combine the two. The .NET documentation doesn't seem to mention arbitrary dialogs, and RunDialog() doesn't have a parameter to specify that it's not modal.

    Think of a draughts (checkers in the US) game. When it's their turn, the user has to select a piece, make a move or moves with it, and press "OK". The OK/Cancel form will disappear but the board remains. That's the effect I want.

    Modal is simply a description of what a dialog does - it suspends the code execution in the caller until the dialog that was called is closed.   I can't get your reference to draughts because I can't see why there would be more than one form in that case - OK would be a control on the same form that the user selected the piece and the move, and there would be no need for a Cancel.    If you need to supply an example of what you want to do, then I am sure it is available in an application that is accessible, such as Visual Studio.

    Tuesday, December 19, 2017 7:33 PM
  • I didn't think that I was trying to anything particularly complicated! If you look at my reply to Frank's question you'll see the sort of thing I'm trying to do.

    It's not complicated at all -  in fact it is how the modal dialog is designed to work, and it's the examples provided with the description of the dialog form.

    Tuesday, December 19, 2017 7:35 PM
  • Peter,

    Obviously I'm not "getting" what you want here, but when you find it and complete it, would you post a screenshot of it here?

    If nothing but just for the sake of curiosity, I'd like to know what you're talking about.


    "A problem well stated is a problem half solved.” - Charles F. Kettering


    • Edited by Frank L. Smith Tuesday, December 19, 2017 7:36 PM ...added words
    Tuesday, December 19, 2017 7:36 PM
  • The basic form can be modal or not. The form with the buttons on has to be non-modal or the user can't click the buttons on the basic form. At least, that's how I understand modality.

    That's correct, but your description does not involve pressing buttons on the base form while the dialog is visible.  

    This is what you originally required: "I have a form on which a user makes some changes and then presses an OK or Cancel button when finished. The form has to remain open after the button is pressed."  Whether or not the form remains open after the button is pressed depends on code in the button click event handler that either closes the form, or doesn't.  But you haven't indicated why the form would remain open after the user has selected OK or Cancel - both those buttons usually mean "I have finished entering data etc and I now want this form to go away so that code in the calling form can use that information to continue processing".  That's a modal dialog.

    You added to that description with the summarising comment "The problem I have is that the main program needs to suspend itself after step (1) and resume in step (3)."  That means that the form that it instantiates and shows should be modal - a modal dialog.  Step 3 you have described as 'hide the second form with the OK/Cancel buttons' which is exactly what a modal dialog does for the default setup of OK or Cancel button.  The other thing to happen in step 3 is "The code then checks what the user has done and acts on it."   That code simply looks at the properties of the controls and fields in the instance of the dialog form, gets the settings that the user selected, and acts on it.  You have those two steps the wrong way around - the user closes the dialog before the code in the calling forms checks what the user has done, because closing the dialog is the point where controls returns to the caller  - but otherwise it is the exact description of how to use a modal dialog.

    Tuesday, December 19, 2017 7:53 PM
  • Probably the solution is easy and you are making it complex.

    Quite often people think they have a solution to a problem and they ask about the solution. Your original post says a lot about (what you think is) a possible solution but not much about the problem. Things like async and await are what you think might be a solution.



    Sam Hobbs
    SimpleSamples.Info

    Tuesday, December 19, 2017 8:14 PM
  • At that point it needs the program state at the point of suspension.

    That seems to be the important part but it is very vague. I am not sure which form would be needing it and I don't know what "state" means. I am confident that if the requirements could be defined then the answer is easy.

    So let us assume you have created a new Windows Forms application. Add a second form. Add a textbox to the second from. Add a label and a button to the first form. Use the following for the button click event handler.

    Dim f2 As Form2 = New Form2
    f2.ShowDialog()
    Label1.Text = f2.TextBox1.Text

    Then run it. Click the button. The second form is shown. Enter something into the textbox. Close the form (you can click the close button at the top right). The text from the textbox is put into the label. Is that close to a very simplified version of what you are doing?


    Sam Hobbs
    SimpleSamples.Info


    Wednesday, December 20, 2017 2:03 AM
  • Probably the solution is easy and you are making it complex.

    Quite often people think they have a solution to a problem and they ask about the solution. Your original post says a lot about (what you think is) a possible solution but not much about the problem. Things like async and await are what you think might be a solution.



    Sam Hobbs
    SimpleSamples.Info


    My original post is out of date - please read my later ones before commenting. I did not think I had a solution, I was asking for one! If I had a solution I wouldn't be here.

    Peter


    • Edited by ptoye Wednesday, December 20, 2017 9:59 AM typo
    Wednesday, December 20, 2017 9:59 AM
  • The basic form can be modal or not. The form with the buttons on has to be non-modal or the user can't click the buttons on the basic form. At least, that's how I understand modality.

    That's correct, but your description does not involve pressing buttons on the base form while the dialog is visible.  

    This is what you originally required: "I have a form on which a user makes some changes and then presses an OK or Cancel button when finished. The form has to remain open after the button is pressed."  Whether or not the form remains open after the button is pressed depends on code in the button click event handler that either closes the form, or doesn't.  But you haven't indicated why the form would remain open after the user has selected OK or Cancel - both those buttons usually mean "I have finished entering data etc and I now want this form to go away so that code in the calling form can use that information to continue processing".  That's a modal dialog.

    You added to that description with the summarising comment "The problem I have is that the main program needs to suspend itself after step (1) and resume in step (3)."  That means that the form that it instantiates and shows should be modal - a modal dialog.  Step 3 you have described as 'hide the second form with the OK/Cancel buttons' which is exactly what a modal dialog does for the default setup of OK or Cancel button.  The other thing to happen in step 3 is "The code then checks what the user has done and acts on it."   That code simply looks at the properties of the controls and fields in the instance of the dialog form, gets the settings that the user selected, and acts on it.  You have those two steps the wrong way around - the user closes the dialog before the code in the calling forms checks what the user has done, because closing the dialog is the point where controls returns to the caller  - but otherwise it is the exact description of how to use a modal dialog.

    I've edited my comment on 19th above to clarify it, as the different forms were getting confused. Sorry.

    So you will see that I do need to press buttons on the base form, and then OK/Cancel on the second form. "OK" means "I have finished making a selection, I want the program to process it and Iwant the form to stay there". As I've said above, think of a draughts/checkers game. The user has to click on a piece to select it, click on the square(s) that they want it to pass through, and then OK/Cancel to accept the move. But the board doesn't go away after all that. I agree that in this particular case, the OK/Cancel could go onto the main board form, but that doesn't affect the argument. It's also taking the analogy too far.


    Peter

    Wednesday, December 20, 2017 10:08 AM
  • At that point it needs the program state at the point of suspension.

    That seems to be the important part but it is very vague. I am not sure which form would be needing it and I don't know what "state" means. I am confident that if the requirements could be defined then the answer is easy.

    So let us assume you have created a new Windows Forms application. Add a second form. Add a textbox to the second from. Add a label and a button to the first form. Use the following for the button click event handler.

    Dim f2 As Form2 = New Form2
    f2.ShowDialog()
    Label1.Text = f2.TextBox1.Text

    Then run it. Click the button. The second form is shown. Enter something into the textbox. Close the form (you can click the close button at the top right). The text from the textbox is put into the label. Is that close to a very simplified version of what you are doing?


    Sam Hobbs
    SimpleSamples.Info


    Program "state" is the context at that particular time. Call stack, values of variables etc. Think co-routines.


    Peter

    Wednesday, December 20, 2017 10:09 AM
  • It's not complicated at all -  in fact it is how the modal dialog is designed to work, and it's the examples provided with the description of the dialog form.
    Do you have an URL for the description please?

    Peter

    Wednesday, December 20, 2017 10:11 AM
  • Do you have an URL for the description please?

    https://msdn.microsoft.com/en-us/library/c7ykbedk(v=vs.110).aspx

    The bit that you need to expand is  txtResult.Text = testDialog.TextBox1.Text.

    Wednesday, December 20, 2017 10:30 AM
  • Do you have an URL for the description please?

    https://msdn.microsoft.com/en-us/library/c7ykbedk(v=vs.110).aspx

    The bit that you need to expand is  txtResult.Text = testDialog.TextBox1.Text.

    Thanks. I still don't see how it helps. The user cannot select buttons on the base form while the dialog's active because of the modality. But the user needs to be able to select an unknown (to the program) number of buttons before clicking "OK/Cancel". So, without asking the user to click a "continue" on the dialog each time they select a button (which might as well be a Msgbox now), there's no way of getting the type of interaction the program needs. And I hope you'd agree that asking for two user clicks when one should suffice is not good UI design.

    I've worked out two ways of doing what I want. Neither of them is great.

    The first is to  completely refashion that part of the program, use forms rather than dialogs (to remove modality) and keep a record of the program's state so that the appropriate action can be taken when the buttons are clicked. Heavy programming, lots of spaghetti, but keeps everything in a single thread and I don't have to learn anything new.

    The second is to learn about asychronous programming, which keeps the program logic simple but I think (without knowing) will allow the main program thread to be suspended but still allow events such as button clicks. This will be a big learning curve and take quite a lot of experimentation.


    Peter

    Thursday, December 21, 2017 10:41 AM
  • The user cannot select buttons on the base form while the dialog's active because of the modality. But the user needs to be able to select an unknown (to the program) number of buttons before clicking "OK/Cancel".

    Why would you open the dialog before the user has completed selecting the buttons on the 'base' form.  That seems the wrong way around.

    Or, to put it another way, why are these buttons on the base form when the user needs to click them when the dialog is open?  Shouldn't they therefore be on the dialog form?

    /Edit

    We may be at cross purposes.  You do appreciate, I hope, that (a) an event can have multiple handlers and (b) the event handler does not have to be on the same form as the control that raises the event.

    Public Class Form1
    
        Public WithEvents F2 As Form2
    
        Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
            F2 = New Form2
            F2.Show()
            AddHandler F2.Button1.Click, AddressOf Button_Click
        End Sub
    
        Private Sub Button_Click(sender As Object, e As EventArgs)
            MsgBox("Clicked on form 2, Handled on form 1")
        End Sub
    
    End Class
    
    Public Class Form2
    
        Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
            MsgBox("Clicked on form 2, Handled on form 2")
        End Sub
    End Class

    • Edited by Acamar Thursday, December 21, 2017 11:37 AM add
    Thursday, December 21, 2017 11:21 AM
  • The user cannot select buttons on the base form while the dialog's active because of the modality. But the user needs to be able to select an unknown (to the program) number of buttons before clicking "OK/Cancel".

    Why would you open the dialog before the user has completed selecting the buttons on the 'base' form.  That seems the wrong way around.

    Or, to put it another way, why are these buttons on the base form when the user needs to click them when the dialog is open?  Shouldn't they therefore be on the dialog form?

    /Edit

    We may be at cross purposes.  You do appreciate, I hope, that (a) an event can have multiple handlers and (b) the event handler does not have to be on the same form as the control that raises the event.

    Public Class Form1
    
        Public WithEvents F2 As Form2
    
        Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
            F2 = New Form2
            F2.Show()
            AddHandler F2.Button1.Click, AddressOf Button_Click
        End Sub
    
        Private Sub Button_Click(sender As Object, e As EventArgs)
            MsgBox("Clicked on form 2, Handled on form 1")
        End Sub
    
    End Class
    
    Public Class Form2
    
        Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
            MsgBox("Clicked on form 2, Handled on form 2")
        End Sub
    End Class

    I do not know which or how many buttons the user will click. They are part of the base form and need to persist after the user has done this phase of the program. So they can't be part of the dialog form. Think checkers/draughts. The user has to make an unknown number of moves on the board (multiple captures are allowed) and then accept/reject the result.

    I think that we are at cross purposes, though. My UI needs are clear enough (to me at least, and if not to you that's my fault), programming them isn't! Here is a mock-up of what I want:


    Peter

    Thursday, December 21, 2017 12:23 PM
  • The user cannot select buttons on the base form while the dialog's active because of the modality. But the user needs to be able to select an unknown (to the program) number of buttons before clicking "OK/Cancel".

    Then what is the problem with that arrangement?  If you want code in the base form to continue only after the OK button in Form 2 is clicked, then don't use a dialog, handle the Form 2 OK button click event in a handler on the base form, and include the 'continue' code there.  It's a very standard toolbox-type arrangement, except that you base form is what would usually be the toolbox. 

    Or, create you own event, subscribe to it in the base form and raise it in the Form 2 button click event.

    Public Class Form1
    
        Public WithEvents F2 As Form2
    
        Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
            ' process, process, process
            F2 = New Form2
            F2.Show()
            AddHandler F2.ButtonOK.Click, AddressOf ButtonOK_Click
            AddHandler F2.ButtonCancel.Click, AddressOf ButtonCancel_Click
        End Sub
    
        Private Sub ButtonOK_Click(sender As Object, e As EventArgs)
            MsgBox("Clicked OK.  Carry on")
            F2.Close()
            ' continue
        End Sub
    
        Private Sub ButtonCancel_Click(sender As Object, e As EventArgs)
            MsgBox("Clicked Cancel.  Abort")
            F2.Close()
        End Sub
    
        Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click
            ' do something
        End Sub
    
        Private Sub Button3_Click(sender As Object, e As EventArgs) Handles Button3.Click
            ' do something else
        End Sub
    End Class
    



    • Edited by Acamar Thursday, December 21, 2017 1:05 PM example
    Thursday, December 21, 2017 12:58 PM
  • The user cannot select buttons on the base form while the dialog's active because of the modality. But the user needs to be able to select an unknown (to the program) number of buttons before clicking "OK/Cancel".

    Then what is the problem with that arrangement?  If you want code in the base form to continue only after the OK button in Form 2 is clicked, then don't use a dialog, handle the Form 2 OK button click event in a handler on the base form, and include the 'continue' code there.  It's a very standard toolbox-type arrangement, except that you base form is what would usually be the toolbox. 

    Or, create you own event, subscribe to it in the base form and raise it in the Form 2 button click event.

    I'd looked at that - almost the first thing I did before posting any of this. The main issue with that is that this code is in the middle of a subroutine and is only obeyed under certain (user-defined) circumstances. At other times, the code bypasses the user interaction described above and continues on its merry way. But I can't obey the continuation code until the user's finished playing with the buttons if he wants to. So the code has to  be split into 2 parts. As most of it's already been written (this user interaction is a late arrival), it's a nasty programming job. Basically move everything after the user interaction into a subroutine and call it either immediately (if no interaction) or after the interaction's finished - which means keeping a whole load of state information as to exactly what the program was doing at this point.

    My original question said: "What obvious solution have I missed please?", and the common consensus here seems to be "NO". So as I said above, I either have to do the nasty programming job or learn about asynchronous programming.

    This has been a fascinating journey into some of the guts of Windows programming, and I may well find time to play with async as see if I can get it to work. If I do, I'll report back here, as Frank L Smith asked me to. Meanwhile, thanks to everyone who helped, and have a good festive season.


    Peter

    Thursday, December 21, 2017 4:38 PM
  • Hi ptoye,

    Have you solved your issue now? If yes, please remember to close your thread by marking the helpful post as answer, it is beneficial to other community members who face the same issue.

    Thanks for your understanding.

    Best Regards,

    Cherry


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, December 27, 2017 7:23 AM
    Moderator
  • Have you solved your issue now? If yes, please remember to close your thread by marking the helpful post as answer, it is beneficial to other community members who face the same issue.

    I wish I had. After a lot of very interesting and useful discussion, the only answer that came up to my original question: "What obvious solution have I missed please?" was "There isn't one", which is hardly an answer. If you think that this post should be marked as an answer (or a non-answer) I can do that.

    I intend to do more investigations into async, but at the moment I've completely recast the program I was writing (with a lot of trouble and it's not finished yet) so that I can get on with what I was doing. So it'll be at least a week before I can do that, if I ever do!


    Peter

    Wednesday, December 27, 2017 9:30 AM
  • Peter,

    This thread is long, but probably I've written it somewhere. 

    You are trying to find the best way to hammer a nail with a screwdriver. 

    You won't find an answer on that given by somebody else or it should be one to make a fool of you.


    Success Cor


    • Edited by Cor Ligthert Wednesday, December 27, 2017 10:40 AM
    Wednesday, December 27, 2017 10:39 AM
  • Peter,

    This thread is long, but probably I've written it somewhere. 

    You are trying to find the best way to hammer a nail with a screwdriver. 

    You won't find an answer on that given by somebody else or it should be one to make a fool of you.


    Success Cor


    On your first paragraph, I don't think you've ever come up with a solution, just comments about how my UI design makes it impossible to find one. Telling me to understand Windows the Windows messaging system is like telling me that I can't drive a car without being able to understand the principles behind building it.

    Your second paragraph is not helpful. Constructive comments only, please.

    Your third paragraph mangles the English language as badly as I am mangling the VB language. I cannot understand it. English is my first language and I've been speaking it for well-nigh 70 years. I do  not take kindly to being called a "fool", if that is what you meant.

    Secondly,


    Peter

    Thursday, December 28, 2017 11:01 AM


  • On your first paragraph, I don't think you've ever come up with a solution, just comments about how my UI design makes it impossible to find one. Telling me to understand Windows the Windows messaging system is like telling me that I can't drive a car without being able to understand the principles behind building it.

    Your second paragraph is not helpful. Constructive comments only, please.

    Your third paragraph mangles the English language as badly as I am mangling the VB language. I cannot understand it. English is my first language and I've been speaking it for well-nigh 70 years. I do  not take kindly to being called a "fool", if that is what you meant.

    Secondly,


    Peter

    First paragraph: I did not write that. If you want to ride a car, you at least have to know where the accelerator is located. If you don't want to know that, than go after the car and push. 

    Second paragraph: Not for you but for those reading this long thread where you want a solution to nail your button with your screwdriver. There are many solutions, but you don't want to use them, beside that, you don't even want to know what a dialog form is.

    Third paragraph: Cheap and offending. However, what is called English language is a a language originated in England (therefore the name English), which is the result of a huge melting pot of other European languages. In contrast with for instance German and French it has no rules written down. Outside England it is even again influenced by other languages, even again European. But that is exactly what you write in this thread. Your way of how Windows Forms must be used seems to be the rule, however those rules are written down. Maybe you can investigate it a little bit. Many persons have given here the leads to do that. 


    Success Cor

    Thursday, December 28, 2017 11:23 AM


  • First paragraph: I did not write that. If you want to ride a car, you at least have to know where the accelerator is located. If you don't want to know that, than go after the car and push. 

    Second paragraph: Not for you but for those reading this long thread where you want a solution to nail your button with your screwdriver. There are many solutions, but you don't want to use them, beside that, you don't even want to know what a dialog form is.

    Third paragraph: Cheap and offending. However, what is called English language is a a language originated in England (therefore the name English), which is the result of a huge melting pot of other European languages. In contrast with for instance German and French it has no rules written down. Outside England it is even again influenced by other languages, even again European. But that is exactly what you write in this thread. Your way of how Windows Forms must be used seems to be the rule, however those rules are written down. Maybe you can investigate it a little bit. Many persons have given here the leads to do that. 


    Success Cor

    Cor, I don't want to start a flame war, but several things you have said require either a retraction or an explanation.

    First: I agree that you have to know how to use an accelerator pedal. But you don't have to know the mechanism by which it speeds up the car, only its effect. Getting too deep into the implementation details is of no use to the driver. But I think this analogy has run its course.

    Second: your comment that I don't even want to know what a dialog form is is insulting. I know what it is: it's a modal form which invites an input on pressing a button. I need a non-modal form, so using a dialog doesn't work. That's why I need a substitute. Comments about buttons (I assume you meant one on my shirt, not one on a Windows form) and screwdrivers are patronising. I realise that you speak from great knowledge of Windows internals, but I think you do not see the wood for the trees, if I may use an English expression. It should be simple: I have a particular need in a UI and asked if there was a solution. Sermons about how I shouldn't be asking for it are not helpful.

    Third: I'm sorry if you feel insulted, but it appears to be inviting people (including yourself?) to make a fool of me. I think the first part of your sentence meant that there isn't an answer. That's the conclusion I came to, and have said so in several previous posts.

    I do not intend to contribute further to this debate. If anyone else has constructive ideas, please post them and they will be accepted in the spirit that they are made.


    Peter

    Friday, December 29, 2017 2:54 PM
  • For those reading this thread. 

    It seems Peter does not want to understand this. However, going on with the "accelerator" that describes in fact exactly what is happening in this thread. 

    Peter translated that automatically to an "accelerator pedal". However, I wrote "accelerator". The Form he uses is in fact a trailer. A trailer has not always an "accelerator pedal". 

    That pedal is in fact the receiving of messages from the Windows system but those are only eaten by the active form in a forms application.

    A modal dialog is always active so that is a simple solution preventing that a Windows message is missed.


    Success Cor

    Sunday, December 31, 2017 10:39 AM