I have a TEdit in a Delphi VCL form app (contained in a TFrame instance, if it matters). After a user indicates they are finished editing, by clicking elsewhere on the form, the caret and focus remain on this control until I click on another control, which then takes the focus. However, I want the TEdit to loose focus regardless of where the user clicks. I expect I can use ActiveControl := nil to end focus on the selected control, but I am uncertain where to invoke it.
What I want is for the focus to leave the selected control without necessarily having to transfer it to another control. I could end focus in the form's OnClick event, but that will not work if the user selects any of the other controls (also contained in frames) on my form, since the form's OnClick event is not triggered. It seems inelegant and tedious to provide separate OnClick events for each additional item on the form.
What is the global solution to achieve this behavior?
Try using the TApplication(Events).OnMessage event to look for WM_LBUTTONDOWN messages.
You can use the VCL's FindVCLWindow() or FindDragTarget() function (both in the Vcl.Controls unit) to see if there is a TWinControl located at the click coordinates. Or simpler, you can use the VCL's FindControl() function (also in the Vcl.Controls unit) to get an TWinControl directly from the message's target HWND.
If no control exists under the mouse, or if the control is not focusable (its CanFocus() method returns False), then set ActiveControl=nil. Otherwise, do nothing, and let the clicked control take focus on its own when the message is processed.
Related
I've created a GtkComboBoxText using gtk_combo_box_text_new_with_entry. When I type into it, the "changed" callback is called for every letter.
How can I tell when the user has finished their entry?
I'd be happy to require the user to press 'Enter' at the end, but that doesn't call the callback.
(I'm using GTK+2.)
(Stackoverflow suggested another Q&A which put me on the path to enlightenment. I hadn't seen it while searching before I wrote my Q.)
It boils down to
g_signal_connect(gtk_bin_get_child(GTK_BIN(cb))/*entry*/, "activate", G_CALLBACK(entryActivated), NULL); where cb is the GtkComboBoxText (GtkWidget*). The callback is called when 'Enter' is pressed.
Pressing enter in a GtkComboBoxText that has an entry causes the child GtkEntry to emit the activate signal.
If the GtkComboBoxText contains an entry (via the 'has-entry' property), its contents can be retrieved using gtk_combo_box_text_get_active_text(). The entry itself can be accessed by calling gtk_bin_get_child() on the combo box.
https://developer.gnome.org/gtk2/stable/GtkEntry.html#GtkEntry-activate
The combo box might be considered as part of a form that has its own apply button.
You can also connect to GtkWidget signals. I can't say which event but there is one that is emitted when a widget loses keyboard focus to another widget in the same window. This would allow save on tab out. This is distinct from the window losing focus to another window which is a signal emitted on the GtkWindow. As the widget that has focus in the window does not change when a window loses focus.
After looking at the documentation, I'm able to persist state in the following two cases:
When a WebviewPanel is hidden (ie, the user switches tabs) using getState/setState
When the user restarts the VS Code by implementing a WebviewPanelSerializer
However, I don't see a way to persist state when the panel is destroyed (ie, the user closes it or calls dispose). Here's my scenario:
I execute a command to show the WebviewPanel
I have an input box in the HTML content. I type some string in and press a button to save it. Upon saving, I save it using setState and then append a div with the entered text into the webview.
I close the panel and execute the command again. The panel does not have the appended div.
You have 2 options:
Recreate the additional div when you find saved state (e.g. the input from the user).
Use retainContextWhenHidden to keep the content of the webview, even if it is moved to the background.
The latter won't help when the user closed the webview, however, and is much more resource hungry than the state save/restore operation.
I'm trying to create a simple test program in Gtkada to bring up a Dialog box upon leaving a specific textbox. I have managed this part, but am having problems resetting the focus back to the original textbox when the Dialog's 'Ok' button is pressed.
The general idea is that the user enters something into a textbox and when they click/tab out of the box (focus out event), some simple Alphanumeric validation is done. If the validation fails, the user is warned with a Dialog, and focus is returned to the textbox they entered erroneous data into.
All I am after is a simple example of how to set the focus back to a textbox when you close the Dialog box which clicking out of the textbox originally called. In Gtkada... I'm using version 2.2 of Gtkada. I can't change the version of Gtkada, or use a different program or language!
Much obliged!
Tim
The most elegant solution, GUI-wise, is to do the validation on a leave_event on each input field, and if that fails display an error message (in red or some such) next to the field. But do not display a dialog or force the focus to a specific field, that would interfere with what the user is trying to do (imagine: I enter an incorrect email address, press tab, get the dialog which I do not read (like most users), start typing my name for the next field, but since the focus went back to the email address, I have no overridden that one and lost my previous input).
If you still want to grab the focus, Gtk.Widget.Grab_Focus is the procedure you want.
I have a big form on extjs which opens in window, and, for speed reasons, i cache it in hidden panel. There is can be only one window at time, so the cached form is single too. On show event i add form to window, with no rendering and with suspendLayout option for form. On close event i move the form to hidden panel, with panels add method. I do not use remove method not for window not for panel. So, for several times all perfect, but after 3- 5 window openings form lose all of its events: buttons, comboboxes, triggers and other controls are not responding. Where is the problem? Thank you.
It is difficult to know for certain but my theory is that the observable object that your listeners are setup on is garbage collected at some indeterminate time period of inactivity.
I have seen this occur on an object representing the body of an iframe that is watched from the parent window. Click events from the body will work for some time and then all events will stop.
One way to test the theory is to store object reference in a global variable - this is NOT what you want to do in any app but worth a try just to test. Global vars are never garbage collected.
I want to know if there is any way to navigate Dialog components by pressing the Enter Key in the same manner natively implemented by the TAB key?
Though I haven't tried it by handling the keyDown and keyUp events certainly it seems doable. Though you may not be able to intercept the browser produced dialog boxes this way and other dialogs created using Window.alert(). How are you creating the dialogs ?
The tab key is the browser doing the work of changing focus - nothing special needs to be added, you'll find that tab works on any form on the internet (except where explicitly disabled for some reason...).
To move focus with the enter key, you must listen for the onkeydown event (focus change via tab also occurs onkeydown, so selecting this for consistency), check if it was the enter key, and if so, move focus to the next element in the list.
Typical tab focus behavior involves the browser checking the tabIndex of the elements on the page, and finding the next element on the page with a higher tabIndex, or the nearest subsequent sibling/cousin element. I don't have a method to implement this easily, so instead I'm going to focus on just going to the next widget.
GXT 3's FormPanelHelper has some handy methods to look for all Fields - this code could be used as a basis for non-GXT fields as well. Track all FocusEvent and BlurEvent from the fields found in the dialog, and use that to always track the currently focused field. Add a key handler to the dialog itself, to capture all key events, and check if one is the enter key. If so, figure out what the next field is from the currently focused field, and invoke .focus() on it - this will trigger the focus handler described above, so your bookkeeping will be updated correctly.
And as #eliran-m noted, consider leaving the tab key alone - don't get in the way of users navigating the way they are used to. Adding new functionality might be a good thing, but taking away expected behavior probably isn't.