Keeping OpenArgs around: Hidden textbox or Private global variable?

[Max Moor]

Hi All,

The title says it all. Somewhere, way back in time, I got in the habit
of setting a Private local variable in a form's module if I needed to keep a
value around from the OpenArgs. A couple of folks have recently suggested a
hidden textbox for this.

Is there an advantage to one over the other? Going even farther back
in time, I know global variables are generally frowned upon in structured
programming. I've always felt pretty safe with them in VBA for this sort of
thing, though.

Opinions?

Regards,
Max

 

[Allen Browne]

You can use a private local variable if you like.

A public variable won't be any good if you have several forms open at once,
or several instances of a form.

A hidden text box has some advantages over a variable. Particularly during
debugging, the variables lose their values when you 'reset.' And the text
box can be read from other contexts (e.g. query or macro) where the VBA
doesn't work.

But I'm not sure why you need any of these. OpenArgs won't disappear while
the form is open.

 

[Max Moor]

You can use a private local variable if you like.

A public variable won't be any good if you have several forms open at
once, or several instances of a form.

A hidden text box has some advantages over a variable. Particularly
during debugging, the variables lose their values when you 'reset.' And
the text box can be read from other contexts (e.g. query or macro) where
the VBA doesn't work.

But I'm not sure why you need any of these. OpenArgs won't disappear
while the form is open.

Hi Allen,

You make a good point about being able to read a text box after a code
reset. I hadn't considered that. The alternative, sprinkling Debug.Print
all over the place, can be an enourmous pain.

Also, you're right, of course, that the OpenArgs would stay in focus
as long as the form is open. I tend to shove multiple open arguments
together with 'Join' and then 'Split' them up in the Form_Open event. The
textbox or global question really refered to keeping any one of these many
arguments easily accessible without further Split calls. I should have
explained that more completely.

I have one more multi-forms question, but I'll put it in a separate
thread. Maybe the answer will help someone else.

As always, thanks for your help. Knowledgeable, willing mentors are
an invalueable thing.

Regards,
Max

 

[Allen Browne]

Yep: I'll admit to doing the same thing sometimes: Split() the values in
OpenArgs, and assign to a text box.

 

[David W. Fenton]

I'll admit to doing the same thing sometimes: Split() the values
in OpenArgs, and assign to a text box.

Any time I've contemplated parsing an opening argument, I've
concluded that it's a silly idea, and instead gone to a class module
as a data storage structure. That's much more extensible as
retrieving each value is independent of the others, whereas when
parsing an opening argument into multiple values, it's very
dependent on position.

 

[Allen Browne]

Have you tried named arguments, David?

As in:
strOpenArgs = "x=2;y=4;Something=99"

 

[David W. Fenton]

Have you tried named arguments, David?

As in:
strOpenArgs = "x=2;y=4;Something=99"

I find it much simpler to use something other than string parsing. A
class module is self-documenting, whereas packing all that stuff
into a single string and unpacking it is *not* going to be.