>[SNIP]
>>Here's one trick I've come up with, for example to support a dynamic checkmark in a main menu: use a dummy expression in the SKIP FOR clause to force the required refresh logic to be executed when it's needed. The following is an illustration:
>>
>>

>>DEFINE BAR 610 OF moviewpop PROMPT "Always on \<Top" ;
>>	SKIP FOR not docmd("SET MARK OF BAR 610 OF moviewpop TO _screen.AlwaysOnTop") ;	&& force refresh as nec.
>>	MESSAGE "Toggle whether to keep this " + MONT_APPNAME + " Desktop in front of other windows."
>>ON SELECTION BAR 610 OF moviewpop _screen.AlwaysOnTop = not _screen.AlwaysOnTop		&& toggle the setting
>>SET MARK OF BAR 610 OF moviewpop TO _screen.AlwaysOnTop
>>

>>
>>The docmd() function is just a generic UDF that executes the specified command line(s), always returning .T. (Hence this is just a "dummy" SKIP FOR clause, since it never actually disables the menu bar.)
>>
>>Mike
>
>Hi Michael,
>
>I have read your smart trick. However, in my case the solution has been constructed somewhat different. Below I try to explain it all, but I'm not sure whether many people will be able (or are willing to try) to follow it. I am not even sure whether it works in all circumstances and is robust enough. Anyhow, it is a start.
>
>If any co-reader thinks that I am doing things overly complicated, then please tell me. :)
>
>
>In my generated main menu I have...
>

>DEFINE PAD sessioninfo OF (m.cMenuName) PROMPT "\<Session info" COLOR SCHEME 3 ;
>	KEY ALT+S, "" ;
>	SKIP FOR isnull( goMainWindow ) or empty( goMainWindow.cMPSFile )
>

>goMainWindow is a global variable that holds a reference to the form.
>goMainWindow.cMPSFile is a variable that is a prerequisite for a successfully filled treeview.
>
>There is no corresponding ON PAD statement in the generated mpr. Of the choices
>'Command', 'Pad Name', 'Submenu', 'Procedure' I had chosen Pad Name and filled in 'sessioninfo'.
>
>The menu is loaded in the form's Load() method:
>

>	lcMenuName = ""
>	do BasicMenuSM.mpr with this, lcMenuName, .t., .t.
>	thisform.cMenuName = lcMenuName
>

>So, there is a userdefined property cMenuName. I'll need it later.
>
>There is a method TreeviewMenu()...
>

>lparameter tcAction, tuP1
>
>local lcAction, lox, i
>
>lcAction = lower( tcAction )
>
>with thisform
>
>	do case
>	case inlist( lcAction, 'init', 'menu init' )
>		*
>		if empty( .cMPSFile )
>			RETURN .F.
>		endif
>		*
>		if lcAction = 'menu init'
>			*	Pad named 'sessioninfo' has already been predeclared
>			*	in the menu BasicMenuSM.mnx.
>			ON PAD sessioninfo OF (thisform.cMenuName ) activate popup treeview
>			DEFINE POPUP treeview MARGIN RELATIVE SHADOW COLOR SCHEME 4
>		else
>			DEFINE POPUP treeview SHORTCUT RELATIVE FROM MROW(),MCOL()
>		endif
>		
>		*	Use goMainWindow instead of thisform, because menusystem
>		*	can't handle thisform, but it can handle goMainWindow.
>		DEFINE BAR   1 OF treeview PROMPT "E\<xpand all"
>		DEFINE BAR   2 OF treeview PROMPT "\<Collapse all" ;
>			skip for not goMainWindow.pgf.pagMain.oleTreeview.Nodes(1).Expanded
>		DEFINE BAR   7 OF treeview PROMPT "Show current \<actions"
>
>		*
>		ON SELECTION BAR 1 OF treeview goMainWindow.TreeviewMenu( '+' )
>		ON SELECTION BAR 2 OF treeview goMainWindow.TreeviewMenu( '-' )
>		ON SELECTION BAR 7 OF treeview goMainWindow.TreeviewMenu( 'actions' )
>		*
>		set mark of bar 7 of treeview to goMainWindow.lShowActions
>		*
>		if lcAction == 'init'
>			activate popup treeview
>		endif
>
>	case lcAction = 'menu remove'
>		*
>		release popup treeview		&& will not generate an error if it still doesn't exist
>
>	case inlist( lcAction, "+-", "+", "-" )
>
>		do case
>		case lcAction == "+-"		&& This action indicates that the current setting must be used.
>		case lcAction == "+"		&& Let's expand.
>			.lExpanded = .T.
>		case lcAction == "-"		&& Let's collapse
>			.lExpanded = .F.
>		endcase
>
>		lox = .pgf.pagMain.oleTreeview
>		.lockscreen = .t.
>		lox.visible = .f.
>
>		FOR i = 1 TO lox.Nodes.Count
>			lox.Nodes(i).Expanded = .lExpanded
>		ENDFOR
>
>		lox.visible = .t.
>		lox.setfocus()
>		
>		.lockscreen = .f.
>
>	case lcAction = 'actions'
>		*
>		.lShowActions = not .lShowActions
>		.filltreeview()		&& refreshes treeview
>		.TreeViewMenu( "+-" )
>		set mark of bar 7 of treeview to goMainWindow.lShowActions
>		.refresh()
>
>	endcase
>
>endwith
>
>RETURN .T.
>

>The MouseDown() event of the treeview contains this code...
>

>*** ActiveX Control Event ***
>LPARAMETERS button, shift, x, y
>
>if button = 2 and shift = 0	&& if rightclick
>	*
>	thisform.treeviewmenu( 'init' )
>endif
>

>And there's also a method that's responsible for the just-in-time declaration of the popup of the sessioninfo menu pad. In my case it is in the method that acts on a selected file. The crucial code herein is...
>

>with thisform
>	...
>	if not .CreateCursors()	&& creates a cursor that's used to fill the treeview
>		*
>		if reccount( 'c_treeview' ) = 0
>			*
>			.cMPSFile = ""
>			.TreeviewMenu( "menu remove" )
>			.pgf.pagMain.oleTreeview.nodes.clear()
>		endif
>		.refresh()
>	else
>		.TreeviewMenu( "menu init" )
>		.TreeviewMenu( "+-" )
>		.refresh()
>	endif
>endwith
>

>The crux is that the main menu must have been updated BEFORE the user rightclicks on the treeview! If that's not the case, then the main menu's treeview popup will be at the wrong place with the wrong color scheme.

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.

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.:)

Mike