#Wxwindow findfocus example update
#Wxwindow findfocus example code
#Wxwindow findfocus example windows

#Wxwindow findfocus example code

In the above examples, all the code for dealing with focus is in the frame itself - but in many situations you will want to have the focus-handling logic within the input field, like this: The above scheme works quite well when you have a relatively simple input form, but doesn't work as well if you have a more complex form involving subclasses of wx Text Ctrl. To prevent this problem from occurring, you need to add code to your application which remembers if the wxFrame has been closed, and have your EVT_KILL_FOCUS method check to see if this has happened before it attempts to access any of the input field's methods.

#Wxwindow findfocus example windows

Under Linux it will work perfectly well, but it will crash horribly under MS Windows - even though your code looks perfectly simple and correct. Your application will crash in a most public and embarrassing way. If you then attempt to access a method of the input field object in your on Focus Lost method, for example like this:

Send the currently focused input field a 'Focus Lost' event.īecause wxPython automatically handles the destruction of the wxFrame and all contained wxWindows within it (including your input fields), this means that if the user closes the wxFrame you will actually receive the EVT_KILL_FOCUS event after the input field object itself has been destroyed.

Close the wxFrame, and destroy all objects related to it.

Now, when the user closes a window (for example, a non-modal dialog box containing input fields), Microsoft Windows does things in the following (completely illogical) order: These events from the operating system are then passed directly on to your wxPython application via the EVT_SET_FOCUS, EVT_KILL_FOCUS, and EVT_CLOSE commands. In this case, there are several events which get sent to the input fields and other user-interface elements, including events such as: Unfortunately, however, due to the wonderful vaguaries of Microsoft Windows, the above code can actually cause your wxPython application to crash in certain situations.īecause wxPython is built directly on top of the native operating system's own user-interface elements and their related event-handling logic, oddities of the underlying operating system unfortunately do flow through to your wxPython application. The scheme described above may seem like a straightforward way of dealing with the user moving into and out of input fields.

# Field value changed -> respond appropriately. You might want to do this to remember the value of the field as the user moves into the field, and only perform an action if the field's value was changed, like this:ĮVT_SET_FOCUS(self.field, self.onFocusGained)

Of course, you can also use EVT_SET_FOCUS to make wxPython call a routine when the user moves into the field as well. ''' Respond to the user leaving our input field. For example:ĮVT_KILL_FOCUS(self.field, self.onFocusLost) The usual way to perform these actions is to use the EVT_KILL_FOCUS command to tell wxPython to call a routine as soon as the user tries to move out of your input field. Another example might be to validate the contents of an input field as soon as the user tries to tab out of the field, rather than validating when the user clicks on the 'OK' button to close the form.

#Wxwindow findfocus example update

For example, an 'invoice' input form may need to update the invoice total at the bottom of the form whenever the user enters a value into one of the 'unit price' fields. When you use a complex input form in your wxPython application, you may find that you need to perform an action as soon as the user tabs out of an input field.

Using Focus Events for Pleasure and Profit Surviving with EVT_KILL_FOCUS under Microsoft Windows