[AccessD] Open Multiple Instances of a Form and passing aparameter

Rocky Smolin rockysmolin at bchacc.com
Mon Aug 6 20:20:21 CDT 2012


I parse multiple arguments in a single string using the Split statement -
works a treat.

Rocky


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Monday, August 06, 2012 3:51 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Open Multiple Instances of a Form and passing
aparameter

The tag property is to use as a variable.  The problem with the tag property
is that it is ONE variable.  There is an entire function dedicated to
parsing the tag property when suddenly it starts holding dozens of values to
be passed in.

ICK.  I have used it.  Ick!

And what happens when you leave and the next programmer decides to "just use
the tag property" and over writes your tag property.  And suddenly stuff
breaks because after all, what is the tag property for if not for that
programmer to pass something in to the form.

It is a kluge.  Simpler is better until it isn't.

OpenArgs exists for this purpose.  OpenArgs can contain any number of
arguments.  I wrote a very simple class to parse the args and make them
available at a method call.  Instantiate the class, the class reads any
openargs and voila, 0 or a hundred or a thousand available and waiting for
your command.

But if you want to communicate in real time then make a public method of the
form class.  You can pass parameters in to the form, cause it to do stuff,
whatever.

There is nothing "superior" about the tag property, it is a kludge.  If you
are unable to program then "Tag away" I suppose.

Having said all of that, I actually use the tag to store the name of the
form contained in a subform control for JIT subforms.  I set it at design
time.  It allows me to remove the form name from the source property and get
it back from the tag property.

I don't like it, it makes me very nervous.  If any programmer following me
decides to use the tag of the subform control then my system breaks.  Ick.
But I did it.  So shoot me.

That doesn't mean I like the tag, I think it is a kludge and avoid it
wherever possible and have never needed it (once I learned to program) other
than that one place in my framework code.

BTW, IIRC you can create custom properties that are stored with the form?
Then the property is yours and yours alone.  And hidden, not easy to find if
you are trying to do security stuff.

But that is another discussion.

John W. Colby
Colby Consulting

Reality is what refuses to go away
when you do not believe in it

On 8/6/2012 5:40 PM, Stuart McLachlan wrote:
> As  Brad just commented in another thread:
>
> "> Why make things simple when you can make them complex and wonderful?"
>
> Perhaps John and Kenneth can explain what they think the Tag property is
for.
> ( or is it like GOTO - just an evil addition that must never be used 
> in any circumstances on principle).
>
> Also, why they think that 62 lines of code in two different location 
> is not *ugly*, when compared to a single line assignment of a value to 
> property whose purpose, according to the people who created the property,
is to store additional information about the form.
>
>

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



More information about the AccessD mailing list