[AccessD] Same form, different actions

>>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.

Egads!  Where are the moderators?  This crass commercialism lowers the
tone of these exalted discussions!  Now, we were talking about natural
keys versus surrogates ....  ;o}

Charlotte Foust


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Colby
Sent: Tuesday, January 31, 2006 6:08 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [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 

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com