How do I specify which button on the form is the default button which will be pressed when someone presses Enter from anywhere on the screen?
You can't do this in oracle forms with normal functionality.
The only thing you can do if you really want to accomplish this is to re-map your enter key see the following link on how to do this.
Then you can map your enter key to a key-trigger and in that key-trigger you can put the code you want to execute when the enter-key is pressed.
The only downside to this is that in every application the enter key is pressed the same key-trigger will be triggered if it exists in your application. So you can't use this method to only use the enter key in 1 form and normal use (go to the next field) in the other applications. Then you have to make in every application that key-trigger with the code next_item;
Related
I currently have a custom portal with a custom version of the form widget that doesn't have any UI Actions (OOTB inclusive).
We also have a custom widget (let's call it "actions widget") where we control all the actions we need to take in the record.
Currently I need to create a "Save" button inside the actions widget where the user, after filling the form, can click on the save button to update the record.
I am unable to find any way to make this button work. The keyboard shortcut "CTRL + S" works perfectly but I have no idea what type of functions and/or methods this shortcut calls.
If this is too complicated or not possible I can also fetch the fields one by one (there is not a lot of them) and update the record with that information.
Can you guys assist me with this?
Thank you in advance.
In ng2-smart-table when user add data and instead of add data clicked on cancel button and again clicked on add then it shows old field data.
I need to set that when user clicked on cancel button, His field data must be clear.
Demo
I have searched a lot but I didn't find any help and I have also checked in it's doc and they are not providing it's event.
In the ng2-smart-table doc, there is no any event for this. If you want then you might update it's node-module file.
Make sure after update that you will not get it changes when you make a build of the app.
I have set the tabindex of TexInput controls in my Adobe Air works fine with tab key. Now I want to do the same with the enter key. I mean when I press enter key in the TextInput, next control should be selected.
In C# we can do the same with SendKeys and as per my knowledge there is not such way in Adobe Air.
Here is my added event
// get key presses only when the textfield is being edited
inputText.addEventListener(KeyboardEvent.KEY_DOWN,handler);
function handler(event:KeyboardEvent){
// if the key is ENTER
if(event.charCode == 13){
// WHAT ???
}
}
Find the instance with next/previous tabIndex
Depending on what control you are using, either call setFocus() method on this control (if it has one), or set the focus property of the stage to this instance. Set it to null if you want to remove focus at all.
I am making a very simple feedback form for an MS-Access application I'm working on. It consists of a textbox (for comments), a Submit button, and a Cancel button.
In your opinion, when the focus is on the textbox, is it more intuitive for the Enter/Return key to click the Submit button or move the cursor to the next line within the textbox?
Edit: The textbox is obviously multi-line.
Standard Access UI is that in a data entry form, the ENTER key is equivalent to the TAB, i.e., moves to the next control in the tab order.
The exception to this default behavior is textboxes that are bound to memo fields. In that case, the default is to have the ENTER key insert a CrLf in the bound memo. Textboxes have a property for this.
In a feedback form, it seems to me that the ENTER key should create a new line when the focus is on the textbox where the user is to type the feedback. ENTER should submit the form only when the focus is on the SUBMIT button.
All that said, your terminology sounds very web-like (nobody uses "submit button" in database forms programming, and certainly not in Access). I like certain aspects of HTML forms and the ENTER key, but have learned from watching others that 99% of the users out there don't know that in an HTML form the ENTER key submits the form (when the focus is not on a multi-line input box).
It's possible to set a command button on a form as the default button, such that hitting the ENTER key will click the command button, but for anything other than a dialog form, that's usually inadvisable in my experience. Users don't expect the ENTER key to execute a command button and making it do so is just likely to confuse them, even if it does make the Access form behave something like HTML forms.
I'd suggest that this depends on your layout: in an obviously multi-line textbox, the average user might expect Enter to move to a new line. In a single-line textbox, we generally don't expect that behaviour.
Depending on the structure of the form.
If the form has several textboxes, I expect it not to send the data when I hit Enter, except maybe on the last text box. Hitting Enter should do nothing, or move the focus to the next text box if you're feeling creative (most users will find this behaviour strange - it is not common in WinForms to move between input fields on pressing Enter).
If the form really consists of one text box and a submit button, then maybe sending the data when i hit Enter is ok, but I'd still be careful - users will not expect this behaviour, except in obvious places (like Google's search text box), and it will annoy the users if they accidently hit Enter and have their incomplete form being sent.
For a multi-line textbox, yes. It's more intuitive for the Enter key to go to the next line. However, in almost every other case (at least for my users), the Enter key should "hit" the "Submit" button.
Caveat: Most of my users use forms with textboxes to do a Search function against the database, which then populates textboxes in another form that disallow editing. My spiffy way to avoid them creating "new" customers that aren't real.
I have a form with multiple submit buttons, each of which is relevant to how the user wants the data saved and/or loaded.
The problem is (or was) that if a user pressed enter on the last (or any other) input within the form, the submit button that seemed to be called was the "load saved formed" which is at the top of the form. All attempts to user javascript to have the return button default to the "save form" seemed useless, almost as if the browser was too busy already submitting the form to have any js interfere.
Finally, in FireFox 3.5, I actually had the server-side script echo out what it received for the post variable and discovered that none of the submit button values were being passed back to the server. As it turns out, I have hooks in the script for when the user hits "Save" or "Save and Print", etc, but if the user uses the "load page" it simply updates a variable and continues loading the page normally with that variable in context.
So with no submit button value at all, it did the same thing, it simply loaded the page.
So, on to the big question:
Is this typical browser behavior? Maybe even reliable browser behavior? Will hitting enter always submit the form as though no submit button was pressed at all, or do some browsers like to pick a button to use as the default when the user presses enter?
If it is typical behavior, what is the suggested course of action? I was going to have the script save anything no matter what, so long as there was data in the form, but then I realized that this was even more dangerous, because if the user loads one saved form, changes there mind, and changes the form dates and hits "Load Form", then it will save the form data from the pervious form for the new dates they have requested.
I considered setting it up so that changing the load form inputs (selects with dates and other particulars) would clear the form so that the server still recieved an empty form and thus would not overwrite any previous data, but this is risky as well, as many users will certainly notice and think that their data has been lost, etc, and there is always the slight chance that the user will be almost done with the form, go up to the top and fiddle with the form-load selects just to confirm they chose the right what nots and then be forced to start from scratch.
I should just have two forms, one for loading, one for the data, but the problem with that is that all of the data in the load part of the form does get used by the main form. I could write more js to combine the two on submit, or hide the data in the second form, but all of that seems clunky.
Essentially, I need a setup such that the top part of the form is independent of the main form, but not vice versa. Submitting the upper form does not submit the lower, but submitting the lower does submit the higher.
Okay,I've gone on long enough. Basically I'm wondering if a solution already exists or if anyone else has run into this and found a clever fix. I thought simply having the form save whenever the form wasn't empty was pretty clever, until it occurred to me that when the user goes to the page, it auto-loads the most applicable form given the date, and thus changing the load variables will almost always caused trouble.
Having read the possible duplicate that Artelius was good enough to draw my attention to, I'm still unclear on the consistency across browsers regarding the Enter button as submit.
It seems that almost everyone in that question assumed that hitting enter presses the first available submit, which was also my assumption until a friend suggested I hide (via CSS) another submit button at the top of the form with whatever I wanted enter to achieve. It was when this got me the same results that I finally viewed what was being passed to the server (ie nothing in terms of a submit value). So that means either
a) the "enter as no submit button just submit" is new behavior for some or all browsers,
b) the "enter as just submit" vs "enter as first submit button" is just browser choice, no trends, just typical cross-browser unreliability, or
c) Everyone just keeps assuming that the "enter as first submit button" is the case because most of us only code if (situation1) else (assume not situation1) and none of us are really sure what the browser is doing.
I highly doubt it's that last one, but then again, I also highly doubt most of us know which browsers do which. I'd sure like it if there was a straight answer I could pass along.
Oh, and finally: While I know it would be far simpler to use buttons, and I am taking that under serious consideration, I would also like to consider other options, since really the only need for less submit buttons I have is for when users hit enter instead of one of the buttons.
Actually, let me get carried away one more second:
The only thing I really need to know is whether or not they hit enter FROM one of the text inputs. If I could pass that along to the server, I'd know if I should save or reload the form. But the problem is (or at least what I've had troubles with) is that when the user hits enter in an input, it seems like there isn't any more playtime with js to capture anything, and in some cases, it seems like the browser is triggering the onclick for whichever submit button and thus not really allowing me to know the real event that triggered that. I'll play around more with jquery, but has this behavior been observeed by anyone else?
My best advise would be to only have on submit button, and let that submit what ever is the most common usage of the form. Let the rest of the buttons just be normal buttons, which you can hook click events onto.
Just make sure you make it very clear which button will be "pressed" when the user hits enter. Let the submit button be the biggest one. If you have 3 buttons that are used equally as much, I would just drop having a submit button at all...
edit: I'm pretty sure most browsers will post all the data inside a form. If you want to do some checking on the data before posting you could add a listener for onsubmit
<form onsubmit="checkData(this);" ... >
Passing in this will let you check which form is actually being submitted:
function checkData(form) {
var formName = form.id;
//check all the data based on which form is being submitted
}
The HTML5 spec specifies synthetic click activation steps for implicit form submission:
A form element’s default button is the first Submit Button in tree order whose form owner is that form element.
If the user agent supports letting the user submit a form implicitly (for example, on some platforms hitting the "enter" key while a text field is focused implicitly submits the form), then doing so for a form whose default button has a defined activation behavior must cause the user agent to run synthetic click activation steps on that default button.