John Colby
jwcolby at ColbyConsulting.com
Wed Feb 1 08:04:58 CST 2006
There are a LOT of classes that I "borrow" and never bother to figure out
how they work. I found zip/unzip stuff that is waaaaaaay over my head, or
at the very least I have no interest in figuring out. I don't care how
compression works, I just need to use it. The same with the registry stuff
you mention. I just use it.
Many of my classes are not that difficult to figure out what they are doing.
So if you folks want to know how it does the magic, by all means dig in.
But please don't let the fact that you don't understand it prevent you from
using it.
Sysvars are a HUGE help in controlling your application, learn the concept
and just start using them. Openargs can be a very valuable tool. Grab the
class(es) and start using them. If you like what I have done why start from
scratch?
John W. Colby
www.ColbyConsulting.com
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim DeMarco
Sent: Wednesday, February 01, 2006 8:38 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Same form, different actions
Excellent point John and one that I cannot agree with more. I don't know
how many times I've mentioned to other developers that all they have to do
is use whatever class we may be discussing and not worry about the behind
the scenes stuff. The reference I make the most is about a class I found on
the web that let me read/write registry values. I did not care how it got
or set values. I just needed to figure out what methods to use to access
those values. Much better than the APIs it wrapped (and that's really the
point of many class modules - to take complex processes and simplify them).
Jim DeMarco
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John Colby
Sent: Tuesday, January 31, 2006 9: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
****************************************************************************
*******
"This electronic message is intended to be for the use only of the named
recipient, and may contain information from Hudson Health Plan (HHP) that is
confidential or privileged. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution or use of the
contents of this message is strictly prohibited. If you have received this
message in error or are not the named recipient, please notify us
immediately, either by contacting the sender at the electronic mail address
noted above or calling HHP at (914) 631-1611. If you are not the intended
recipient, please do not forward this email to anyone, and delete and
destroy all copies of this message. Thank You".
****************************************************************************
*******
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com