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

Exactly. A single Split statement will do it all, so why the need for a whole class to do the job?

Lambert :-) 

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

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

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