What is the difference between the LostFocus and the Leave events of TextBox?
Check the notes section on these links:
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.lostfocus.aspx
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.leave.aspx
According to MSDN, there is difference when changing focus of a control. The Leave event occurs before a validation and LostFocus occurs after validation.
UPDATE: 14 Feb 2019
I see that I'm still getting views and upvotes on the answer that I posted couple of years ago. It has now become imperative that I include a (rather important) quote from the MSDN links above to avoid confusion among new programmers (note the difference of order esp. in case of focus by using the mouse or by calling the Focus method):
When you change the focus by using the keyboard (TAB, SHIFT+TAB, and
so on), by calling the Select or SelectNextControl methods, or by
setting the ContainerControl.ActiveControl property to the current
form, focus events occur in the following order:
Enter
GotFocus
Leave <--- before validation
Validating --
|<--- validation
Validated --
LostFocus <--- after validation
When you change the focus by using the mouse or by calling the Focus
method, focus events occur in the following order:
Enter
GotFocus
LostFocus <--- before validation
Leave <--- before validation
Validating --
|<--- validation
Validated --
N.B: Emphasis on text and indicators in the quote added by me
They happen at different points in the control's lifecycle. Depending on the method used, validation happens after Leave and before LostFocus.
See MSDN: http://msdn.microsoft.com/en-us/library/system.windows.forms.control.lostfocus.aspx
Leave() event means that first executes keyboard event and then executes mouse event where as Lost() event means that first executes mouse event and then executes keyboard event.
To sum up, it either won't work for the keyboard or it won't work for the mouse. Considering you can't predict what input method will be used it's not very helpful.
However, that's not my point. LostFocus will happen when the form loads, Leave does not.
This would turn the text box yellow when the form is loaded.
Private Sub txtBox_LostFocus(sender As Object, e As EventArgs) Handles TextBox.LostFocus
txtBox.BackColor = Color.Yellow
End Sub
This would not.
Private Sub txtBox_TextLeave(sender As Object, e As EventArgs) Handles TextBox.Leave
txtBox.BackColor = Color.Yellow
End Sub
Related
I'm working in a legacy application using MFC.
We have a mechanism to enable/disable controls depending on some business logic.
This mechanism is implemented in the CView-derived class. The way it works is all the views in the application derived from a common CView-derived class (CBaseView) and on the PreTranslateMessage all controls of the view are enabled/disabled.
This worked fine so far because all controls send at least WM_PAINT message when they need to be painted. So the system worked without the user having to move the mouse or anything. I recently added some drawing features and I had to use WS_EX_COMPOSITE to get ride of some flickering. With this flag activated my CView-derived class is not getting any called to PreTranslateMessage when creating the view....so the controls are not disabled until the user moves the mouse over the control.
I understand there is no way to send WM_PAINT using WS_EX_COMPOSITE but is there other message I can use to get the same behaviour???
Edited:
I am currently using the OnIdle approach but it has a big drawback, the windows doesn't become idle until after drawing all the controls...so when you enter the screen al controls are enabled and inmediately they are disabled...this makes a quite ugly effect!
More solutions???
Thanks in advance...
The logical place to enable/disable controls would be CView::OnUpdate, it is called by the framework after the view's document has been modified and from OnInitialUpdate(); you can also call this function if there is some change that would trigger re-evaluation of your business logic.
EDIT
After reading the question a bit more closely, what you could also do is to post a private message at the end of OnInitialUpdate and "catch" it in your PreTranslateMessage:
PostMessage(WM_APP, 0, 0);
Calling InvalidateRect followed by UpdateWindow against the window in question will mark the entire client area as dirty and force an immediate repaint. Remember that WM_PAINT is not really a message, in the queue in the usual sense, it is pushed out after all other messages have been processed for that window, which would include any invalidations of the area being drawn. No message is generated at all if there are no invalid segments of the active window display.
I'm currently trying to toggle a 'Locked' element so that it is no longer locked once a check is performed. In the properties of the button, I have set the default value to be 'Locked' so that the user cannot use it's functionality.
When another button is clicked, my macro runs a process and if the process returns true then then the other 'Locked' button should be 'Unlocked' and a textbox containing a name should be 'Locked' to prevent alteration. The processing is done in a module called 'PNC_Module2' and the form that I wish to lock and unlock elements on is called 'folder_creator_window'.
I'm currently using the following lines to try and achieve the 'Lock and Unlock' but it doesn't seem to be doing anything:
'This is supposed to unlock the create_folders_button
folder_creator_window.create_folders_button.Locked = False
'This is supposed to lock the p_name_textbox textbox
folder_creator_window.p_name_textbox.Locked = True
I haven't included the rest of the code as it has no real baring on what occurs here.
Seeing the rest of your code may reveal the problem as your syntax looks ok
But on your quest as asked The normal method of toggling is to reverse the current condition using NOT. ie to toggle Locked on CommandButton1 on UserForm1 you would use:
UserForm1.CommandButton1.Locked = Not UserForm1.CommandButton1.Locked
I have a bunch of control objects (TextBoxes, to be precise) that get injected into my code using the #FXML annotation during the FXML load.
I would like to save the states of these controls, specifically the text values, when the user closes the Scene by clicking the close box on the title bar.
However, when I trap the CloseRequest event in an OnCloseRequest handler I find that the values of the control variables are null (the original injection works, so this is something that happens in between the loading of the FXML and the calling of OnCloseRequest).
Can anyone explain this behavior and/or suggest how I can get the functionality that I want?
TIA
onCloseRequest is
Called when there is an external request to close this Window. ...
(from Javadoc). One of the meanings of "external request" is when you close the window through OS native window close button. The closeRequest event is not triggered through the programmatic stage.close() or stage.hide() calls. So consider to handle onHiding or onHidden events.
Otherwise post your OnCloseRequest handler code.
I just started maintaining a set of embedded Python plugins for a Qt application. I'm also new to both PyQt and Python, so bear with me.
I have an implementation of a QTreeWidget in one dialog where the "expanded" signal is not being caught by the corresponding handler. I have another dialog where it works just fine.
In the problem dialog, I can verify that the connect was successful.
connected = wdg.connect(wdg.treeView_,SIGNAL("expanded(QTreeViewItem*)"), wdg.expanded)
evaluates to True. When I click on the child indicators to expand an item, the [+] signs change to a minus, but nothing else happens. Likewise, when I click on the [-], it toggles back to [+]. I have set the ChildIndicatorPolicy to initially set the indicator to SHOW in both cases.
In the dialog that works OK, when the user clicks on the plus sign, the 'expanded' handler is executed. Only the indicator toggles when it is clicked.
My handler code is simply:
def expanded(self, item):
logging.debug("In expanded handler")
I have a breakpoint at the logging call, but the statement is never reached.
I the failing dialog, I have another signal that's connected immediately before the one above, and it works just fine:
wdg.connect(wdg.treeView_,SIGNAL("currentItemChanged(QTreeWidgetItem*, QTreeWidgetItem*)"), wdg.itemChanged)
Is there anything that could prevent an expanded signal from firing or being caught? Another event perhaps? What should I be looking for? I realize that my nomenclature may be a bit off, and I welcome any correction in that regard as well.
The signal for a QTreeView expansion event is "expanded(QModelIndex)".
Alternatively, consider using the new style signal/slot syntax. I find it much easier than looking up the exact argument type for a particular signal.
wdg.treeView_.expanded.connect(wdg.expanded)
I found the problem. Despite the misleading name, the object is a QTreeWidge. When I replaced the name of the signal from "expanded" to "itemExpanded" and changed the parameter type to a QTreeWidgetItem*, everything worked.
wdg.connect(wdg.treeView_, SIGNAL("itemExpanded(QTreeWidgetItem*)"), wdg.expanded)
I have a Glade GUI description file with a GtkTreeView in a GtkHBox in a window; and there's a handler for the row_activated signal. Now, Glade has automatically set the "events" property (inherited from GtkWidget) of that treeview to some value (GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK). And there are two strange things with this:
removing the pre-set value (so that the property is empty) doesn't seem to break the application (at least not with the old GTK 2.10 I have atm).
in fact, an annoying bug I has seen before (where the treeview items would not correctly react to expand or collapse clicks) is now gone!
I have yet to test this with a newer GTK version, but the question is already there: exactly what is the purpose for this events property? And why does Glade automatically and unnecessarily set it to some value? Does this have some side effects I'm not aware of?
It's a bug in glade, it always sets the event property of widgets it create. It has no notion of the default value of a property so it always sets it.
Doesn't this mask indicate the events you're willing to receive? In this case, you'll probably want to receive notification that the user has clicked or double-clicked an item in the GtkTreeView, and you'll want to register callbacks to handle these events.
me.yahoo.com/a/kUQ7zeQ: but even if I set the property to an empty string as mentioned, the row_activated handler is still called when I double-click on a row (or press Enter or Space). So the treeview still gets events...