[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 


-----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 ;)

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