You'll notice that both GotFocus and LostFocus are hidden from the Properties window to prevent accidental usage. Instead, use the safer Enter and Leave events. ![]() ■Tip If you don't want to perform validation, but you simply want to update some part of your user interface when focus changes from one control to another, you still shouldn't use the GotFocus and LostFocus events. If both controls have invalid data, they may fight endlessly among themselves, trying to move the focus somewhere else and trapping your program in an endless loop. If you try to direct the user back to the original control, or if you change the focus in another way (for example, by showing a message box), you'll end up triggering an additional LostFocus event from the target control. Unfortunately, this approach is dangerous, because it's not safe to change the focus inside a LostFocus event handler. It may seem tempting to write "do-it-yourself" validation by responding to a control's LostFocus event. ![]() ![]() Oddly enough, if you change focus using the mouse or by calling the Control.Focus() method, the order of events shifts slightly so that the LostFocus event occurs earlier: The same pattern plays out when you change focus using other keys (like Shift+Tab), or when your code calls the Control.Select() or Control.SelectNextControl() methods, or sets the ContainerControl.ActiveControl property. For example, if you move from TextBoxl to TextBox2 by pressing the Tab key, here are the events that fire: ![]() When you navigate from one control to another, a series of events unfolds.
0 Comments
Leave a Reply. |