>>>Hi to All,
>>>
>>>Last friday I posted a request for some feedback and no one replied. So, I will retry. Perhaps you skipped the message because it's lacking some concrete code. However, I will not modify the text, because I still expect it is good enough to trigger your thoughts. If you think a piece of code is needed to start the discussion, then I'll post my first, but partly failing, attempt. Here's the text:
>>>
>>>---
>>>
>>>I have developed a shortcut menu (for a treeview) that I also want to offer in the main menu, but without having to write the same code twice. The shortcut menu code is in a method of the form. Actually, it is re-initialized each time that the user rightclicks on the treeview, in order to disable certain options and mark other options.
>>>
>>>The idea is that a user should also be able to choose the menu options via the keyboard, for example if the mouse is unavailable. This design is also dominant in Visual FoxPro itself, for example the project manager's shortcut menu is (largely) repeated in the main menu under the pad Project.
>>>
>>>Who has already dealt with this design? Any suggestions on how to handle it?
>>
>>Hi Peter,
>>
>>First of all, you should expect to be using PRG-based menus, if that isn't already a given. VFP's menu designer is a handy way to get started, but kiss it goodbye after you use it to generate some preliminary sample menu code. You'll have much more flexibility with PRGs, which can take any sort of arguments and support any dynamic behavior you'd like. Instead of putting the common menu logic into a method, just let the method pass an object reference to your menu PRG, or initialize a reserved private memory variable to THIS before invoking the menu program.
>>
>>HTH
>>
>>Mike
>
>Hi Mike,
>
>Oh well, let me show some code then. Hope it doesn't confuse you and others.
>
>This is the TreeviewMenu() method:

lparameter tcAction, tcMenuName
>
>local llExpanded, lcAction, lox, i
>
>lcAction = lower( tcAction )
>
>with thisform
>
>	do case
>	case inlist( lcAction, 'init shortcut', 'init main' )
>		*
>		with thisform.pgf.pagMain.oleTreeview
>			*
>			llExpanded = .Nodes(1).Expanded
>
>* This call is not appropriate if 'init main' is intended. But what is appropriate then?
>			DEFINE POPUP treeview SHORTCUT RELATIVE FROM MROW(),MCOL()
>			
>			DEFINE BAR   1 OF treeview PROMPT "E\<xpand all"
>			DEFINE BAR   2 OF treeview PROMPT "\<Collapse all" skip for not llExpanded
>			* etc..
>		endwith
>		*
>		ON SELECTION BAR 1 OF treeview goMainWindow.TreeviewMenu( '+' )
>		ON SELECTION BAR 2 OF treeview goMainWindow.TreeviewMenu( '-' )
>		* etc..
>		*
>* This call is not appropriate if 'init main' is intended. But what is appropriate then?
>		activate popup treeview
>
>	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 etc...
>	endcase
>
>endwith

>
>
>And here is the direct command in the built main menu:

goMainWindow.TreeviewMenu( "init main" , "&cMenuName.")

>
>I'll be back tomorrow, because it's now bedtime in Europe. :)

Peter,

The syntactic differences between the main menu and shortcut menus are most easily seen by using VFP's menu generator. For example, here's a little bit of code to define a main menu pad called Format:

* define the main menu pad for the Format submenu
DEFINE PAD mofmtpad OF _MSYSMENU PROMPT "Format" COLOR SCHEME 3 ;
	AFTER moviewpad ;
	KEY ALT+O, "" ;
	MESSAGE "Text and image formatting options."

* cause the Format submenu to appear when its main menu pad is selected
ON PAD mofmtpad OF _MSYSMENU ACTIVATE POPUP mofmtpop

* define the Format submenu popup
DEFINE POPUP mofmtpop MARGIN RELATIVE SHADOW COLOR SCHEME 4

* define various text Font-related menu bars contained in the Format submenu
DEFINE BAR 10 OF mofmtpop PROMPT "\<Font..." ;
	SKIP FOR &skpfontif ;
	MESSAGE "Select a text font."
ON SELECTION BAR 10 OF mofmtpop ;
  docmd("getfontx(&vwformname..moc_viewer)", "_screen.moc_main.mom_setenablements()")

...

Going beyond syntactic differences, shortcut menus are typically generated dynamically each time they are invoked, while main menus are most commonly initialized once. You don't have to do things that way, but it's the least klunky way to use main menus. This imposes some limitations on how dynamic your main menus can be, since there's not much to work with besides the SKIP FOR clause. Of course you could have code to somehow refresh or modify the main menu on some basis, but this can easily get ugly and complicated.

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