Chris:
In general your suggestion is an excellent technique and one to be valued.
My favorite way of doing any event is
try
call a sub to do the work
except
handle the exception
end try
That makes the sub aviailable independent of the event as you have suggested.
HOWEVER, what seems to be getting missed here is that I'm computing what
routine to call next and I'm trying to avoid a giant if statement.
I just run down a group of menu items calling them in order. Since the item
knows what it's click event is, i certainly don't want to duplicate that
information in code.
So I know that mi is the one to be called next. I've discovered that
mi.performclick will do the job SORT OF. (Who would have thought to look in
the P's for something related to click?-)))
The problem is that performclick is synchronis. Thus, at the end of the
string of say 10 menu items you have as a minimum 10 calls stacked up. In my
case it's more like 40. Do I really want the stack to get that high. That's
my objection to the performclick appropach. I don't know that a deep stack is
bad per se. But it sure is when you're trying to figure out what is
happening. And it sure doesn't mimic what things would look like if the user
just clicked on the menu items in turn, since the stack would return to
running the message loop after the completion of each event.
However, since it works I'm going to stick with performclick until someone
has a better suggestion.
--
Regards,
Al Christoph
Senior Consultant and Proprietor
Three Bears Software, LLC
just right software @ just right prices @3bears.biz
[quoted text, click to view] "Chris Dunaway" wrote:
> I would suggest taking the functionality out of the click event and
> placing it into a normal sub or function and then you can call it from
> either place.
>