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.
Related
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.
I'm trying to build a Wizard framework in Windows Forms. I've managed to glean a lot of useful tips from this and other sites which have gotten me very close to success. However, I'm having a problem with displaying an ErrorProvider on any tab page other than the first page of the wizard.
My Wizard control is a UserControl. It contains a custom tab control that I've derived from TabControl so that I can hide tabs and ignore attempts to navigate between tabs using keypresses, along with the usual collection of Back/Next/Finish/Cancel buttons at the bottom of the control.
I've used reflection to allow me to raise the validation events on a particular TabPage that belongs to the Wizard Control when I hit the Next button. (I don't want to validate the whole TabControl, only the currently active page.) When I do this, I see in the debugger that my Validating routine for the controls on the current tab page is correctly called and I see that I've called the ErrorProvider that I've attached to the particular control (a TextBox in this case) with a valid error message. I set Cancel to true for the CancelEventArgs in the validating routine and that's picked up by the code that uses the reflection mechanism so that I see that I've failed and don't change tabs. And I set the focus successfully to the control that failed validation.
So all that appears to be working just fine.
Unfortunately, I don't see the ErrorProvider's cheery blinking icon unless I'm on the first tab page. For all of the other tab pages, there's no message visible at all.
I'm baffled. Any thoughts? I can provide code snippets, if helpful.
Thanks!
I assume that in your case the button that moves to the next step of the wizard is placed outside (below) the TabControl
I noticed that the icon is displayed correctly if I pressed the button without releasing the mouse button. It seems that the button outside the container gets focused event though a validation error has occurred (normally you would not be able to leave the active control).
I worked around this issue by registering an event handler for the buttons MouseUp event to "refocus" the TabControl:
private void cmdOK_MouseUp(object sender, MouseEventArgs e)
{
tabControl1.Focus();
}
Note: you also need to set your forms ActiveControl property the one of the controls that failed validation.
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 have an activity with a mayStop() method. I am having two issues with it that pertain to a hyperlink on the page.
The first issue is that if I hit refresh or the window's X I get a dialog box that wraps my mayStop() text with "Are you sure you want to navigate away from this page?" and "Press OK to continue, or Cancel to stay on the current page." That is fine.
When I hit the hyperlink, I only see my mayStop() text without the wrapping text. Why is that?
The second issue is that if I hit Cancel in response to the hyperlink click, hitting the link again results in not getting the mayStop() challenge at all. It is as if I am not hitting the hyperlink.
Has anyone run into these issues?
Any thoughts?
Thanks,
Doug
The difference in "behavior" is that the first dialog box is the one from the browser when you try to prevent the user from navigating away, while the other is PlaceController calling Window.confirm(). Each browser uses a different dialog box for the first case, so there's no way to mimic it for everyone, and it's probably not a good thing either (navigating away from the app vs. navigating within the app).
As for your second issue, the events are generated by the browser "history" changing; if you prevent navigating away (from the Place), the URL stays the same (there's noway to know what to do to "rollback" the change: History.back(), History.next(), History.newItem() but then you destroy the existing "next" history ?), so when you click again on the link, you don't make the URL change, and no event is fired.
It's expected that you use PlaceController.goTo to navigate when you use places, not Hyperlink or History.
I am trying to find the most usable/accessible way to implement a simple form dropdown list which will sort a list of products by pice and alphabetical order.
In your opinion is the dropdown more usable when there is a button that governs its submission or when it automatically submits onchange of the dropdown?
The research I have read is both for and against such methods and there is a variery of implementations on the web so interest to hear the thoughts of the community.
Thanks in advance
As a blind computer user either method works fine. I find that having a button to click is slightly easier for me then the onchange event firing. I wouldn't say it's a big enough difference to take into account though assuming the majority of your users will not be disabled. If your targeting specifically blind users I would not use the onchange event.
So long as you do not change focus or navigate to another page when the selection changes, either approach should work. The classic example of a problem dropdown is where it contains a list of other pages on the site, and navigates as soon as the selection changes. This prevents a keyboard user from using the list; they can't browse it, and can't navigate to any pages beyond the first selection, since it's impossible to navigate past those. So in cases where focus changes or the page navigates as a consequence, having a separate action (eg. Go button, or handling enter) to cause the navigation to take place is essential. This is likely where the advice you've read is coming from.
In this case, however, it sounds as though you are just updating content elsewhere on the page, and not changing focus or doing navigation. Simply resorting existing content should be fine.
Depends on your users and their respective expectations and the context in which it's presented.
As a blanket, general statement, you should have the drop down accompanied by very obvious submission button. That is the safer approach.
If you are refreshing page data or if the focus moves away after the dropdown option is selected, you should use a button to be accessible. If you fire the event on change, blind or keyboard-only users will not be able to use the dropdown menu at all if they are on windows with ie and chrome (so added together, a majority of the people on windows). As soon as they use the arrows to scroll down and make a selection, the first option they hit will be selected and the page data will refresh or the focus will move, making it impossible for them to navigate or select the second option, third option, etc. Below is a thorough explanation with examples so you can see what I mean.
Designers definitely don't like the buttons, but if you are blind and on chrome/ie, it is impossible to use a lot of dropdowns without it. I'm guessing Jared uses firefox or a mac.
http://pauljadam.com/blog/javascript/onchange-event-on-a-select-inputjump-menu-accessibility-problems/