I have an input form in which users submit multiple types of information to the database.
Is there any way I could provide an example input of what should go in each field, upon the form loading?
Some fields I'd expect a small paragraph of text, others are dropdowns. The dropdown fields I wouldn't need to put an example of course, just the string text fields. If I try and include an example in the Default value for example, it would save the default value, which I wouldn't want.
Any help is greatly appreciated - It's worth noting I'm quite new to Access & coding in general.
I agree you probably don't want to use default values, or actually enter dummy data into the actual controls for the reason you mention: saving dummy values to the table.
A few possibilities:
Use a custom tooltip. You can do this by editing a control's "controltip text" property. Keep in mind that tooltips are only visible to the user when they hover the cursor over the specific control.
Add a label below the input control that describes the information that should be put in the control. This would always be visible, but can quickly cause your form to be cluttered and difficult to read.
I should say though, that you want to attempt to make your forms as intuitive as possible. For example, if you expect a paragraph of text, make the textbox much larger than a control only expecting a 6 character string. The more you are concerned with UX (user experience), the greater the chance that users will pick up on expectations using subtle design hints. I highly recommend researching the topic if you are concerned that your users will be unable to decipher the purpose of your form/controls. Be sure to check out the UX page on SE.
Furthermore, you can utilize a control's "AfterUpdate" event to validate the input placed in the control as soon as the user moves away from it. For example, you could test if the input IsNumeric() to validate that numbers were entered instead of text. If text is found, you can use a message box to alert the user, and move the cursor back to the control that is invalid.
Of course, that's the customized approach to just using the control's validation rules. The only issue I have had with the standard validation rules is user exhaustion. It can be irritating for a user to deal with validation messages when they are already aware that a typo was made. With an unbound entry form that requires a save button, I usually batch all control validation into the save procedure. This allows the user free reign to skip controls in the tab order without being blocked by constant validation exceptions.
Related
This is my first post, so be gentle :)
I am developing an ASP.NET web user control that will allow a user to type in some free text in a multi-line textbox and the application will asynchronously stem the words and use Ajax to submit them to a web service for further processing. The web service processes the words and returns a number of choices (id, title) back to the user.
Naturally, I used the AutoCompleteExtender control which basically covered all my needs but one. Once a user makes a selection from the popup window, I need to keep track of the selected item, BUT, I do NOT wish for my typed-in text to disappear or be replaced by the item selected by the user (as what AutoCompleteExtender seems to do by default).
Does this make any sense? I want the "OnClientItemSelected" event to fire (so as to know which item was selected by the user), BUT, I don't want to have to "lose" the content typed-in by the user.
Can anyone help?
Thank you for your time.
Use the DelimiterCharacters="" "" property in your extender mark-up.
Basically, what seems to happen, is that the extender will recognise a new "suggestion" after it sees your specified delimiting character. In this case, " " (a normal space.)
You can also use any other delimiter, I.e ",".
if we use setEnabled(false) say on text input type it disables and not take part in form validation so how can i enoforce this right before onsubmit
As a general rule browsers do not submit the value of disabled fields at all. (As mandated by the HTML standard)
It's important to see that because of the browser sending no data, the problem is framework-neutral. The solution is also independent of your framework:
Double-fielding: each text field that you intend to disable should have a "shadow" hidden field where its value is copied.
In the Javascript function that does the submitting you can re-enable the fields for the time of submit only. I haven't tried this option yet so I'm not sure if this is a good idea or indeed if it works (it should though).
A separate, Wicket-specific issue is that even if the browser submits the values, any Wicket component which has setEnabled(false) called will refuse to process them. So you'll have to extend double-fielding into your Wicket component structure as well, which won't look very nice.
So it's doable but you should know that users will not expect disabled fields to be submitted and you're likely to cause confusion by changing the standard behaviour of form inputs. You might want to think about redesigning your UI as an alternative option.
If the component is disabled it won't have any input to be validated. I'll assume from now on that you want to execute a FormValidator which involves some other components' user input and this disabled TextField's model object.
Unless you return the disabled TextField in FormValidator.getDependentFormComponents(), the FormValidator will continue to execute. Take into account that FormComponent.getConvertedInput() won't return anything, because there's no input. You can get the Modelobject instead by using FormComponent.getValue().
Basically, what pros/cons are there to using multiple forms in the same web page vs one form with multiple submit buttons? Any difference at?
Ah? Multiple submit buttons on a single form will all submit the entire form when pressed... there's really no advantage to having multiples, unless you're overriding how the submit process works so each button only submits it's own area. In this case they'd probably not even by submit buttons, but just buttons with sum JS code to handle submission.
Multiple forms are discrete spaces of data collection, each can have it's own submit button... but only one of them can be sent at a time (and depending on the browser you may loose what's in the other forms).
Neither approach is particularly good from a user interface perspective since it'll be confusing.
The real question is, what are you trying to do that prompts you to ask this?
The two behave differently and there are good reasons to choose one over the other.
Multiple Forms on a page allow you to send data to two different locations. A common example is to have an input form as the main focus of a page going to one location, and a search form that appears as part of the generic header/footer. These both go to separate locations and submit only the HTML form elements within their appropriate <form/>
Multiple submit buttons offer you the ability to give different purpose to a submitted set of form elements. E.g. One form may have a bunch of submit buttons all with name attributes, meaning you can add conditional logic on the server side to say: "Continue", go " Back" or even "Save for later". All reference only the form elements within it's parent tag.
Two side notes are: 1) You can't nest forms. 2) JavaScript can change this default behaviour if you wanted it to. :)
Edit: with reference to a comment you made, if you wanted to do without JavaScript (a wise choice while it's not needed), you could do some careful thinking and keep POSTing the form to itself. Each time checking which form button has been clicked (top tip, give them all the same name and you can just switch case through it) and do whatever you need to do, including performing validation. E.g: When they hit "add media", you'd save the media uploaded and return a reference of it to the screen as a hidden input. The user can then continue to add things to the other boxes and when complete, hit your save button, at which point you do all the main saving work and make sure you tie the uploaded file to it as well.
You effectively keep adding stuff to their screen until they hit the save and then you perform a save method and redirect to a thank you page (or whatever logic suits your scenario). :)
All fields in a form are sent when one of their submit button is clicked. It's for you to see if you need all fields or not.
my company's software product has a feature that allows users to generate forms from Word templates. The program auto fills some fields from the SQL database and the user can fill in other data that they desire. So we have a .dotx template that holds the design of the form, and then the user gets the .docx file to fill out when they call it from our program.
The problem we're having is that some of our users have been finding that the forms take an exceptionally long time to open up and then, once open, are so slow to respond (scroll around, etc) that they're unusable. So in my investigations so far, I've found out that the problem systems are one with lower powered CPUs (unfortunately it happens for systems above our system requirements) and the Word forms that cause the problems are ones with large amount of ActiveX style checkboxes on them. I verified that reducing the ActiveX checkboxes fixes the form loading problems.
So I have the following questions about solutions (we're using Word 2007):
1) Is there any way to configure Word, or some other settings, so that there won't be such a strain opening a Word form with lots of ActiveX checkboxes? Any way of speeding up Word's opening?
2) Using Legacy style checkboxes instead of the ActiveX ones makes the forms load fine, but it looks like the user has to double-click the checkbox and change Default Value->Checked. Is there a way to configure it so that they can simply click on the checkbox to tick it? "Legacy Forms" checkbox as a name kind of worries me (Legacy…), does that mean a future version of word at some point wouldn't load the checkboxes because they're "legacy"?
3) Yes, it became clear to me after a little bit of research into solutions that Word is not the tool for the job for forms like I'm describing. InfoPath seems to be exactly what we should have been using all along but unfortunately I wasn't involved in the decision making or development of these forms, just tasked with coming up with a solution.
I'd appreciate answers to any of these, or if anyone has any other ideas for solutions to this problem.
Thanks
I'm about 3 years too late, but if you want a legacy checkbox to act like a checkbox, you have to restrict editing on the document or section. (You can lock just a section, if you want.) Locking--on Word 2010 it's called "Restrict editing"--is an option under either the Developer tab or the Review tab.
If you restrict editing in this way, the user cannot edit the text but can fill in the form field, so if the form field is a checkbox, the user can click the checkbox on or off; if the form field is a text box, the user can fill the text box.
If you choose to lock off just a section, you'll probably want to use continuous section breaks (Page Layout > Breaks > Continuous) and specify which section. (In the space where you choose form editing as your kind of restriction, there's a small link that lets you specify which section or sections are locked.)
I am making a custom textbox control and am thinking about adding keybindings in the constructor that execute commands to open and save files. I am also thinking about handling the find and replace dialog from within my textbox control.
Is there a reason I shouldn't do this?
--Edit--
I am planning on only using this control in my current application. One of the reasons I am thinking of doing this is to avoid binding to the textbox's Text property, since this binding seems like it would be just as inefficient as updating a string on the textbox's textchanged event.
Well, flexibility comes to mind. Consider the following scenarios, which would be impossible (or at least difficult) in your control:
You want to handle multiple or different methods of opening a file, but it depends on your application.
You want to use your textbox but limit the functionality -- e.g., Find/Replace is not allowed.
You want to change the behavior of any of that in one application but not the other. For example, in app A you want to tack on an extra slash to the end of the text, but in app B you want to add a custom folder name.
In general, I would consider something more generic. Something like a textbox has a specific purpose; enhancing that purpose is fine, but you're going beyond that. You're taking logic that rightly belongs to the app and putting it on a specific control. That limits what you can do with the control across multiple apps.
Of course, if you're writing a control specifically for one and only one app, you don't need to worry about these things. But I would still consider it a bad practice, myself.