Does anyone know of a browser plugin or application that will save form values then populate the same form when required?
Let me explain what I mean. I'm currently working on the registration page of a web application. As you can imagine it's quite long and I have to keep filling it out. I can fill it out reasonably quickly using values already entered by tabbing through the fields and hitting the down arrow. But, it's not fast enough! Ideally I'd like to enter the form values, then somehow save all the values under a name. E.g. "Valid registration". When I come back to the page I'd like to select my saved "Valid registration" form values and have the whole form populated automatically.
I've tried things like Web Developer but they are no good, they don't populate a form with valid data.
EDIT
I've also looked at autofill forms which is better, but still requires a lot of set up for a long form containing non standard fields.
hi this is Rahul Mandaliya.
some time ago i had faced that problem , and i got the answer , i used RoboFill software for store some data like user name , password and other .
i think you have to download this software.
i have put link for Download is : http://www.roboform.com/dist/RoboForm-Setup.exe
if did not get this software from above link , you have to manually go to www.roboform.com and Download this software.
A colleague pointed out that you can use Selenium IDE for this purpose. It's not really what it's intended for but it works like a charm.
Simply record yourself entering some details on the form, save it as something meaningful (e.g. "RegistrationValid" or "RegistrationInvalidPostcode") then you can run it whenever you like to auto populate the form. The only negative point is that the plugin is Firefox only.
You can download the plugin here: http://seleniumhq.org/download/
Related
Note: I've been debating on whether this should go into SuperUser or StackOverflow... I figure that SU is better, but please let me know is SO is a better fit for this question.
Alright so I'm kind of pulling my hair out over this. I have a database where I'm tracking questions, issues, change requests and more in regards to a piece of software. An important aspect here is to be able to add attachments (bug reports, screenshots, etc.). I read that generally it's better to create your own attachment handling system in Access because using the native attachment field can negatively impact performance, so I did just that. Plus, I prefer my implentation much more than the native implementation for the most part, so that's a bonus.
I created a report with different buttons to add, copy, and delete files with different buttons including the VBA code to handle everything. I then add the report as a subreport to the report or form in question. Example: Someone wants to ask a question and wants to attach a screenshot and an error log. The main form handles things like question and tags, and the subreport handles the attachments. To the right of every record (attachment) I have two buttons - one to open a dialog to copy the file somewhere locally, and the other to delete the attachment. Everything works fine, with one annoyance that should be minor but is really getting on my nerves: when the subreport is empty, it shows the two buttons in the otherwise empty details area. This is pretty confusing to me because I only have this empty line when the report isn't showing any records. As soon as I add an attachment, the new attachment/record uses that line (it's not as if the empty line is Access presenting a row for entering a new record).
In pictures (in German as I'm doing all of this in German):
When the attachments report has records, it looks like this:
Translations: Anhänge => Attachments; Dateiart => File type; Dateiname => File name; Datum => Date; Größe => Size; Kopieren nach... => Copy to...; Löschen => Delete; Anhang hinzufügen... => Add attachment
I've also blacked out some info for privacy reasons, but I hope everyone gets the idea.
When the subreport has no records, it looks like this:
I've scoured the web for solutions and I have yet to find anything that worked. I've tried setting the buttons to invisible in the "NoData" event, only to figure out that that event doesn't seem to fire when the form is a subform. I've tried adding code to the "Format" event of the details area, but that doesn't seem to fire either. Does anyone have any idea how I can solve this majorly annoying minor annoyance? Ideally I'd also remove the header lines and change the title as well but getting rid of the buttons would be a great start.
It looks like an empty record, so try using the OnCurrent event of the subform:
Me!DeleteButton.Visible = Not Me.NewRecord
I don't see the benefit of having hidden input? If you set the value of the hidden input why not just use that value at the point where you reference this hidden input?
There are reasons for this but I just don't know them.
They're used to pass data that will be needed when the form is submitted. One of the more common cases would be a form allowing users to edit some existing entry. You'll need to know which entry they're editing so that you can update the correct row in the database when they submit the form. The user doesn't need to edit (or even know) the ID of the entry though, so a hidden field works well here.
Other options
URL parameters:
This could also be done by building the parameters into the url that the form is being submitted to:
<form action="save.php?entry_id=1234">
but this means you have to handle building the URL properly and escaping the data yourself, and the length of URLs servers will accept is limited so it may not work for longer data. So generally using hidden form fields is the easier way to go.
Session variables: When the edit page loads you'd store the entry ID in a session variable, and then retrieve it on the page that saves the changes. That's a lot easier to mess up though; setting up and maintaining sessions may require adding code in several different places, and then their session could expire in between loading and saving, and you have to make sure it works if they have multiple windows or tabs open, and you have to make sure it doesn't do weird things when they hit back/forward. Because of all these potential pitfalls it isn't a great way to solve this problem--passing the id with the data being submitted is a lot more robust.
Cookies: In many languages/frameworks sessions are tracked using cookies, so they're basically the same solution. The pitfalls are the same as for session variables even when sessions are tracked by other methods though.
It sends additional information that the user doesn't know or isn't interested in (such as a security token) so that if the form is submitted twice, you can compare the tokens and reject/accept that submission.
Not using hidden inputs means the server needs to keep track of these values instead. This requires the server to keep state, which could otherwise be embedded into the request (form) itself. This may make the page RESTless (not RESTful), i.e. break the self-containedness of an HTTP request. If you did keep track of hidden values on the server, you would at least need to embed a unique token into each form to deal with several different unique submissions of the same form. The cleanest way to embed such a token is, drumroll, through a hidden input. :)
The Hidden Input field is not displayed on the page, so it does not allow visitors to add anything into it. The Hidden Input allows you, the webmaster, to add specific information to a form, to be passed through the form processor along with the data entered by the visitor.
For example, if you have several forms on different pages on your website, you could use a Hidden tag, in each form, that identifies which page the visitor was on when they filled out the form.
The hidden input is for when you want to send information back on a post without the user seeing the data as a UI element.
The web is stateless - ergo, when a POST comes in, you have only a couple pieces of information to determine what you need to do; Session, Url, some ServerVariables, and the Form data passed to you.
If a piece of data is transient that is not useful for putting in the session, sometimes it is prudent to put into a hidden field.
They can also be useful for storing data on the client side for rich internet applications (such as a product Id that is easily accessible to use in ajax calls).
because you have a php while loop with alot of different objects which you can't get the id's of later and you just save them by storing them in the hidden input... also i like them to be a security check to know my users aren't messing with my post variables through tamper data
If you build a tag system like the one here. You can set the values into a a hidden field.
Consider a form that's being displayed to edit a record in a database, one technique is to bake the id of that record in a hidden input and have it submitted back so the server can read it back.
It's also used frequently for security purposes (as genesis has said).
Another reason might be for javascript-oriented scenarios, perhaps for non standard controls such as treeviews, where the concept of a selected node cannot be represented as a normal input. Instead, JS can manipulate a hidden field and store the node's name/id in it, so that it can be read by the server.
It's just what it's name implies, a form input that is hidden from the user. It's a way of getting data to the server that the user doesn't need to see or control directly. This is especially useful for maintaining state.
I'm working on a project right now where a user creates several items that are represented as data objects in JavaScript and serialized when sent to the server. These data items are expressed one way when displayed to the user with HTML, another way as JavaScript, and a third way when sent to the server. A hidden input is the only way to accomplish this. (Okay, fine not actually the only way, but certainly the most reasonable way).
For example, if you have a form to edit an entity from you data model, you could use an hidden input to place the id of the entity you are updating, since you don't want to have this value put in the text input field to be posted back to the server. the hidden field will be posted to the server as if it were part of your form.
All answers explained why we using hidden inputs in form but here is the security concern.
Security concern
Using hidden inputs in forms can be tampered/changed by View source or using developer tools in any browser.
Solution
Use cryptography in your code/project to avoid changing values in
hidden input by attackers/hackers.
Generic Solution
If you want to store any data in hidden input first encrypt the data and store them in hidden input.
When form is submitted then decrypt them if values not change then save your data.
If changed then show some error or else.
Further reading
Cryptography
Wiki Cryptography
For framework Developers
Other framework developers can find cryptography in their framework.
Cryptography in Laravel(PHP)
Cryptography in .Net
Cryptography in Django
As name implies, Hidden fields are similar to other input fields except one difference i.e, hidden fields are not actually shown to the user and hence can not be edited by the user.Its value can only be set at the time of execution i.e. may be form submitting which posts the data to the server.
But the data set on the html page i.e. name/value can be seen in the html source of the page (view source of the page).
Client has asked me to create a self contained tool in MS Access, versions 2007 and 2016. It needs to be self contained because it will be copied to and from various laptops at various times. The tool may not create, delete, or modify any file except the accdb database itself. When the tool is in use, the user is unlikely to have network or internet access.
One of the criteria is the creation of new forms each time it is run. I realize that Access is meant to have all the forms and their controls already built before deployment, but client doesn't want that. I have solved that problem, creating x number of forms upon certain conditions, and creating 30-40 controls on each form based upon certain conditions, each with their own events, etc.
Now, how do I load his logo into a control on each form? Remember, the accdb must be self contained, so I can't count on the logo being in a certain directory or even on the machine in use, and I can't write it to the file system myself.
I can and have loaded the logo (jpeg) into one of my tables in an attachment field. It will be the only attachment in that field. It would be just as easy for it to be its own table, if that helps.
I can create attachment controls with VBA, but I don't know how to set the ControlSource to the FileData inside the attachment with VBA.
I also have had poor success attempting to embed the picture in an image control in a hidden form and setting the .picture property to the image name. It only seems to be working on my machine.
So, how do I display an attached jpeg on a newly created form?
Just asked and answered in SO access-vba. Here's one solution.
Saving Image as OLE Object, in Access
Many others on google and SO search
EDIT: You must read the whole question to see the author's answer
Answer:
So, what I ended up doing was following this
https://support.microsoft.com/en-us/kb/210486
I use the readBLOB function to read the file and save it into the
database. Then, when I run a report or open a form that has the
picture, onload, I use the WriteBlob function to write the file to a
temp folder and then use that path to populate an Image object.
I was wondering if there was any way of changing the background in access. The standard grey is ok but I would like to change it to an image that shows instructions or what was updated last. Also, if I can allow a user to change the background to an image of their choice that would be cool as well.
Can this be done
To be honest, I'm not sure if this is possible or not, but if it is, I'd advise you not to do it. Why?
Users will expect instructions under a help menu or on an intro
splash form
They will expect info. like what was updated last to appear in more
conventional places like the status bar
Allowing users to personalise your application with their photos can
make your application look pretty bad and increase load times.
Only advice though - good luck with it!
I have been able to allow users to change the background of the database. It works great and it works no matter what computer they log onto the database from. I did have a problem with remote users so I added a macro that allows them to disable the functionality. It works great. It was a little complicated to se up initially. Some of the modules below may have more stuff contained in them then what is needed for the purpose of this question. But here is what I did to make it work:
Add the Following modules to your database: modChangeMDI, SetBackgroundImage, and clsCommonDialog
Link to a zip file containing the code for the above modules: http://www.filedropper.com/changebackgroundimage
You can set the default location that a users sees when the search for file dialog pops up. This is located in the ThisFileToOpen function of the SetBackgroundImage module.
clsCommonDialog <-- Used to open the find file dialog box
modChangeMDI <--Used to change the background image
Create a table called $BackgroundLocation with the following fields. On my database this is contained in the backend database.
ID (AutoNumber, Primary Key)
UserID (Text, Required, 250 in length, don't allow zero lengths)
BackgroundLocation (Text, 255 in length, not required)
DisableBackground (boolean)
Create an AutoExec macro and add an action that runs the code SetTheBackgroundPictureOnStartup (1)
Create a BackgroundDisableEnable macro and add an action that runs the code DisableEnableBackground()
Create a BackgroundSet macro and add an action that runs the code SetTheBackgroundPictureOnStartup(2)
Then assign the BackgroundDisableEnable and the BackgroundSet macro to their own menu item.
When the database opens it will run the AutoExec by default.
You can use a start-up form as I suggested above. You can even base the start-up form on a comments table that can be edited by the users and will display the most recent and / or relevant information. The form can be displayed at start-up and then referred to at any time by the users.
In the past, I have included a ? button on forms that open such a form at the relevant page.
I don't see the benefit of having hidden input? If you set the value of the hidden input why not just use that value at the point where you reference this hidden input?
There are reasons for this but I just don't know them.
They're used to pass data that will be needed when the form is submitted. One of the more common cases would be a form allowing users to edit some existing entry. You'll need to know which entry they're editing so that you can update the correct row in the database when they submit the form. The user doesn't need to edit (or even know) the ID of the entry though, so a hidden field works well here.
Other options
URL parameters:
This could also be done by building the parameters into the url that the form is being submitted to:
<form action="save.php?entry_id=1234">
but this means you have to handle building the URL properly and escaping the data yourself, and the length of URLs servers will accept is limited so it may not work for longer data. So generally using hidden form fields is the easier way to go.
Session variables: When the edit page loads you'd store the entry ID in a session variable, and then retrieve it on the page that saves the changes. That's a lot easier to mess up though; setting up and maintaining sessions may require adding code in several different places, and then their session could expire in between loading and saving, and you have to make sure it works if they have multiple windows or tabs open, and you have to make sure it doesn't do weird things when they hit back/forward. Because of all these potential pitfalls it isn't a great way to solve this problem--passing the id with the data being submitted is a lot more robust.
Cookies: In many languages/frameworks sessions are tracked using cookies, so they're basically the same solution. The pitfalls are the same as for session variables even when sessions are tracked by other methods though.
It sends additional information that the user doesn't know or isn't interested in (such as a security token) so that if the form is submitted twice, you can compare the tokens and reject/accept that submission.
Not using hidden inputs means the server needs to keep track of these values instead. This requires the server to keep state, which could otherwise be embedded into the request (form) itself. This may make the page RESTless (not RESTful), i.e. break the self-containedness of an HTTP request. If you did keep track of hidden values on the server, you would at least need to embed a unique token into each form to deal with several different unique submissions of the same form. The cleanest way to embed such a token is, drumroll, through a hidden input. :)
The Hidden Input field is not displayed on the page, so it does not allow visitors to add anything into it. The Hidden Input allows you, the webmaster, to add specific information to a form, to be passed through the form processor along with the data entered by the visitor.
For example, if you have several forms on different pages on your website, you could use a Hidden tag, in each form, that identifies which page the visitor was on when they filled out the form.
The hidden input is for when you want to send information back on a post without the user seeing the data as a UI element.
The web is stateless - ergo, when a POST comes in, you have only a couple pieces of information to determine what you need to do; Session, Url, some ServerVariables, and the Form data passed to you.
If a piece of data is transient that is not useful for putting in the session, sometimes it is prudent to put into a hidden field.
They can also be useful for storing data on the client side for rich internet applications (such as a product Id that is easily accessible to use in ajax calls).
because you have a php while loop with alot of different objects which you can't get the id's of later and you just save them by storing them in the hidden input... also i like them to be a security check to know my users aren't messing with my post variables through tamper data
If you build a tag system like the one here. You can set the values into a a hidden field.
Consider a form that's being displayed to edit a record in a database, one technique is to bake the id of that record in a hidden input and have it submitted back so the server can read it back.
It's also used frequently for security purposes (as genesis has said).
Another reason might be for javascript-oriented scenarios, perhaps for non standard controls such as treeviews, where the concept of a selected node cannot be represented as a normal input. Instead, JS can manipulate a hidden field and store the node's name/id in it, so that it can be read by the server.
It's just what it's name implies, a form input that is hidden from the user. It's a way of getting data to the server that the user doesn't need to see or control directly. This is especially useful for maintaining state.
I'm working on a project right now where a user creates several items that are represented as data objects in JavaScript and serialized when sent to the server. These data items are expressed one way when displayed to the user with HTML, another way as JavaScript, and a third way when sent to the server. A hidden input is the only way to accomplish this. (Okay, fine not actually the only way, but certainly the most reasonable way).
For example, if you have a form to edit an entity from you data model, you could use an hidden input to place the id of the entity you are updating, since you don't want to have this value put in the text input field to be posted back to the server. the hidden field will be posted to the server as if it were part of your form.
All answers explained why we using hidden inputs in form but here is the security concern.
Security concern
Using hidden inputs in forms can be tampered/changed by View source or using developer tools in any browser.
Solution
Use cryptography in your code/project to avoid changing values in
hidden input by attackers/hackers.
Generic Solution
If you want to store any data in hidden input first encrypt the data and store them in hidden input.
When form is submitted then decrypt them if values not change then save your data.
If changed then show some error or else.
Further reading
Cryptography
Wiki Cryptography
For framework Developers
Other framework developers can find cryptography in their framework.
Cryptography in Laravel(PHP)
Cryptography in .Net
Cryptography in Django
As name implies, Hidden fields are similar to other input fields except one difference i.e, hidden fields are not actually shown to the user and hence can not be edited by the user.Its value can only be set at the time of execution i.e. may be form submitting which posts the data to the server.
But the data set on the html page i.e. name/value can be seen in the html source of the page (view source of the page).