Open new record with filled fields
- Thread starter setis
- Start date
Minty
AWF VIP
- Local time
- Today, 14:54
- Joined
- Jul 26, 2013
- Messages
- 10,695
You can refer to another forms controls from an open form using the syntax - Forms!YourFormName!YourControlName.
See here http://access.mvps.org/access/forms/frm0031.htm for more examples
So on Form B's load event you could use
Me.MemberID = Forms!FormA!MemberID
You would be best checking the Form A is open and has a current record before adopting that approach.
Or you could use the OpenArgs property to either do some looks ups, or open a recordset and set values from that.
Like most things in Access there are many ways to skin a cat.
See here http://access.mvps.org/access/forms/frm0031.htm for more examples
So on Form B's load event you could use
Me.MemberID = Forms!FormA!MemberID
You would be best checking the Form A is open and has a current record before adopting that approach.
Or you could use the OpenArgs property to either do some looks ups, or open a recordset and set values from that.
Like most things in Access there are many ways to skin a cat.
- Local time
- Today, 09:54
- Joined
- Feb 19, 2002
- Messages
- 48,017
Do not dirty the record before the user does.
If you want to open a form positioned to a specific record, use the Where argument of the OpenForm method.
If you want to populate a foreign key on a form that you pop up to add new records, use the form's BeforeInsert event. That way, the form will not be dirtied until the user actually types something himself. When you dirty the form all by yourself by putting your code into events that occur BEFORE the user enters data, the user will get confused if he attempts to close the form and your validation code kicks in and complains about missing or invalid values. From the user's perspective, all he did was to open a form. HE didn't change anything. Of course if you have no validation code, then the form closes and you just saved a blank record. Both are bad outcomes.
The other problem with using the load event or any event prior to BeforeInsert is that you can only enter a SINGLE record since the event fires only once. That may not be a problem if the user will only ever need to enter a single record, but you need to ensure that the user isn't able to scroll to a new empty record if you only want him to enter a single record.
If you want to open a form positioned to a specific record, use the Where argument of the OpenForm method.
If you want to populate a foreign key on a form that you pop up to add new records, use the form's BeforeInsert event. That way, the form will not be dirtied until the user actually types something himself. When you dirty the form all by yourself by putting your code into events that occur BEFORE the user enters data, the user will get confused if he attempts to close the form and your validation code kicks in and complains about missing or invalid values. From the user's perspective, all he did was to open a form. HE didn't change anything. Of course if you have no validation code, then the form closes and you just saved a blank record. Both are bad outcomes.
The other problem with using the load event or any event prior to BeforeInsert is that you can only enter a SINGLE record since the event fires only once. That may not be a problem if the user will only ever need to enter a single record, but you need to ensure that the user isn't able to scroll to a new empty record if you only want him to enter a single record.
Guys, I think that I need to take a step back and ask for some advice on how to set this up.
I have a list of members that will have claims. Under every claim can be one or more invoices.
What would be the right way to do this?
What I am thinking is either
*A subform on the claim form with the invoices details
or
*A button to launch an invoice form that is linked (without user input) to the claim where it's launched from
I have a list of members that will have claims. Under every claim can be one or more invoices.
What would be the right way to do this?
What I am thinking is either
*A subform on the claim form with the invoices details
or
*A button to launch an invoice form that is linked (without user input) to the claim where it's launched from