个回答天前这是一个现在正在工作的解决方案。使用，将该单元添加到dpr使用列表中（我必须在其他表单的顶部附近放置它）会导致正确的字体大小应用于菜单画布，这取决于保存菜单项在任何弹出式菜单中。该解决方案故意忽略顶层菜单（主菜单栏），因为VCL没有正确处理所有者测量的项目。unit slMenuDPIF
// add this unit to the main application dpr file BEFORE ANY FORMS in the uses list.
implementation
Winapi.Windows, System.Classes, Vcl.Graphics,
Vcl.Controls, Vcl.Forms, Vcl.Menus, slScaleUtils, Math,
TMenuClass = class(TMenu);
TMenuItemClass = class(TMenuItem);
TrampolineMenuCreate: procedure(const Self: TMenuC AOwner: TComponent) =
TrampolineMenuItemAdvancedDrawItem: procedure(const Self: TMenuItemC ACanvas: TC ARect: TR State: TOwnerDrawS TopLevel: Boolean) =
TrampolineMenuItemMeasureItem: procedure(const Self: TMenuItemC ACanvas: TC var Width, Height: Integer) =
function GetPopupDPI(const MenuItem: TMenuItemClass): I
pcf: TCustomF
Result := Screen.PixelsPerI
pm := MenuItem.GetParentM
if Assigned(pm) and (pm.Owner is TControl) then
pcf := GetParentForm(TControl(pm.Owner))
if Assigned(pcf) and (pcf is TForm) then
Result := TForm(pcf).PixelsPerI
procedure MenuCreateHooked(const Self: TMenuC AOwner: TComponent);
TrampolineMenuCreate(Self, AOwner);
Self.OwnerDraw := T
// force always ownerdraw.
procedure MenuItemAdvancedDrawItemHooked(const Self: TMenuItemC ACanvas: TC ARect: TR State: TOwnerDrawS TopLevel: Boolean);
if (not TopLevel) then
ACanvas.Font.Height := MulDiv(ACanvas.Font.Height, GetPopupDPI(Self), Screen.PixelsPerInch);
TrampolineMenuItemAdvancedDrawItem(Self, ACanvas, ARect, State, TopLevel);
procedure MenuItemMeasureItemHooked(const Self: TMenuItemC ACanvas: TC var Width, Height: Integer);
lHeight: I
pdpi := GetPopupDPI(Self);
if (Self.Caption && cLineCaption) and (pdpi && Screen.PixelsPerInch) then
ACanvas.Font.Height := MulDiv(ACanvas.Font.Height, pdpi, Screen.PixelsPerInch);
lHeight := ACanvas.TextHeight('|') + MulDiv(6, pdpi, Screen.PixelsPerInch);
lHeight := 0;
TrampolineMenuItemMeasureItem(Self, ACanvas, Width, Height);
if lHeight & 0 then
Height := Max(Height, lHeight);
initialization
TrampolineMenuCreate := InterceptCreate(@TMenuClass.Create, @MenuCreateHooked);
TrampolineMenuItemAdvancedDrawItem := InterceptCreate(@TMenuItemClass.AdvancedDrawItem, @MenuItemAdvancedDrawItemHooked);
TrampolineMenuItemMeasureItem := InterceptCreate(@TMenuItemClass.MeasureItem, @MenuItemMeasureItemHooked);
finalization
InterceptRemove(@TrampolineMenuCreate);
InterceptRemove(@TrampolineMenuItemAdvancedDrawItem);
InterceptRemove(@TrampolineMenuItemMeasureItem);
人们可以轻松地修补Vcl.Menus，但我不想这样做。slidingmenu给菜单添加手势滑动关闭菜单
[问题点数：40分]
slidingmenu给菜单添加手势滑动关闭菜单
[问题点数：40分]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
2014年6月 移动开发大版内专家分月排行榜第一2014年3月 移动开发大版内专家分月排行榜第一
2014年11月 移动开发大版内专家分月排行榜第二2014年4月 移动开发大版内专家分月排行榜第二2014年2月 移动开发大版内专家分月排行榜第二
匿名用户不能发表回复！|Visual FoxPro Menus
Creating Custom Visual FoxPro Menus
Rodney Hill, Microsoft Corporation
If you're creating Windows&
95-compatible applications, you need to provide a menu system to expose the application's functionality to users. The Microsoft & Visual FoxPro™ Developer's Guide discusses some of the design considerations and mechanics of creating a menu system, and that is the best place to start if you are new to Visual FoxPro menus. This article supplements
that information in the following areas:
Most of the information in this article applies to both Visual FoxPro 3.0 and 5.0. Information that is specific to
Visual FoxPro 5.0 is noted. You can download a zipped copy of this document,
(45 KB) (428 KB uncompressed).
The easiest and quickest way to create a menu is
to use the Visual FoxPro Menu Designer, and this article assumes
that you'll be doing this. The best strategy for creating menus
is probably the same strategy that Microsoft has been taking with
the Internet: embrace and extend. In the Menu Designer
context, this means using the tool that Visual FoxPro provides,
but extending its capabilities by adding your own code.
Using the Menu Designer to create menus is described in the Visual FoxPro Developer's Guide. Basically, the process is:
Use the Menu Designer to create the menu structure and assign commands to be executed when users choose menu items.
Generate Visual FoxPro menu definition code (to a program file with an .MPR extension by default).
Run the program in your application to create the menu.
A menu program, like other Visual FoxPro programs, runs, does what it is supposed to do (in this case define and
display the menu), and then ends. The menu program does not continue running in the background, waiting for a user to choose an item from a menu. The commands that are processed when a user chooses a menu item are scoped at the system level, that is, they have access to PUBLIC variables, programs, and procedures in files specified with the SET PROCEDURE TO command.
Of course, since you cannot use THISFORM or THIS
outside method code, you cannot use them in code to be executed
when a user chooses a menu item. To call methods or set properties
of a form from a menu, use the form's object reference, or more generically _SCREEN.ActiveForm. For example, for a Close option on a File menu, you could use the following line of code:
_SCREEN.ActiveForm.Release
Designing Modular Menus
You can design the entire menu structure for your
application in the Menu Designer and generate a single menu program,
but it's not necessarily a good idea. You can get some of the
same advantages that you get with modular or object-oriented programming when you design modular menus.
Instead of creating one menu program to define your entire menu structure, create separate programs for each menu in the menu system, or maybe for selected groups of menus. For example, if you create separate File, Edit, Window, Help, and application-specific menus, you can reuse the generic menus easily in multiple applications, coding and maintaining them in one place. You can also more easily add and remove specific menus as they are needed.
Designing menus one at a time in the Menu Designer is an easy and straightforward way to create modular menus. There
are also other tools or techniques you can use. For example, GenMenuX, a public domain tool written by Andrew Ross MacNeill, allows you to create reusable menu templates for modular menu design. GenMenuX is available for download from several Internet sites and CompuServe's FOXUSER forum.
Saving and Restoring the Original Menu
In your application, remember to push the existing
menu on the menu stack (that is, save it to be restored later)
before running your menu program, and, when the user is finished
with your application, pop the old menu off the stack, as in the
following main program of an application.
&* Push the existing menu on the menu stack
&PUSH MENU _MSYSMENU
&* Display interface
&DO File.MPR
&DO Edit.MPR
&DO MyApp.MPR
&DO Window.MPR
&DO Help.MPR
&DO FORM InitialForm
&* Allow interface to process events
&READ EVENTS
&* Restore the original menu
&POP MENU _MSYSMENU
The menu stack, like all stacks, operates on a last
on, first off, basis. If you push menu A on the stack, run menu
B, then push menu B on the stack, and run menu C, executing the
POP MENU command will restore menu B. The next time you issue the POP MENU command, you'll restore menu A.
Note& PUSH MENU _MSYSMENU takes up about 12K of memory, and pushing a fully user-defined menu can take more. So for every PUSH MENU, there should always be a balancing POP MENU to make sure memory usage is kept to a minimum.
Using Cascading Menus
Cascading menus are menus that are opened when a
user selects a menu item on another menu. You can easily create cascading menus with the Menu Designer, but that doesn't mean that you necessarily should. Cascading menus require more mouse dexterity on the part of the user and can't provide the context or visual clues that a dialog box can. Users rarely appreciate a cascading menu that displays a single item. The developer could just as easily have put the single item on the original menu. You'll also want to avoid opening cascading menus from shortcut menus or making a user open a cascading menu from a cascading menu to get to the functionality you want to expose.
Using Visual FoxPro menu commands and functions in conjunction with the Menu Designer and Form Designer allows you to create dynamic menus that are configurable at run time and
aware of the environment.
Menu Elements
The Menu Designer generates (via _GENMENU) Visual FoxPro menu definition code. When you understand this menu code, you are in a better position to extend the Menu Designer menus.
Terminology has always been a problem with menus in general and FoxPro menus in particular. Microsoft documentation for example has alternately used the terms menu command, menu option, and menu item to refer to the thing programmatically created in Visual FoxPro with the DEFINE BAR command. In Visual FoxPro code, a menu consists of PADs on _MSYSMENU, POPUPs that are activated when a user chooses a PAD, and BARs that are the items on the popup that the user chooses to perform some action. When this article, and the Visual FoxPro documentation, refers to a menu, the elements involved are a pad, a popup, and one or more bars.
The following illustration shows how the Visual FoxPro menu definition code maps to menu elements.
If you search the Visual FoxPro Help file for &Menus and Menu Bars,& you'll get a list of all the menu definition and manipulation commands and functions with jumps to detailed syntax and examples. The following example walks through the most basic menu commands in the order they would normally be executed.
Before setting up your application's menu system, you need to remove the default Visual FoxPro menu system. The following line of code removes all the system menu pads from the system menu bar.
SET SYSMENU TO
You can add a new menu pad to the system menu bar
with the DEFINE PAD command.
&DEFINE PAD padReports OF _MSYSMENU ;
& &PROMPT &\&Reports& ;
& &MESSAGE &Choose a report to run&
When a user clicks the new pad, however, nothing happens. You need to define a popup and bars on the popup to display the kind of menu that users expect to see when they click a menu pad.
&DEFINE POPUP popReports MARGIN
&ON PAD padReports OF _MSYSMENU ACTIVATE POPUP popReports
&DEFINE BAR 1 OF popR
& &PROMPT &Invoice& ;
& &MESSAGE &Print an Invoice&
Now when the user clicks the Reports pad, the Invoice menu item is displayed. But you still need to add code to determine the action associated with the menu item.
ON SELECTION BAR 1 OF popReports REPORT FORM INVOICE.FRX PREVIEW
Using the Visual FoxPro System Menus
In addition to menus that you create from scratch, you can use predefined Visual FoxPro system menu elements in your applications, and there are a couple of good reasons why you should.
System menus have built-in functionality. The Edit menu (pad name _MSM_EDIT and popup name _MEDIT), for example, allows cutting, copying, pasting, and finding text. If the Edit menu isn't available, you cannot cut, copy, or paste. The Window menu (pad name _MSM_WINDO and popup name _MWINDOW) displays the Caption of your running forms and allows a user to activate a form by choosing the caption from the menu.
In the General Options dialog box of the Menu Designer, you can specify a location before or after a system
For a list of all the system menu pad, popup, and bar names, search the Visual FoxPro Help file for &System
Menu Names& or use the SYS(2013) function. The Quick Menu feature of the Menu Designer allows you to easily add all the system menus to your menu. From there, you can customize. In Visual FoxPro 5.0 when you are creating generic menu components, you can just choose Insert Bar in the Menu Designer to add Visual FoxPro system menu options one at a time.
When you are creating an application-specific menu component, you probably won't need Visual FoxPro's system menus, but remember to specify the Location for your menu in the General Options dialog box. If you want the application-specific menu to be displayed to the left of the generic Window menu, choose Before and then choose Window in the drop-down that becomes visible.
Note&You can programmatically access Visual FoxPro 5.0 system menu functionality with the SYS(1500)
function. For example, if the active window is an editing window, the following line of code opens the Visual FoxPro Find dialog box:
?SYS(1500, &_MED_FIND&, &_MEDIT&)
Disabling Menu Items
One of the most common means of having a menu dynamically adjust to the user's current work environment is to disable or enable menu items as appropriate. When you define a menu bar, use the SKIP FOR clause to specify when the menu item should be disabled. When the expression indicated by the SKIP FOR command evaluates to true (.T.) the menu item is disabled. For example, if you have a Close option on a File menu, the following line of code ensures that it is enabled only when a form is active:
&DEFINE BAR 3 OF _MFILE ;
&&PROMPT &Close& ;
&&MESSAGE &Close the currently active form& ;
& &SKIP FOR TYPE(&_SCREEN.ActiveForm&) != &O&
& ON SELECTION BAR 3 OF _MFILE _SCREEN.ActiveForm.Release
Two samples in the Visual FoxPro Solutions sample application illustrate disabling menu items: Coordinate Menu Items and Toolbar Buttons and Disable or Display a Check Beside a Menu Item. When you run these samples, press F1 to see a description of how they were implemented.
Visual FoxPro system menus automatically take care of disabling inappropriate items. For example, the Cut, Copy, Paste items on the Edit menu (pad name _MSM_EDIT and popup name _MEDIT) are automatically disabled when no text is selected or no text is in the clipboard to paste.
You can include the SKIP FOR expression in the Menu Designer when you create a menu item. While you can use the SKIP FOR clause or the SET SKIP OF command to disable an entire menu in your application by disabling the pad, this is not a standard interface for a Windows application. When a menu isn't applicable for a given environment, it should be removed altogether, as described in the following section.
Associating Menu Pads with Forms
Often you'll want to extend the functionality of a form by putting less frequently-used options on a menu. The menu is only appropriate when the form is active, so you need to remove the menu when the form is not active. For example, in Visual FoxPro, when the Project Manager is the active window, there is a Project menu on the menu bar. When the Project Manager is not the active window, the Project menu is removed.
To design a menu to be associated with a form:
Create a menu pad in the Menu Designer with the menu items appropriate for your form.
When the Menu Designer is the active window, choose General Options from the View menu.
Choose Append, Before, or After for a Location. Don't choose Replace or you'll lose all the other menu pads when
your form is running.
In the Menu Designer, click the Options button to open the Prompt Options dialog box.
In the Prompt Options dialog box, specify a Pad Name. You'll need the pad name when removing the pad from the
system menu.
Generate the menu code.
To associate the menu with the form:
In the Activate event of the form, run your menu. For example, if your menu is defined in FORMMENU.MPR, include
the following code:
DO FormMenu.MPR
In the Deactivate event of the form and the Destroy event of the form, release the menu pad. For example, if your
menu pad is named myform, include the following line of code in both places:
RELEASE PAD myform OF _MSYSMENU
Displaying Most Recently Used Documents on the File Menu
Windows applications often display the most recently used (MRU) documents on the File menu so that a user can quickly go back to a document or project that he or she has been working on. It is relatively easy to provide this functionality in your applications.
Tracking Most Recently Used Documents
In order to display the most recently used forms,
or most recently run reports or queries, you need to save information about these documents in a table. The following table, for example, saves the prompt to display on the menu, the action to be performed when the user chooses the item, and a timestamp to order the items by their most recent use.
Obviously, you don't want to display the last thirty
forms, reports or queries on the file menu, so you'll need to limit the number of items to display, a good number being between four and eight.
When the user runs a query, report, or form, select the table for storing the most recently used items, UPREFS.DBF in this example, and update the information, as illustrated in
the following code.
In this code, cFormName is the name of the
form the user is about to run, cAction is a string with
the action to be performed when the user subsequently chooses
the menu item to reopen the form (in this case, probably &DO
FORM& + cFormName), and nMaxItems
is the limit you have set for the number of most recently used
items to display.
& SELECT Uprefs
&LOCATE FOR prompt = cFormName
&IF FOUND()
&& &REPLACE Timestamp WITH DATETIME()
&&IF RECCOUNT() & nMaxItems && maximum number of items to display
&&&INSERT INTO Uprefs VALUES(cFormName, cAction, DATETIME())
&& &SET ORDER TO Timestamp ASCENDING && oldest at top
&& &GO TOP
&& &REPLACE prompt WITH cFormName
&& &REPLACE Action WITH cAction
&& &REPLACE Timestamp WITH DATETIME()
Every time you update the preferences table, you
need to rerun the File menu program:
&DO FILE.MPR
Adding Most Recently Used Documents to the File Menu
When you create the File menu in the Menu Designer,
create all the items for the File menu except for the separator
bar and Exit item at the end of the menu. These will be added
in code after the most recently used items are added.
Add the following code in the Cleanup editing window.
In this code, the nBar variable always reflects the number of defined bars on the menu. The iPrefix variable stores the number to be displayed beside the most recently used item.
&nBar = CNTBAR(&_MFILE&)
&cOldAlias = ALIAS()
&IF !USED('UPrefs')
& &USE UPrefs IN 0
&SELECT Uprefs
&* order so that most recently used is at the top
&SET ORDER TO timestamp DESCENDING
&IF RECCOUNT() & 0 && some user preferences are saved
& &iPrefix = 0
& &nBar = nBar + 1
& &* add a separator bar before the MRU list
& &DEFINE BAR nBar OF _MFILE PROMPT &\-&
& & &nBar = nBar + 1
& & &iPrefix = iPrefix + 1
& & &cAction = ALLTRIM(UPrefs.Action)
& & &DEFINE BAR nBar OF _MFILE PROMPT &\&& + ;
& & & &ALLTRIM(STR(iPrefix)) + & & + UPrefs.Prompt
& & &ON SELECTION BAR nBar OF _MFILE &cAction
& &ENDSCAN
&* Add the Exit menu item
&DEFINE BAR nBar + 1 OF _MFILE PROMPT &\-&
&DEFINE BAR nBar + 2 OF _MFILE PROMPT &E\&xit&
&ON SELECTION BAR nBar + 2 OF _MFILE CLEAR EVENTS
&IF !EMPTY(cOldAlias)
& &SELECT (cOldAlias)
Given the two items in the table in the example, the following illustration displays the resulting menu.
A top-level form (also referred to as a Single Document Interface or SDI form) is not a child window of the main Visual FoxPro window. In Visual FoxPro 3.0, you can create an SDI form by setting the Desktop property of the form to true (.T.). Top-level forms in Visual FoxPro 5.0 are more truly independent of the main Visual FoxPro window. You can create a top-level form in Visual FoxPro 5.0 by setting the ShowWindow property of the form to 2 - As Top-Level Form. Because the top-level form is not contained in the main Visual FoxPro window and doesn't necessarily have access to the system menu, you might want to add a menu directly to your form.
The Visual FoxPro 3.0 Menu Designer doesn't allow
you to create a menu for a top-level form, so you'll have to write
the code yourself. The following code, for example, can be added
to the Init event of a form to add a menu to the form:
&DEFINE MENU _example BAR IN WINDOW (THISFORM.Name) COLOR SCHEME 1
&DEFINE PAD p1 OF _example PROMPT &\&File&
&DEFINE PAD p2 OF _example PROMPT &\&Color&
&ON PAD p1 OF _example ACTIVATE POPUP file
&ON PAD p2 OF _example ACTIVATE POPUP color
&DEFINE POPUP file MARGIN
&DEFINE BAR 1 OF file PROMPT &E\&xit&
&ON SELECTION BAR 1 OF file _SCREEN.ActiveForm.Release
&DEFINE POPUP color MARGIN
&DEFINE BAR 1 OF color PROMPT &ForeColor&
&DEFINE BAR 2 OF color PROMPT &BackColor&
&ON SELECTION BAR 1 OF color _SCREEN.ActiveForm.SetAll(&ForeColor&, GETCOLOR())
&ON SELECTION BAR 2 OF color _SCREEN.ActiveForm.SetAll(&BackColor&, GETCOLOR())
&ACTIVATE MENU _example NOWAIT
In Visual FoxPro 5.0, you can use the Menu Designer
to create menus for top-level forms. Choose General Options from
the View menu to open the General Options dialog box, and choose
Top-Level Form to create a menu for a top-level form.
When you generate a menu for a top-level form, the
generated menu code includes comments on how to use the menu:
&* To attach this menu to your Top-Level form,
&* call it from the Init event of the form:
&* Syntax: DO &mprname& WITH &oFormRef& [,&cMenuname&|&lRename&]
&* oFormRef - form object reference (THIS)
&* cMenuname - name for menu
&* lRename - renames Name property of your form
&* example:
&* PROCEDURE Init
&* DO mymenu.mpr WITH THIS,.T.
&* ENDPROC
&* Use the optional 2nd parameter if you plan on running
&* multiple instances of your Top-Level form. The logical
&* lRename parameter will change the name property of your
&* form to the same name given the menu and may cause conflicts
&* in your code if you directly reference the form by name.
&* You will also need to remove the menu when the form is
&* destroyed so that it does not remain around in memory
&* unless you wish to reactivate it later in a new form.
&* If you passed the optional lRename parameter as .T. as in
&* the above example, you can easily remove the menu in the
&* form's Destroy event as shown below. This strategy is ideal
&* when using multiple instances of Top-Level forms.
&* example:
&* PROCEDURE Destroy
&* RELEASE MENU (THIS.Name)
&* ENDPROC
A shortcut menu is typically displayed when a user
right-clicks on an object. When you create a new menu in Visual FoxPro 5.0, you have to choose whether you want to create a normal menu or a shortcut menu.
In Visual FoxPro 5.0, there are two examples of shortcut
menus in the Visual FoxPro Solutions sample application: Display shortcut menus and Create dynamic shortcut menus. The Create dynamic shortcut menus example, described in the &Creating Shortcut Menus Without the Menu Designer& section below, uses menu definition code in a menu utility class to create the shortcut menu. With a minor adjustment, this code can also be used in Visual FoxPro 3.0.
Displaying Check Marks Beside Shortcut Menu Options
You can dynamically display check marks beside items on a shortcut menu by including the #PREPOP directive in the Setup code for the menu and using the SET MARK OF command in the Cleanup code. The #PREPOP generator directive causes the code in the menu's Cleanup to be generated before the ACTIVATE POPUP command.
The Display shortcut menus example in the
Visual FoxPro Solutions sample application illustrates adding
a check mark beside a shortcut menu item.
The following line of code is included in the RightClick
event of the &Display shortcut menus& example form:
&DO frmshort.mpr WITH THIS
FRMSHORT is the shortcut menu. The following code
is included in the Setup code window for the menu:
&PARAMETER oREF
The oREF parameter allows you to check or set object
(in this case, the form) properties in the menu code. The following code in the Cleanup code window sets a check mark beside a menu item if the AlwaysOnTop property of the form is set to true (.T.).
&SET MARK OF BAR 4 OF frmshort
&TO oRef.AlwaysOnTop
The code that is generated from the menu includes
the following lines, modifying the display of the menu item before
the shortcut menu is displayed:
&SET MARK OF BAR 4 OF frmshort TO oRef.AlwaysOnTop
&ACTIVATE POPUP frmshort
Without the #PREPOP directive, the following code
would be generated.
&ACTIVATE POPUP frmshort
&SET MARK OF BAR 4 OF frmshort
&TO oRef.AlwaysOnTop
And because code execution is suspended with the
ACTIVATE POPUP command until the user makes a choice, the SET
MARK OF command isn't executed until after the shortcut menu is
no longer displayed.
Creating Shortcut Menus Without the Menu Designer
You can also create shortcut menus without the Menu Designer. The Create dynamic shortcut menus example in the Visual FoxPro 5.0 Solutions sample illustrates creating a shortcut menu driven from an array. Because it is data-driven, it is more easily configurable at run time, and the strategy works in both Visual FoxPro 3.0 and 5.0.
In order to run the following code in Visual FoxPro 3.0, you need to remove the SHORTCUT
keyword from the DEFINE POPUP command. The SHORTCUT keyword was added in Visual FoxPro 5.0 to provide standard Windows 95 shortcut menu behavior.
The RightClick event of the example form contains
the following code. The oMenuShortcut object referenced in this code is based on the menulib class in the Visual FoxPro \SAMPLES\CLASSES\UTILITY.VCX library.
&LOCAL laMenu[5]
&laMenu=&&
&laMenu[1]=&\&Center&
&laMenu[2]=&\&Font...&
&laMenu[3]=&\&Minimize&
&laMenu[4]=&\-&
&laMenu[5]=&E\&xit&THISFORM.oMenuShortcut.ShowMenu(@laMenu)
&&CASE BAR()=1
& &&THISFORM.AutoCenter=.T.
&&CASE BAR()=2
& &&THISFORM.SetFont && a user-defined method
&&CASE BAR()=3
& &&THISFORM.WindowState=1
&&CASE BAR()=5
& & &THISFORM.Release
The ShowMenu method of the oMenuShortcut object (based on the menulib class) contains the following code:
&LPARAMETERS taMenu,tcOnSelection
&LOCAL lcOnSelection,lnMenuCount,lnCount,llDoubleArray
&LOCAL lcMenuItem,lcMenuSelection
&EXTERNAL ARRAY taMenu
&IF PARAMETERS()=0 OR TYPE(&taMenu&)#&C&
&&RETURN .F.
&lnMenuCount=0
&lnMenuCount=ALEN(taMenu,1)
&IF lnMenuCount=0
&&RETURN .F.
&llDoubleArray=(ALEN(taMenu,2)&0)
&ACTIVATE SCREEN
&DEACTIVATE POPUP _popShortcutMenu
&DEFINE POPUP _popShortcutM
& &&FROM MROW(),MCOL() ;
& &&MARGIN ;
& &&RELATIVE ;
& &&SHORTCUT
&FOR lnCount = 1 TO lnMenuCount
&&lcMenuItem=IIF(llDoubleArray,taMenu[lnCount,1],taMenu[lnCount])
&&DEFINE BAR lnCount OF _popShortcutMenu PROMPT (lcMenuItem)
&ON SELECTION POPUP _popShortcutMenu DEACTIVATE POPUP _popShortcutMenu
&ACTIVATE POPUP _popShortcutMenu
&RELEASE POPUP _popShortcutMenu
&IF BAR()=0
&&RETURN .F.
&IF llDoubleArray
&&lcMenuSelection=taMenu[BAR(),2]
&&IF NOT EMPTY(lcMenuSelection) AND TYPE(&lcMenuSelection&)==&C&
& & &lcOnSelection=ALLTRIM(lcMenuSelection)
&&IF EMPTY(lcOnSelection)
& &&lcOnSelection=ALLTRIM(IIF(EMPTY(tcOnSelection),&&,tcOnSelection))
&&lcOnSelection=ALLTRIM(IIF(EMPTY(tcOnSelection),&&,tcOnSelection))
&IF EMPTY(lcOnSelection)
& &RETURN .F.
&&lcOnSelection
When the user right-clicks the form, the shortcut menu is defined from the array and displayed for user choice.
Menus are not objects in Visual FoxPro, but you can write wrapper classes around Visual FoxPro menu definition code to provide the familiar object development interface. There are several implementations of menu classes available. For example, the Visual FoxPro 3 CodeBook by Yair Alan Griver (Sybex, 1995) provides source code and documentation for a robust implementation of menu classes. Other menu classes are available for downloading from the Internet. The following is a very simple example of creating and using menu classes.
&PUSH MENU _MSYSMENU
&bar1 = CREATEOBJECT(&mBar&, &Test1&, &bar1&, &MESSAGEBOX(PROMPT())&)
&bar2 = CREATEOBJECT(&mBar&, &Test2&, &bar2&, &MESSAGEBOX(PROMPT())&)
&bar3 = CREATEOBJECT(&mBar&, &Done&, &bar3&, &POP MENU _MSYSMENU&)
&pop1 = CREATEOBJECT(&mPop&, &pop1&)
&pop1.AddBar(bar1)
&pop1.AddBar(bar2)
&pop1.AddBar(bar3)pad1 = CREATEOBJECT(&mPad&, &Pad1&,
&&No message&)
&pad1.SetPopup(pop1)
&* Class Definitions
&DEFINE CLASS mpad AS CUSTOM
& &PadName = &&
& &Message = &&
& &&PROCEDURE Init(cName, cMessage)
& && &THIS.PadName = cName
& & & &THIS.Message = cMessage
& & & &DEFINE PAD (cName) OF _MSYSMENU ;
& & & & &PROMPT cName MESSAGE cMessage
& & & ENDPROC
& & PROCEDURE SetPopup(oPopup)
& & & cName = THIS.PadName
& & & cPopup = oPopup.PopName
& & & ON PAD (cName) OF _MSYSMENU ACTIVATE POPUP (cPopup)
& & ENDPROC
& ENDDEFINE
& DEFINE CLASS mpop AS CUSTOM
& & PopName = &&
& & BarCount = 0
& & PROCEDURE Init(cName)
THIS.PopName = cName
DEFINE POPUP (cName) MARGIN
& & PROCEDURE AddBar(oBar)
cName = THIS.PopName
& & & & cAction = oBar.Action
& & & & THIS.BarCount = THIS.BarCount + 1
& & & & DEFINE BAR THIS.BarCount OF (cName) ;
& & & & & PROMPT oBar.P
& & & & & MESSAGE oBar.Message
ON SELECTION BAR THIS.BarCount OF (cName) &cAction
& & ENDPROC
& ENDDEFINE
& DEFINE CLASS mBar AS CUSTOM
& & Prompt = &&
& & Message = &&
& & Action = &&
& & PROCEDURE Init(cPrompt, cMessage, cAction)
& & & THIS.Prompt = cPrompt
& & & THIS.Message = cMessage
& & & THIS.Action = cAction
& & ENDPROC
& ENDDEFINE
The more data-driven your menu system is, the more flexible and configurable it is at run time. You can create your own procedures or classes that manage reading data from one or more tables and construct a menu system based on the values stored in the table. The following example illustrates designing a completely data-driven menu system.
In this example, there is one table that stores menu system information and separate tables for each menu popup store
bar information. The table that stores the menu system information is Menubar, defined below.
&CREATE TABLE MENUBAR ;
& & & &(NPAD C(15), ;
& & & &PROMPT C(25), ;
& & & &MESSAGE M, ;
& & & &POPNAME C(15), ;
& & & &DBFNAME C(10))
The following are some possible values for a couple
of records in the menubar table:
Open, Close, Save, etc.
Cut, Copy, Paste, Find, etc.
This example requires a separate table for each menu, listing all the items and what to do when the item is chosen. For example, you could have a table with the following structure:
&CREATE TABLE FILE ;
& & & & (NBAR C(15), ;
& & & &PROMPT C(25), ;
& & & &MESSAGE M, ;
& & & &SKIPFOR M, ;
& & & &HOTKEY C(8), ;
& & & &ACTION M)
The following are some possible values for a couple of records in the File table:
New Customer
DO NewCustomer
Open a form
DO FORM GETFILE('scx')
When you have the data ready, you can run a program or call a method that reads the values and creates the menus. For example, the following code reads through the Menubar table and creates menus based on the Menubar data.
&SELECT MenuBar
& & & &DEFINE PAD (ALLTRIM(npad)) OF _MSYSMENU ;
& & & & & &PROMPT ALLTRIM(Prompt) MESSAGE ALLTRIM(Message)
& & & &DO DefinePop WITH popname, npad, dbfname
The DefinePop procedure creates the popup, associates it with the appropriate pad and defines all the bars.
&PROCEDURE DefinePop
&LPARAMETERS cPopup, cPadName,
& cPopup = ALLTRIM(cPopup)
&cPadName = ALLTRIM(cPadName)
&cTable = ALLTRIM(cTable)
&cOldAlias = ALIAS()
&DEFINE POPUP (cPopup) RELATIVE MARGIN
&ON PAD (cPadName) OF _MSYSMENU
&ACTIVATE POPUP (cPopup)
LOCAL cAction, cPad, cKey, cDefineString
IF !USED(cTable)
USE (cTable) IN 0
SELECT (cTable)
cAction = ALLTRIM(action)
cBar = ALLTRIM(nBar)
cKey = ALLTRIM(hotkey)
cSkipFor = ALLTRIM(skipfor)
cDefineString = &DEFINE BAR & + cBar + ;
& OF & + cPopup + ;
& PROMPT '& + ALLTRIM(prompt) + &'&
IF !EMPTY(cKey) cDefineString = cDefineString + & KEY & + cKey
IF !EMPTY(cSkipFor)
cDefineString = cDefineString + & SKIP FOR &
+ cSkipFor
&cDefineString
ON SELECTION BAR &cBar
of (cPopup) &cAction
IF !EMPTY(cOldAlias)
SELECT (cOldAlias)
If you want to implement a data-driven menu engine like this,
the best way to do it is to create a form class with methods that
manage the menu definition code, then create a form based on the
form class and set the DataSession property of the form to 2 -
Private Data Session. When you run the form in your application,
use the NOSHOW keyword so that the form is created but not displayed.
For example: DO FORM menuform NOSHOW. Then call the methods on the form to manage your menu system.
Acknowledgments
Randy Brown, Tom Cooper, and Ken Levy reviewed this
paper, pointing out holes and suggesting changes. Liz Ruest edited
the paper.
& 1997 Microsoft Corporation. All rights reserved.