The whole idea of "waiting" is wrong.
In a Windows application nothing should wait for anything. More generally, in whole programming of multitasking systems, CPU should not also wait for anything; if some thread is in a wait state, it should not waste a single tick of the CPU time which should do something else. But before you understand this, you have to grasp the idea of at least single-threaded event-oriented UI, which works not wasting any CPU resources at all until the hardware interrupt from an input device invokes some event which your application responds to.
As you are missing the whole fundamental programming paradigm, no Quick Question & Answer
can help you immediately. Nothing can replace systematic study of the subject.
However, even though your exact requirements are, by far, not clear, I'll try to give you a hint. As I can understand, you expect the user to meet some condition by typing a string value in a text box. Then you can handle the event
Control.TextChanged Event (System.Windows.Forms)
In the handler of this event, you can take the current
value of the text box and check up if one or another condition has met. In this case, you perform the next action.
However, I would strongly recommend not doing it this way. Or, as a maximum, you can provide a user with some visual feedback of having the condition met. Typically, it could be the enabled state of some button or other control (which would be grayed out if the condition is not met, and not
), but it could be, say, change in some color. If you take some more active action, it can be too confusing to a user. Besides, you can perform final validation of all entered data just before it is about to be used. In other words, don't stress the user and limit the user's actions too intrusively.
Besides, never call
methods what parsing can be used. Instead use
if (int.TryParse(message.Text, out pin))