View Full Version : Navigate in forms using ENTER key instead of TAB

2 Aug 2010, 5:12 AM

I am evaluating Ext JS to see if we can use it in our existing RIA and I'm facing one last issue to deal with, to be able to say 'Go'.
Our application has a strange way to navigate in a form from one field to another and our users are used to hit ENTER key to do that instead of TAB.

So, is there a way to do that? Something like traping the ENTER key and make ExtJS components act like if TAB key were pressed would be helpful.

Thanks in advance!

2 Aug 2010, 5:13 AM
That's so far off from all current standards that you should just retrain users.

2 Aug 2010, 5:19 AM
Believe me, I totally agree with you, and that would be an option if we could switch all our application to correctly deal with field navigation (meaning TAB key). But it's about 8 years of development that must be reviewed and re-tested to do that.
My boss will certainly prefer to give off the idea of using Ext, and that is not my wish.

2 Aug 2010, 5:34 AM
Our original DOS application did this and so when a Windows application was created this behaviour was copied. Fortunately, when web development started I was able to convince my boss that using Enter that way was really outdated.

Trapping the enter key won't be the problem, but performing a tab-to-next-element might be a problem.
Try if the focus changes when you fire a tab key event using Animal's Ext.Element.fireEvent (http://www.sencha.com/forum/showthread.php?89309-Manually-firing-DOM-events&p=425656#post425656) code.
If it doesn't, then you're stuck with manually finding the element with the next tabIndex and focus that element.

2 Aug 2010, 6:27 AM
Our app did this too. We have a huge Unix user base using VT100+ green screen terminals.

They've slowly "upgraded" to a Windows interface which uses TAB to navigate.

And now I'm dragging them to a web UI which uses TAB.

2 Aug 2010, 6:44 AM
That's exactly our situation, our application was running on unix terminals and we switched to web app in 2002. Unfortunately, people who was able to decide at this time, considered that it worth to spend days and days to reproduce on a web/app this out of standard navigation mode.

I've tried to fire an event using 'Animal's fireEvent function, but it doesn't seem to work. We have already the mechanism to decide which field is to be focused next. We can always use js code to attach our listener and to focus the 'next' field, but I was wondering if there is a better 'Ext' way to do that.

2 Aug 2010, 6:49 AM
Also, because we will use a lot of EditorGridPanel, I found this that may help : http://www.sencha.com/forum/showthread.php?4888-Disabling-Tab-And-Enter-In-EditorGrid&p=77429#post77429

But when I try this, I have an error because my grid.activeEditor is null. Seems like, when I hit the ENTER key, the editor is already stopped before the call to onEditorKey. Something changed in 3.2 version?

2 Aug 2010, 7:16 AM
It seems that you cannot programatically fire a TAB event.

Unfortunately, people who was able to decide at this time, considered that it worth to spend days and days to reproduce on a web/app this out of standard navigation mode.

They are just wrong, and forcing a wrong decision upon the organization.

2 Aug 2010, 7:18 AM
I found a nice solution to deal with EditorGridPanel thanks to this post Adding a new row .... (http://www.sencha.com/forum/showthread.php?28911-Adding-a-new-row-to-editorgrid-by-tabbing-on-last-row-column&p=135745#post135745)

I had to change a little bit, so the code looks like this :

sm : new Ext.grid.RowSelectionModel({
singleSelect: true
,onEditorKey : function(field, e) {
if (e.getKey() == e.ENTER) {
var k = e.getKey(), newCell, g = this.grid,ed = g.activeEditor || g.lastActiveEditor;
newCell = g.walkCells(ed.row, ed.col-1, -1, this.acceptsNav, this);
newCell = g.walkCells(ed.row, ed.col+1, 1, this.acceptsNav, this);
g.startEditing(newCell[0], newCell[1]);

})Maybe this helps somebody

2 Aug 2010, 10:40 AM
i hate this old ENTER behavior... to archive this in any window gui tool you should override everything... in web applications its more tricky then native gui tools... actually fuddy-duddy people who will use our products is the point... we should override them...

for overriding i found another solution that you dont have to override whole onEditorKey method, using an interceptor to alter it (http://www.sencha.com/forum/showthread.php?105914-Disabling-TAB-keys-or-altering-its-behavior-on-EditorGridq)

i hope it helps too