next »

[Jeff W.]

Running a GWC app.  I removed the acceleratorname="Return" in the action defaults file for the "accept" action.  When an end-user hits the Enter/Return key instead of the Tab key in a form, it still fires the "accept" action.  The only way I can seem to somewhat control this is with an . . .

ON KEY ("RETURN")
   NEXT FIELD NEXT

However, this bypasses any AFTER FIELD code if present.

What is the solution to this?  Is there a way to make the Return key act just like the Tab key?

FGL version 2.32
GASD 2.32

[Jeff W.]

Upon further testing, it's actually firing the Cancel action and not the Accept action.  The Cancel action doesn't have an acceleratorName defined in the action defaults file.

[Reuben B.]

If the cancel action is being fired unexpectedly, check the value of int_flag.  If it has a non-zero value when the dialog starts, this could explain what you see.

P.S I strongly recommend you follow convention and use Return/Escape/Tab for accept/cancel/nextfield respectively.

[Jeff W.]

These accelerators are "industry" standards or conventions, but what if our client insists on having the Return key work like the Tab for nextfield?  What is the risk or danger of doing this?

[Reuben B.]

These accelerators are "industry" standards or conventions, but what if our client insists on having the Return key work like the Tab for nextfield?  What is the risk or danger of doing this?

If your client insists, get them to log onto any other web application that has a username and password field (facebook, gmail, hotmail, banking etc) and ask them what key they use to move between the username and password field, and ask them why they want to be different.

Whats the danger.  If you use Return/Escape/Tab this will most likely work for most combinations of browser and AJAX/Silverlight/HTML5 and whatever the future may hold.  If you do something different e.g. FourGen based code with F12 for accept, does F12 get passed through to the application or does the browser capture it and use it to open developer tools.

Was the int_flag the reason the cancel action was being fired?

Reuben   

[Jeff W.]

Thanks for the info Reuben.  This will help backup our point of view with the client.  The INT_FLAG was set to zero but we're not taking that approach any longer.