Re: Call statements


"Pop`" <nodoby@xxxxxxxxxxxxxxxxxxx> wrote in message
news:17MQi.5770$2o1.3334@xxxxxxxxxxx
Hi,

What is the "danger" in calling command buttons or setting their state =
true in VB6 code?

I have a fair amount of repetitive code, sometimes exactly what a command
button does and so far I've been creating separate subs to hold such code.
e.g. if I have a cmdDoIt_click() I'll create a 'Private Sub DoIt' and dump
the code into that for reuse instead of calling the button.

Instead of duplicating in a few instances, just for grins to see what
happens, I've been Call-ing command buttons or setting them to True. So
far
nothing untoward has happened, but, though I do NOT Plan to leave that
there, I did the test because I've received some pretty strong advice to
NOT
call buttons or set them to True; instead, create a separate sub for the
code. But there wasn't any reasoning behind the advice, that I can find
now,
at least.
Since nothing untoward has happened, then there must be some other,
possibly non-techical reason for not doing that. I'm hoping someone can
give me the reasoning behind it. It's a "head-around" thing<g>.


To add to the pile.

The only real "danger" in invoking controls in this manner, is if you use it
too much you can end up with "spaghetti events". A play on the term for
"spaghetti code" for when you abuse Gotos. A particular nasty Gotcha is
when, in your enthusiasm, you create a circular call - this button invokes
this listbox which invokes the original button. Usually such mistakes are
readily apparent - but on occasion can be hidden and intermittent and quite
fustrating.

Second, as noted by the others, it is always best to separate Presentation
from Function. It allows you more flexibility during development and
maintenance. So if you confine your calls to simplifying navigation or
defining "Form State" they can be useful. But like all techniques slightly
outside 'normal' procedures they can also be opportunities for confusion.

-ralph


.