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

jwcolby jwcolby at colbyconsulting.com
Tue Aug 7 09:02:00 CDT 2012


Because a class is more than a split.

The accepted form for passing multiple parameters like this is

Varname1=VarValue1;VarName2=VarValue2;

A split simply doesn't handle that.  A class can set up a collection to hold the variables, can 
split out the varname / varvalue pairs, use VarName as a key ad insert VarValue in the collection 
keyed on VarName, and then provide a method to pass in VarName and return VarValue.

A split ends up placing the values in an array which has no ability to get at the data by the name 
of the variable.  So you are doing things like

me.Caption = MyArray(9).  Hmmmm.... quite wonderful readability don't you agree?  Now insert a new 
something into the string of values in the wrong place and guess what, it isn't  MyArray(9) anymore 
it is  MyArray(10).  Ooops.  Why is my Caption displaying some piece of garbage data again?

My class uses

Me.Caption = mMyVars.mVarVal("Caption").  Add a new value into the string of parameters and guess 
what happens?  Yep, NOTHING.  It is still mMyVars.mVarVal("Caption").

Classes are not rocket science regardless of what you might think.  A class to do this then allows 
me to Instantiate the class in any form and voila, my VarValues are parsed and ready.  Simple, easy, 
reliable, consistent.

You can muck around with a split if you want, custom programming what each and every form will do 
with the split once the values are in the array, use numeric offsets into the array, puzzle through 
what MyVals(5) really is supposed to be.  I prefer a single class, written once, two lines of code 
in the form's class to dimension and instantiate and then available anywhere in the form's class to 
get at my values - BY VARIABLE NAME.

We are programmers.  Tag is a kluge.  Guess what, split (used like this) is also a kludge.  You are 
using a kludge and horrendous programming throughout your program so that you don't have to write a 
dead simple class?

Hmmmmmm........

John W. Colby
Colby Consulting

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

On 8/7/2012 8:35 AM, Heenan, Lambert wrote:
> 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
>



More information about the AccessD mailing list