Previously, I have seen web forms that are multiple pages long, but on each page, if the inputted information is invalid, it will cause an error and make the user fix their input.
However, I can't seem to find anything to show me how to do this. My form is 2 pages, with a Continue button at the bottom of the first and a Submit button at the bottom of the second. However, all possible errors generated will be on the first page, so I want it to show them if the user hits Continue when he has inputted errors.
Right now, the form is only processed after the user hits Submit and all the data is posted to the backend, which means it then has to go back to the first page to show the errors.
You could try to check the information every time the user continues to the next input control, and tell him that there's something wrong if he enters any nonsense.
How to achieve this depends on how your form looks:
Does it just contain and something like that or radio buttons and other "special elements"?
For you could check at the FocusLost event, but I don't exactly remember its syntax.
Related
I'm a beginner in web dev but I'm really good on the software end. I have some HTML to display text and a YoutTube Video on a webpage. But before this, the user must be prompted to input a value in a text box.
What I wanted is for the user to see a box with a submit button. The box will only accept one of 7000 unique entries. Once the user inputs one of the 7000 entires, only then the HTML/YouTube Video must be displayed. Otherwise the page can display a message saying: Retry, entry not recognized.
The webpage is running Wordpress with Motopress. Is there anyway I can do this with Custom fields to store the values or whichever way is easy and quick?
I have created a help index on a tab control with 60 pages. Each page contains helpful information to the question that corresponds to the page. The questions that are being answered are on a different form from the tab control form. I have created a button next to each question so that the user can access the help form if they need background and instructions for completing each question. I am trying to write code that will open the form and go to the correct page based on the button that was clicked. So the button for question one would open the form and go to page 1. I have tried a few different things, and can't get it to recognize the page. Below is the code that I currently have in place:
DoCmd.OpenForm "frmTestingHelp"
Forms!frmTestingHelp.SetFocus
DoCmd.GotoPage (0)
The form opens, but cannot find the page and results in an error. I started without the second line, but added it to see if the issue was that it wasn't looking for the object in the right place.
Thanks in advance!
DoCmd.GotoPage is used only with page breaks, which hardly anybody uses. See e.g. here: http://www.functionx.com/vbaccess/Lesson13.htm and scroll down to "Using the Pages of a Form".
To select the second page of the tab control TabControl on your form:
Forms!frmTestingHelp!TabControl.Pages(1).SetFocus
or preferably, if you don't want to set the focus,
Forms!frmTestingHelp!TabControl.Value = 1
assuming you haven't changed the default PageIndex values 0,1,...
I'm writing a form and have a multi-select with certain responses (age range); for ranges below a specified value, we redirect users to a page with information on why we don't accept that range currently, etc.
The problem is that the form navigation appears on this page, so they can hit Back (no problem) and Submit (problem).
We don't want users submitting if they wind up on this error-catch page, but I haven't seen any way of disabling or hiding the submit button.
Even checking Google scripts, it doesn't seem like this is possible? Does anyone know if there's a way to do this?
The SUBMIT button either appears on the last page, or on pages where the setting is set to: Submit Form
You probably have the error page as the last page, and the next to last page set to Submit Form.
There is no way to disable the submit button. Put the error page BEFORE the last page. Make the page that is right before the error page skip over the error page and navigate to the last page (Submit Page). On the last page have only one question like: Are you done? "Yes" "No" This way, the user will never see the submit button until they get to that last page. On the Error page, set the page navigation to go to something like back to the first page. If the user clicks BACK on the SUBMIT page, it will skip over the error page and go to the page before it. Of course, the user could navigate back, and change the answer, and get to the SUBMIT page. But then they'd be lying about their age.
You can disable the Google form by accessing Responses tab and unchecking the option Acception responses.
you can use this restrict Data in Google Sheets with Data Validationso it will show a pop up message based on DATA
https://www.howtogeek.com/428919/how-to-restrict-data-input-in-google-sheets-with-data-validation/
I was wondering about the best way to implement a "Confirm Page" upon form submission. I know that it's best for the script that a form POSTs to be implemented by handling the POST data and then redirecting to another page, so the user isn't directly viewing the page that was POSTed to.
My question is about the best way to implement a "Confirm before data save" page. Do I
Have my form POST to a script, which marshals the data, puts in a GET, and redirects to the confirm page, which unmarshals and displays the data in another form, where the user can then either confirm (which causes another POST to a script that actually saves the data) or deny (which causes the user to be redirected back to the original form, with their input added)?
Have my form POST directly to the confirm page, which is displayed to the user and then, like #1, gives the user the option to confirm or deny?
Have my form GET the confirm page, which then does the expected behavior?
I feel like there is a common-sense answer to this question that I am just not getting.
If you must do this (I'd only do it for stuff involving monetary transactions or the like, personally), I'd recommend 2 resources/URIs, both of which follow the Post-Redirect-Get pattern: POST the initial cart checkout, create a "pending order" state (or similar), redirect to the page for that state. The user can then POST from that page to the next URI to create a "confirmed order" (or similar), which redirects to a receipt page or whatever.
What I've done in the past is have one page that has a 'View' area with labels and then a 'Edit' area with textboxes/dropdowns/etc. You can make them DIVs or TABLES depending on your preference.
User comes to page and gets the edit view so they can use the textboxes. Save/Submit button at the bottom.
Clicking on Save/Submit does a postback, populates the labels with the data they entered, and allows them to view/verify what they entered. Continue and Edit buttons at the bottom.
Edit is a postback and goes back to the edit view.
Continue does the actual save and redirection to a new page that displays the confirmation.
Optionally you could save the data on the confirmation page instead of the first page depending on your preference again.
Actually, you could do this ahead of the submit. In the form submit (wherever that is) add an onlick that fires a modal window with a confirmation button. My personal favorite in this situation is to use a Jquery UI Modal Confirmation dialog.
I personally fire this via means of a Jquery .click statement in the page.
So, the document won't submit until the onclick dependency has been completed and changed to "true" which the example does automatically with the included "ok" button.
I believe that this will gracefully fallback to just not require the confirmation if Javascript is turned off, which itself is becoming more and more of an "edge" case. In fact, some of my most staunch corporate clients are starting to accept limitations such as this case when Javascript is turned off....and they're way more picky that most any of us ever will be.
Then, you're free to submit to any page you'd like. Personally, I've switched all of my forms over to a Jquery .ajax submit, but that's just me. You can do it however you like.
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.