>>>>[SNIP]
>>[SNIP]
>>>
>>>Peter,
>>>
>>>I'm glad you liked my little trick, but you didn't use it. If I understand your problem correctly (and I may not), it does seem as though you might benefit from what I was illustrating. The idea is to let VFP do the work in such a way as to be absolutely assured that the necessary main menu adjustments have been made by the time they're needed. Put your own UDF into the SKIP FOR clause, and let it do whatever is necessary to prepare the menu for the user, instead of relying on tricky refresh schemes driven by other events. The main menu doesn't need to be refreshed until it's actually used, and that's when the SKIP FOR evaluations take place. What I'm suggesting is that you think about redesigning your logic a bit to make use of this mechanism - if it's worth the trouble. You could just punt the whole thing by having a tie-in from the main menu to invoke the context menu, without actually trying to replicate it.
>>
>>Hi Mike,
>>
>>I have incorporated your idea:

DEFINE BAR 7 OF treeview PROMPT "Show current \<actions" ;
>>	skip for not DoCmd( 'set mark of bar 7 of treeview to goMainWindow.lShowActions' )

>>However, I don't entirely share your idea of 'tricky refresh schemes driven by other events'. So, I felt no need to do other things with Skip/DoCmd().
>>
>>Your note that the main menu doesn't need refreshed until it's actually used, needs refinement, at the least. One might build a popup under a menu pad that contains expressions that, for the time being, are invalid, under the assumption that they are not evaluated as long as the menu pad is disabled. However, even then these expressions will cause errors as soon as the menu is activated. What I'm saying is that there are also unexpected refresh moments.
>>
>>
>>>If I'm missing the point, I apologize for the confusion. It's not entirely clear what you are asking, so you might consider asking a more focused question. Are you simply trying to avoid some semi-redundant code, or are you encountering a functional limitation? Is it a question about the mish-mosh of confusing menu commands and the menu builder? I don't think the issue is TreeViews, but I could be wrong about that too. Anyway, I hope there was some small increment of help in there.:)
>>
>>I'm indeed trying to avoid (semi-)redundant code. The issue is indeed not Treeviews. The issue is that the items of a rightclick menu should also be available to non-mouse users via the main menu. As it is now, we need to do additional programming to get this realized. Thanks for your feedback. :)
>
>OK, Peter, I think we understand each other. You may have milked the SKIP FOR trick for all it's worth, and I can see how there might be limits of the sort you describe. I'd expect those limits to relate to things you can't change while a menu is already active, though. So, if you have a submenu that requires adjustment before it's activated, you might still be able to perform the necessary logic in a SKIP FOR attached to an item in the parent menu, before the submenu gets activated. In other words, the dummy SKIP FOR expression in such a case would not relate directly to the item that SKIP FOR is attached to - it's just a convenient place to hook into at the right point in time. I'm not sure if this is helpful in your case, but I'm pointing this out for the sake of completeness. Good luck to you in finding the cleanest solution to your problem.

Thanks. I guess at least the SET MARK command should be a keyword too of DEFINE BAR. I have added it to the wish list, see Wish list ID: 1542.