In catching a "key" event in CKEditor, we have a case where a dialog is displayed if a key is typed within a certain HTML span.
After the dialog is dismissed, the 1st key typed does not register on the key listener, but all subsequent keys DO register.
Is this something anyone else has seen?
We're using CKEditor in its inline form, in an application framework based on GWT (Google Web Toolkit). It's possible that GWT is somehow messing with event handling, but I'm not sure how that might be.
I tried setting the event priority very high, but that didn't solve the problem.
After I noticed that the text insertion cursor was not visible until after I tried to type a character after the dialog was dismissed, I tried explicitly setting focus after the dialog is dismissed. This ended up fixing the issue.
I'm not sure why focus would not be on CKEditor until after I did that, or until after a character is typed, but that appears to be the fix.
Related
I am developing an application for the desktop with Flutter. I had to implement the form with multiple input fields. I really need to make the whole focus flow and I have used the FocusNode class to move from one input field to another. Everything is based on the submit event, so when I hit the Enter button on the keyboard it moves to the next field. It is pretty ok, but I have to change it from Enter key to Tab key which is more natural for the desktop users. Have you got any idea what can I do here to achieve such a result? Is there a way to trigger the submit event by different key (than Enter)?
This bug is for making it easy to bind keys to actions. Once that's complete, one of the intended use cases is to add tab support for form field navigation. There's been a lot of work in that area recently, so I wouldn't recommend putting time into working around this yourself.
For the time being, this is a Material-UI question.
I have a situation where the tab key ceases to move the text cursor between TextFields. At the moment, I have no idea where in my code this is happening, and I am hoping someone can point me in the right direction so I can start looking.
Here’s the setup:
A mouse click causes a Dialog to be displayed. The Dialog has
several TextFields as well as 2 FlatButtons, “cancel & “submit”
At this state, tabbing between fields works as expected.
If I hit the “cancel” button, an event is fired which updates state (including the display of the Dialog) and the Dialog is closed. I can repeat the process from the top with no issues.
If I hit the “submit” button, an event is fired which does some async stuff (using rxjs epics).
On success, the epic fires an event which updates the state (including the display of the Dialog)
If I now try to repeat the process from the top, the tab key does not respond.
I am in the process of migrating to v1, and checked some of the v0.* components – they have the same problem – I don’t recall that being an issue before… Possible conflict between the two versions of the library?
Figured it out. Yes, there is a conflict between the v0.20 and v1.0 of the Dialog component. At least when you have one opening on top of another. Having changed all Dialogs to v1.0, the problem disappeared.
By the way, its not that the tab key wasn't responding - it was responding in the lower Dialog component and not in the top (latest to be created) one. This problem disappeared once the same version was used for both.
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 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.
I need to focus a text input into the Facebook login popup. I am using a virtual keyboard to simulate a physical one, but when I click a key, the text input lose focus and the letter is not written into the field.
How could I maintain the focus in the text input?
I'm not sure if creating your own virtual keyboard is a smart idea since all mobiles already have one in there, you just need to set useSoftKeyboard in Flex.
Also, you can always remove focusability to your components by setting focusEnabled and hasFocusableChildren to false.
I finally came to another solution... Using getElementsByTagName('theElementID'), I could get a reference to the textInputs in the browser, and I could modify its attributes...
For example,
emailStringObject =this.html.htmlLoader.window.document.getElementById('email');
emailStringObject.value="example#correo.com"