[AccessD] Same form, different actions

Everyone,

I want to point out that the entire point of classes (objects) is that you
can just use them, you don't have to understand them.  I know that some
people want to learn how it works as well, but in the end, just start using
it, THEN worry about digging in and seeing how it is programmed.

Everything you use in Access as an object, and we don't have a clue how it
works inside.  Combos, text boxes, forms etc, all are objects that have
methods and properties.  You just use them, but don't know, nor care how it
all happens inside the object.  

These classes I put out there, the SysVars classes, the openargs classes,
the date picker class etc. all are things that you can just use yourself,
even if you NEVER figure out how it works inside.

And I might add <shameless plug>, I am a consultant.  If you have a project
that needs this level of expertise, you can hire me to do it.

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 1:24 PM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Same form, different actions

Man, I wish I got this just half as much as you do! This is going to take me
some time to digest, but I think it is exactly what I need.
Thanks for the help!

John W. Clark


>>> jwcolby at colbyconsulting.com 1/30/2006 12:29:53 PM >>>
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