Unanswered: Copy some fields from one form to another form
I am working on creating an Quipment Check-out database. What I am trying to do is if a person is checking out multiple items I want to click a button and OnClick I would like for it to populate with the previous forms user info and go to the Equipment entry. Can anyone help me? Basically I really just need to know how to copy One field entry from one form to the next.
What I am trying to do is if a person is checking out multiple items I want to click a button and OnClick I would like for it to populate with the previous forms user info and go to the Equipment entry.
Basically I really just need to know how to copy One field entry from one form to the next.
Copy from one Form to another, or from the last record?
Whatever fields you will want to auto-populate, save them to hidden fields when the record is updated. Then, if the user clicks the button, in the OnClick event you can update the current record fields from the hidden fields.
Well, I've been in the business (IT) for over 30 years, doing MS Access for over 13 years, and this is the first, ops, second time I've ever heard anything about hidden fields being bad practice. The first time was from a client (consulting firm) that I had to take to small claims court to get paid. They used it as a "design flaw" in their counter claim. I did not see it then, and still don't see it now.
When ever I use a hidden field, I always make it a light yellow color. That way, when I am looking at the report or form in design mode, I can instantly see why the form or report looks different than it does in Normal view. When I try to consider the alternative to using hidden controls, that's a little scary.
But, as anything that is not "straight forward", hidden controls need to be documented. Which is what I feel the light yellow color does.
I guess you're right. I like your approach to hidden fields - especially the highlighting. If I have to use them then I will definately adopt this method if identifying them.
The reason I've always seen them as a problem is always due to lack of documentation. Last month alone I inherited 2 access databases that use hidden fields to the max... and neither project has any documentation.
If you follow proper coding practice and document your work then there should be no problem in using them.
Apart from when your database gets so bloated that the multi-step hidden calculations start to slow everything down... (yes, another undocumented system I inherited).
Just learn to use them properly and there will be no problems!
I even go so far as to have a standing, hidden form in every app. "frmUtility" for me is always there with a place to store that customerID, customer name, orderID, from and to dates, or whatever. For example, you are working on a report and need to test it several times, and each time you have to open the form "frmGetDates" because the report uses the from and to dates off the GetDates form. I get tired re-entering those dates several times, so now anything I ask from a user, except actual data entry, gets written to my frmUtility, then used off there. This way, that report, or sometimes even other forms, will use frmUtility and the debuging/testing process just got a little easier.
I can understand your logic, and I guess it's jsut not my style to program like that. In the odd database I have created a non relational table in which I can store data like folderpaths and other bits and bobs - just giving it a simple code to remember.
But more often than not global variables and combined calculations do the trick.
I used to start my calculating everything in steps in hidden textboxes - then when that worked combined it all into one calculation (that was my debugging method) but I tend to just hop to the answer now - call it practice