[AccessD] Same form, different actions

John Colby jwcolby at ColbyConsulting.com
Mon Jan 30 11:29:53 CST 2006


John,

When you say "go there" what do you mean.  If you open a form modal, then
when you close the form you are right back in the calling form.  If you are
not opening it modal, you should STILL "go there" when you close the form
unless the user has clicked on or opened some other form in the meantime.
IOW, if the switchboard opens the form, then when the form closes, the
switchboard should still be there.  

If you want the form to do something and then OPEN another form, then pass
in the form name in the OpenArgs something like:

strOpenArgs="FrmToOpen=frmThatIWantOpened;"

Now somewhere in the form that you are opening with these openargs (perhaps
in the close event?) do:

Docmd.open acForm, lclsOpenArgs.OpenArg("FrmToOpen")

You do have to make sure that the instance of lclsOpenArgs hasn't been
destroyed already.  I am not sure at what instance in the closing process
that occurs so that part is up to you to figure out.

So.....

The demo has two levels of complexity.  The first (and most complex) is that
as you pass in openargs, it is possible to have the OpenArgs class set
properties of the form that is using this instance of the OpenArgs class.
That is handled automatically by clsOpenArgs.  Pass in OpenArgs with names
that match form properties and Voila, (assuming the properties are not
read-only) the properties are set.  That was demonstrated by the code in the
buttons on the demo form opening the SAME state form in two different modes,
plus setting the caption property of the state form.

The second level of complexity is just using an OpenArg somehow, using code
in the form to retrieve an OpenArg and use it.  That was demonstrated by
setting the label caption in code in the OnOpen event.

In either case, the first thing to get comfortable with is having a form
instantiate and initialize a class.  In the code behind form of the
frmState, we dimensioned a class variable in the header, then SET and
initialized that variable in OnOpen.

Private lclsOpenArgs As clsOpenArgs


Private Sub Form_Open(Cancel As Integer)
    Set lclsOpenArgs = New clsOpenArgs
    lclsOpenArgs.mInit Me, True

So the form now has a lclsOpenArgs instance that has parsed the OpenArgs
string passed in and is waiting for your command.

The next thing to become comfortable with is that you can now use the
Openargs:

	lblDemoArg.Caption = lclsOpenArgs.OpenArg("LblText")

In the OnOpen of the frmState, we initialized the class, and then used the
class to pull out an openarg called "LblText" and used the value returned by
the class to set the caption of a label - lblDemoArg.Caption.

Go back to the button code that OPENED frmState and notice that the string
with all the openargs contained an openarg with this "lblText" name (at the
very end):

    strOpenArgs =
"DataEntry=True;AllowEdits=True;AllowDeletions=False;Caption=My State Data
Entry Form;LblText=My Data Entry Label;"

ALL of the OpenArgs at the front of the string are for setting form
properties.  Their location in the string is irrelevant, it just happens
that is where I placed them.

IF you told frmStates to interpret the openargs as properties BY PASSING IN
True as the second argument of the init:

Private Sub Form_Open(Cancel As Integer)
    Set lclsOpenArgs = New clsOpenArgs
    lclsOpenArgs.mInit Me, True  <<<<HERE


Then any openargs with a name matching a form property will be used to set
that property.  That occurs in the private method of clsOpenArgs called
ApplyFrmProperties, which is called from the Init() method.  We passed in a
bunch of OpenArgs with names matching form properties:

    strOpenArgs =
"DataEntry=True;AllowEdits=True;AllowDeletions=False;Caption=My State Data
Entry Form;LblText=My Data Entry Label;"

DataEntry
AllowEdits
AllowDeletions
Caption

The reason that they are used for setting properties is that we passed in
the TRUE as the second param of the Init method, AND in that Init method we
called the following function:

Public Sub ApplyFrmProperties()
Dim lclsOpenArg As clsOpenArg
    On Error Resume Next
    For Each lclsOpenArg In mcolOpenArg
        mfrm.Properties(lclsOpenArg.pName) = lclsOpenArg.pVal
        lclsOpenArg.pIsPrp = (Err.Number = 0)
        Err.Clear
    Next lclsOpenArg
End Sub

Remember that we passed in a pointer to the form itself to the Init method,
so the class can manipulate the form if it wants to.

To really understand all this stuff, the best thing to do is simply set
break points in the command buttons that open the form.  Then step through
the code and watch it all unfold.  

I understand that the "set the form properties" thing gets in the way of
understanding the OpenArgs class but it is a great example of actually
automatically using openargs, with NO further code on your part (the user of
the class).  I wrote the class to do this "set the forms property" and all
you have to do is use it.  In the frmState, as you initialize clsOpenArgs,
say you are expecting some parameters to be sent in that will set form
properties.  The class takes care of the rest.  Back in your button that
opens the form, set openarg names that match the form properties that you
want to set, set the values that you want the properties set to, and hang on
to your hat.

John W. Colby
www.ColbyConsulting.com 


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Clark
Sent: Monday, January 30, 2006 11:11 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Same form, different actions

OK John, as usual, you are making my brain hurt ;) Seriously, I have
downloaded your demo, and I am looking through your code, in the clsOpenArgs
module. I think I actually understand some of it too. 

I guess the first thing that comes to mind is, does it work with
non-properties of forms? One of the things I want to do is tell the form
where to go on close...actually, when the exit button is clicked. If the
user goes there from the menu, it should return to the menu. However, if the
user goes there, from anther form, it should return to that form, and pass
the name with it.

I am going to try something, with your demo, to test this. Nope...just did
this real quick, and it didn't work. Actually the whole thing pretty much
quit working...what the heck did I do ;)




More information about the AccessD mailing list