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

<<The tag property is to use as a variable.  The problem with the tag
property is that it is ONE 
variable. >>

<<OpenArgs exists for this purpose.  OpenArgs can contain any number of
arguments.>>

 Only if you delimit them...and how is that any different in that regard
then using tag property?

 It's not. Both require a delimiter and parsing to store anything other then
a single value.  You could use your class against the tag property just as
easily.

 I would argue against the tag though; the form will see this as a change
and want to save, which is not the case with OpenArgs.

Jim.

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

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