Could someone break down openargs for me please? I am new to access have taken several access classes I even have the access 2003 bible, but this concept is very new to me. I need the main form to link to a secondary form using the same table. I need the employee information to match to it is still accessing the same info from the main form. I need it broken down pretty basic and where is this information added into access? I am planning on a button/macro to access the secondary form. I need the secondary form as I have ran out of room on the main form.
Which would open Form B, but passing the value of txtSomeIDField from Form A to it.
Then on Form B's Open event, I could do something like ...
Code:
If Not IsNull(Me.OpenArgs) Then
Dim lSomeID As Long
Dim RS As DAO.Recordset
lSomeID = Me.OpenArgs
Set RS = Me.RecordsetClone
RS.FindFirst "[SomeIDField] = " & lSomeID
If Not RS.NoMatch Then
Me.Bookmark = RS.Bookmark
End If
End If
This should open the form to the correct record, but then again, this is all air code.
You can pass multiple arguments and use something like the Instr function to parse out the arguments, or, set up a global array variable to handle all of this.
i have an open argument framework already in place between two existing 'normal' forms (i.e., "form view") of my database (frmItems to open specific record in frmSuppliers: which works).
i now wish to utilise that framework to open frmSuppliers from frmOrders, which is a continuous form. using the same code as with frmItems,(supplied below) frmOrders produces this effect:
when i click on my command button on frmOrders ("Contact Supplier" in the image below), the frmSuppliers opens to a specific record, however, it's the specific record for the FIRST displayed in the continuous form, NOT the 'current', or 'active', or 'in focus' record on that continuous form.
am i using the wrong approach for continuous forms, or do i need a small tweak to get around the 'continuous' bit (i cannot make this subform a datasheet view, due to other command buttons etc on it)?
here is the code i am using on my forms to send the OpenArg (pertinent code in red);
Code:
Private Sub cmdOpenSupplierForm_Click()
On Error GoTo Err_cmdOpenSupplierForm_Click
[COLOR=Red] Dim stDocName As String
Dim varOpenArg As Variant
[/COLOR] [COLOR=Red] stDocName = "frmSuppliers"
varOpenArg = Me.txtSupplierID
DoCmd.OpenForm stDocName, , , , , acDialog, varOpenArg
[/COLOR]
Exit_cmdOpenSupplierForm_Click:
Exit Sub
Err_cmdOpenSupplierForm_Click:
' "modFeatures" class module required for strings presented below
Msg = "Error # " & Str(Err.Number) & Chr(13) & " (" & Err.Description & ")"
Msg = Msg & Chr(13) & "in Form_frmReceivables | cmdOpenSupplierForm_Click"
MsgBox Msg, vbOKOnly, fstrDBname & ": Error", Err.HelpFile, Err.HelpContext
Resume Exit_cmdOpenSupplierForm_Click
End Sub
and the code on my frmSuppliers to accept the OpenArgs:
Code:
Private Sub Form_Open(Cancel As Integer)
On Error GoTo Err_Form_Open
[COLOR=Red] Dim intSupplierID As Integer
If Not IsNull(Me.OpenArgs) Then
[/COLOR] [COLOR=Red] intSupplierID = Int(Me.OpenArgs)
Me.lstSuppliers.Value = intSupplierID
lstSuppliers_AfterUpdate
End If
[/COLOR]
Exit_Form_Open:
Exit Sub
Err_Form_Open:
Msg = "Error # " & Str(Err.Number) & Chr(13) & Chr(13) & " (" & Err.Description & ")"
Msg = Msg & Chr(13) & Chr(13) & "in Form_frmSuppliers | Form_Open"
MsgBox Msg, vbMsgBoxHelpButton, fstrDBname & ": Error", Err.HelpFile, Err.HelpContext
Resume Exit_Form_Open
End Sub
and for those interested, here's a screenshot of the form. the 'supplier' textbox with supplier name is only there during development stage so i can see whether the command button (really a label with an 'on click' event) is pulling the correct record. it's only ever pulling up the record for "Astral Scientific" (via the SupplierID, not visible on the form), whether i need it to find "Lomb Scientific", "Lomb", or "Astral"...
has anyone had OpenArgs work for continuous forms? Can you provide assistance?
Access Help does not mention limitations on OpenArgs re continuous forms, so i guess it must be possible, but i've not found a solution via google (except to use the where argument of the openform command, but i prefer to use openargs.... do i need to be brave and switch it to 'where'?)
You can pass multiple arguments and use something like the Instr function to parse out the arguments, or, set up a global array variable to handle all of this.
i have used this in the past very successfully - very handy thing to be able to do. i used it when i was sending different recordsets to the same report, and needed to change the title and other bits depending on what the data was. however, i used the split() command thus:
Code:
If Not IsNull(Me.OpenArgs) Then
Args = Split(Me.OpenArgs, ";")
Me.RecordSource = Args(0)
Me.Auto_Title0.Caption = Args(1)
Me.lblSubline.Caption = Args(2)
End If
where the openarg itself was like:
Code:
strOpenArg = "qryGENTprimariesRLB_GENTresult;Primary GENT Isolates;RLB positive for GENT (pinkies only)"
You are setting the value of the listbox control where you should be using the same style of a find first code you would get if you used the wizard to add a combo to search for a record.
I'm on the bus heading home from work so it is hard to type more about it.
hi jadefury, like explained previously, openargs is a way to send information from one form to another (or a report etc), so, rather than 'just' opening the second form, we open it at a specific point (or do something else specific to that case, as i described in my earlier post with report and titles etc).
if we use the example of an ordering database: you have a form for your items, and a form for your suppliers. now, you wouldn't put all of your supplier information into your items form BUT sometimes you want to know something about the supplier when you're looking at an item they supply.
so in your items form, you have a button which says something like "suppliers..." and when you click on it, you can send SupplierID from your items form recordset, and match it with the same SupplierID on your supplier form. this way, you can save space on the items form but still access the supplier information on demand.
i've posted code in my previous post which works on regular forms (this is straight out of my working database, so i can assure you it works!) - however, the way i go to my specific record on my supplier form is via a listbox, which already has 'find the record' code attached to it, so i just piggy back that code here instead of writing it all out again.
the 'find the specific record' code is just the code you get from the wizard when you put a list or combo box on it, and is under the 'after update' event of the control:
Code:
' Find the record that matches the control.
Dim rs As Object
Set rs = Me.Recordset.Clone
rs.FindFirst "[SupplierID] = " & Str(Nz(Me![lstSuppliers], 0))
If Not rs.EOF Then Me.Bookmark = rs.Bookmark
the "if not isnull" part in the openarg of the receiving form is essential in case you opened the form on its own from the switchboard, and don't want to go to a specific record.
edit: here is a picture of my suppliers form, just so you know what i mean when i say i use a listbox to find the right record... see the listbox on the left? whenever a user clicks on there, the form goes to that record. the listbox is unbound, FYI.
You are setting the value of the listbox control where you should be using the same style of a find first code you would get if you used the wizard to add a combo to search for a record.
I'm on the bus heading home from work so it is hard to type more about it.
hi bob, thanks for the reply. i just realised that's what it looks like, but i have an afterupdate even which does trigger a 'find bookmark'... and it works when receiving an openarg from a different form (which is not a continuous form).
incidentally, it does WORK when receiving an openarg from the continuous form, it's just that the continuous form is SENDING the wrong ID in the openarg. it's sending the first record off the rank, rather than the 'current' record, i don't know how access decides which is the current record.
i have another button in the continuous form which works for just the current record, and there's nothing 'funny' about that one.. it sends "today's" date to a date field (shown as "rec'd date" on the form picture in my previous post) in the record, and when pressed, it sends it ONLY to the record it's currently on. here's the code for that, if iti helps:
after some fiddling, i have discovered that the openargs method DOES work on continuous forms, so long as the FOCUS can be brought to the correct record.
with my fancy label 'button', this was not bringing focus to the record. when i changed this label to a real button control it triggered focus to the current record and opened the supplier form at the correct record.
jadefury, one important distinction between openargs (to find a record and go to it) and simply using the 'where' clause (to filter the form), is that openargs allows you to then use the form to look at other records, while the 'where' clause filters out all the other records and they can't be viewed (only the one record that the 'where' clause restricts to).
so in forms like mine, where i use a listbox to find records in the recordset of the form - and for people lazy like me, where i refuse to make two or three semi-identical forms (one for edititng, one for viewing, one for...?) - having the functionality of the whole form still accessible to me/user is a big plus that openargs allows. AND i like the versatility ('where' will only filter the record set, but openargs can be used for anything under the sun in the receiving form or report)
and for people lazy like me, where i refuse to make two or three semi-identical forms (one for edititng, one for viewing, one for...?) - having the functionality of the whole form still accessible to me/user is a big plus that openargs allows. AND i like the versatility ('where' will only filter the record set, but openargs can be used for anything under the sun in the receiving form or report)
with my fancy label 'button', this was not bringing focus to the record. when i changed this label to a real button control it triggered focus to the current record and opened the supplier form at the correct record.
yes i thought about that, i may change it when i have the time. alternatively, the button looks like a button to be pressed (to novice users). a label just look pretty.
i prefer pretty, but don't always have time!
ta to you other guys who agree with having just one form!
