Calling "computed" click events programmatically

[Al Christoph]

I have a program that mixes wizard like behavior with random access to the
various dialogs in the wizard. I do this by having each step map to a
toolstripmenuitem. Users can randomly choose the menu item and get the
corresponding dialog. Alternatively at the completion of each dialog, I can
"click" on the menu item and cause the appropriate dialog to come up. It
works rather well but the way I've done it is a horrible kludge. I even left
things out the first time:-(((

I put click in quotes above because I have yet to come up with an elegant
way to do this as noted. What I want is to be able to compute the name of the
next menu item to call and cause its click code to execute, preferably in a
way that exactly mimics the user action.

QUESTION: What is the best approach to do this so that I don't stack up a
whole pile of nested calls most of which are right at the end of the previous
call?

QUESTION: In other environments i'd post/send (I always have to look up
which does it asynchronously) a WM_Click message to the control. Is that the
right thing to do here? If so what is the .net way to do it?

I've tried using reflection to get the eventinfo etc and invoke the event.
That fails because at some point in the process reflection returns NOTHING.
(Code upon request.) QUESION: If I had been able to get reflection to work
what are the odds I would have ended up with that undesired stack of calls.

BOTTOM LINE QUESTIONS: If variable mi contains a toolstripmenuitem whose
click event you wish to cause / invoke, preferablly asynchronously (i.e
through the genration of some kind of message processed by the message loop)
what is the best way to do it? If my fetish for asynchronicity is
inappropriate, then why? What is the synchronous way to do this.
--
Regards,
Al Christoph
Senior Consultant and Proprietor
Three Bears Software, LLC
just right software @ just right prices @3bears.biz

[Cor Ligthert]

Al,

When I understand you well, than when if I have a problem like yours try
forever to seperate data and UI.

Probably will I for your problem create a class that can holds as objects
for every menuItem the information. Those Items will I than store probably
in a nested arraylist.

Than I can do what I want by just accessing the arraylist depending on
stored previous done information.

As last I can serialize and store it, save it and set it next time for the
user back from where he/she ended the last time.

Just my thought,

Cor

[Al Christoph]

Thanks for responding. You shared an interesting idea. The issue is NOT
computing what to do next (for which you offer one possible solution or way
of making it more efficient.) The program quickly figures out that object mi
(a toolstripmenuitem) is the thing it wants to use.

The question is what is the best way to do "mi.click" in the absense of a
click method on toolstripmenuitems. (Something that was overlooked in the
..net design, IMHO. What is needed is mi.click(synchronous as boolean) If
synchronous is true the click event is called directly. If synchronous is
false, a message is posted (event raised?????) so that the click event is
called by the message loop.

I hope that my little wish list item clarifies what I want to do.

--
Regards,
Al Christoph
Senior Consultant and Proprietor
Three Bears Software, LLC
just right software @ just right prices @3bears.biz
"Cor Ligthert" wrote:

Al,

When I understand you well, than when if I have a problem like yours try
forever to seperate data and UI.

Probably will I for your problem create a class that can holds as objects
for every menuItem the information. Those Items will I than store probably
in a nested arraylist.

Than I can do what I want by just accessing the arraylist depending on
stored previous done information.

As last I can serialize and store it, save it and set it next time for the
user back from where he/she ended the last time.

Just my thought,

Cor

[Al Christoph]

Mea Culpa, maybe. I see that there is a performclick method introduced in VS
2005. Right on. BUT who would have thought to look at that end of the
alphabet for a method involving click. When there are 6000 classes to master
even sensible names like this one may be obscure to find.

QUESTIONS remain. In particular I assume that performclick is a synchronis
operation. (Control does not return to the caller until all the processing in
the click is complete.) Correct? That still leave me wanting to do this
asynchronously so that it better mimics what the user actually does with
respect to message loop processing.

--
Regards,
Al Christoph
Senior Consultant and Proprietor
Three Bears Software, LLC
just right software @ just right prices @3bears.biz
"Al Christoph" wrote:

I have a program that mixes wizard like behavior with random access to the
various dialogs in the wizard. I do this by having each step map to a
toolstripmenuitem. Users can randomly choose the menu item and get the
corresponding dialog. Alternatively at the completion of each dialog, I can
"click" on the menu item and cause the appropriate dialog to come up. It
works rather well but the way I've done it is a horrible kludge. I even left
things out the first time:-(((

I put click in quotes above because I have yet to come up with an elegant
way to do this as noted. What I want is to be able to compute the name of the
next menu item to call and cause its click code to execute, preferably in a
way that exactly mimics the user action.

QUESTION: What is the best approach to do this so that I don't stack up a
whole pile of nested calls most of which are right at the end of the previous
call?

QUESTION: In other environments i'd post/send (I always have to look up
which does it asynchronously) a WM_Click message to the control. Is that the
right thing to do here? If so what is the .net way to do it?

I've tried using reflection to get the eventinfo etc and invoke the event.
That fails because at some point in the process reflection returns NOTHING.
(Code upon request.) QUESION: If I had been able to get reflection to work
what are the odds I would have ended up with that undesired stack of calls.

BOTTOM LINE QUESTIONS: If variable mi contains a toolstripmenuitem whose
click event you wish to cause / invoke, preferablly asynchronously (i.e
through the genration of some kind of message processed by the message loop)
what is the best way to do it? If my fetish for asynchronicity is
inappropriate, then why? What is the synchronous way to do this.
--
Regards,
Al Christoph
Senior Consultant and Proprietor
Three Bears Software, LLC
just right software @ just right prices @3bears.biz

[Chris Dunaway]

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.

[Al Christoph]

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
"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.