⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 wpw_wapi_menu_95.html

📁 VC programing
💻 HTML
字号:
<HTML>

<HR><A NAME=WINAPI_MENU_DISABLE>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Disable Menu item</H4><PRE>

According to the docs for AppendMenu():
   MF_DISABLED  "disables the menu item so that it cannot be selected,
                        but does not gray it"
   MF_GRAYED    "disables the menu item so that it cannot be selected
                        and grays it"

I would use MF_GRAYED all of the time, because it indicates that the item
is selectable (just not right now).  At least the user knows it is
invalid at the present time.

But I can't think of a reason to use MF_DISABLED.  It would give the
appearance that it was selectable (i.e. no different than MF_ENABLED),
but it could not be selected, no matter how the user might try.  This seems
rather silly to me - why present the illusion that it is a selectable item,
even though it can not be selected.

So why would I use MF_DISABLED?
-- 
John A. Grant                                           jagrant@emr1.emr.ca
Airborne Geophysics
Geological Survey of Canada, Ottawa
<HR>
On Sun, 18 Jun 1995 02:03:39 GMT, jagrant@emr1.emr.ca (John Grant) said in article <DACJ24.K36@emr1.emr.ca>:
>According to the docs for AppendMenu():
>   MF_DISABLED "disables the menu item so that it cannot be selected,
>                       but does not gray it"
>   MF_GRAYED   "disables the menu item so that it cannot be selected
>                       and grays it"
>
>I would use MF_GRAYED all of the time, because it indicates that the item
>is selectable (just not right now).  At least the user knows it is
>invalid at the present time.
>
>But I can't think of a reason to use MF_DISABLED.  It would give the
>appearance that it was selectable (i.e. no different than MF_ENABLED),
>but it could not be selected, no matter how the user might try.  This seems
>rather silly to me - why present the illusion that it is a selectable item,
>even though it can not be selected.
>
>So why would I use MF_DISABLED?

You might want to do something like use a menu item as a heading for a 
group of items in the menu.  Or, as a concrete example, consider a 
top-level menu item (on the menu bar) that displays some information.  For 
instance, the "Cards Left" display in FreeCell.


--
Robert Mashlan             R2M Software Company           Programmer for Hire
mailto:rmashlan@r2m.com    http://www.csn.net/~rmashlan     PGP key available
Resources for Windows Developers    -     http://www.csn.net/~rmashlan/windev
Windows Developers FAQ    -    http://www.csn.net/~rmashlan/win-developer-FAQ

<HR>
In article <2fe3be3e@r2m.com> rmashlan@r2m.com (Robert Mashlan) writes:
>On Sun, 18 Jun 1995 02:03:39 GMT, jagrant@emr1.emr.ca (John Grant) said in article <DACJ24.K36@emr1.emr.ca>:
>>According to the docs for AppendMenu():
>>   MF_DISABLED        "disables the menu item so that it cannot be selected,
>>                      but does not gray it"
>>   MF_GRAYED  "disables the menu item so that it cannot be selected
>>                      and grays it"
>>
>>I would use MF_GRAYED all of the time, because it indicates that the item
>>is selectable (just not right now).  At least the user knows it is
>>invalid at the present time.
>>
>>But I can't think of a reason to use MF_DISABLED.  It would give the
>>appearance that it was selectable (i.e. no different than MF_ENABLED),
>>but it could not be selected, no matter how the user might try.  This seems
>>rather silly to me - why present the illusion that it is a selectable item,
>>even though it can not be selected.
>>
>>So why would I use MF_DISABLED?
>
>You might want to do something like use a menu item as a heading for a 
>group of items in the menu.  Or, as a concrete example, consider a 
        Ok, but isn't it misleading to have it look like it is selectable?
        Perhaps in that case it really needs MF_SEPARATOR underneath it
        to reinforce the idea that it is just a heading and is therefore
        not selectable.

>top-level menu item (on the menu bar) that displays some information.  For 
>instance, the "Cards Left" display in FreeCell.
        (never noticed that one before...)
-- 
John A. Grant                                           jagrant@emr1.emr.ca
Airborne Geophysics
Geological Survey of Canada, Ottawa
</PRE>



<HR><A NAME=WINAPI_MENU_POPUP_DISTROY>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Distroy Popup menu</H4><PRE>
I am dynamically creating a somewhat complex menu tree at runtime, with
several CreateMenu() & several CreatePopupMenu() underneath it.  There's
2-3 levels.  After it has been created, I attach it to a dialog box at
WM_INITDIALOG with SetMenu().

The docs for CreateMenu() & CreatePopupMenu() say:
        "if the menu is not assigned to a window, an application must
        free system resources associated with the menu before exiting"

Fair enough.  Does this mean as soon as I use SetMenu() to attach it to
my dialog box, I can forget about it and Windows will clean it up after
EndDialog() closes my dialog box?  Can I also forget about all of the
submenus in the menu tree? (i.e. those created with CreatePopupMenu)?
Somehow this seems all too easy.

Even if Windows calls DestroyMenu() for me, will it just do it for the
top-level menu that was attached with SetMenu() or is it smart enough to
follow the chain on down the line and call DestroyMenu() for all of the
subsequent popup menus created with CreatePopupMenu().
-- 
John A. Grant                                           jagrant@emr1.emr.ca
Airborne Geophysics
Geological Survey of Canada, Ottawa
<HR>
John Grant (jagrant@emr1.emr.ca) wrote:
: I am dynamically creating a somewhat complex menu tree at runtime, with
: several CreateMenu() & several CreatePopupMenu() underneath it.  There's
: 2-3 levels.  After it has been created, I attach it to a dialog box at
: WM_INITDIALOG with SetMenu().

: The docs for CreateMenu() & CreatePopupMenu() say:
:       "if the menu is not assigned to a window, an application must
:       free system resources associated with the menu before exiting"

: Fair enough.  Does this mean as soon as I use SetMenu() to attach it to
: my dialog box, I can forget about it and Windows will clean it up after
: EndDialog() closes my dialog box?  Can I also forget about all of the
: submenus in the menu tree? (i.e. those created with CreatePopupMenu)?
: Somehow this seems all too easy.

I understand your question, but I'm not sure I want to answer this
with yes or no.  However, why not just delete them after they're being
used.  If you have BoundsChecker, it will report you which resources
are not released when program is terminated.

: Even if Windows calls DestroyMenu() for me, will it just do it for the
: top-level menu that was attached with SetMenu() or is it smart enough to
: follow the chain on down the line and call DestroyMenu() for all of the
: subsequent popup menus created with CreatePopupMenu().
: -- 
: John A. Grant                                         jagrant@emr1.emr.ca
: Airborne Geophysics
: Geological Survey of Canada, Ottawa


     ________
  -=/ ____  /_  _____ ______  ___ __ Quang Ngo (quang@tiac.net)
 -=/ / __/ / / / / __` / __ \/ __` / IRC /nick RX7-turbo on #amiga & #linux
-=/ /__\  / /_/ / /_/ / / / / /_/ /  http://www.tiac.net/users/quang/
-=\____,\ \___,_\___,/_/ /_/\___,/   A3000/25 (AmigaOS 3.1) - P5/90 (linux)
         \________/        /____/    Software Developer
</PRE>


<HR><A NAME=WINAPI_MENU_POPUP_SUBMENU>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: adding items to popup-submenus</H4><PRE>
In article <omalley-2006951701330001@erdpc-7.umtri.umich.edu> omalley@umich.edu (Kevin O'Malley) writes:
>I would like to add menu items to a popup-submenus while a program is
>running. By popup-submenus I mean:
>
>Menu
>====
>|popup menu    >| |popup-submenu item 1 |
>                  |popup-submenu item 2 |
>                  |popup-submenu item n |
>
>How is this done?
        CreatePopupMenu() followed by AppendMenu() for each item.
        Then attach it by using AppendMenu or InsertMenu to a parent menu.
-- 
John A. Grant                                           jagrant@emr1.emr.ca
Airborne Geophysics
Geological Survey of Canada, Ottawa
</PRE>

<HR><A NAME=WINAPI_MENU_CHILD_WIN>
Return to <a href="wpw_wapi_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Menu problem associate with child windows</H4><PRE>
In article <3u63vt$ofg@news.cs.brandeis.edu>
           acg@cs.brandeis.edu "Andrew Goldish" writes:

>  Hi.  I am working on a program which has a chain of child windows (i.e. one
>window spawns a second window which spawns a third window + 2 siblings).  Each 
>of these windows has a menu associated with it.  The problem is that I 
>can't seem to get both menus and windows at the same time.  I've found that
>by rearranging the order of the icons in the project file (by changing
>dependencies), I can get the file to load up the menus on the windows 
>successfully but then to not display any child windows on the screen (click
>the button on the first window and the CreateWindow function returns 0).
>Rearrange them a bit further and I wind up with the menus not working 
>(the LoadMenu commands all return 0) but the windows are working perfectly
>(all generations, including one I WinExec'ed).  I can get on or the other but
>not both.  Any ideas?  How should the dependencies be set up? 
>
>  If this helps, the project consists of a resouce file which has just three
>menu definitions in it (and maybe an include file), a header file, a library,
>and a C program.  Right now, the four project files are siblings of each 
>other and I've got the menus working and the child windows not working.  
>Incidentally, the menu on the working window seems to be functioning normally:
>I can't test the others though.
>
>  One thing I tried is to put the .rc file in TWO places in the dependency 
>list: didn't work though.

Look more closely at the "CreateWindow" API and the problem will be
obvious. There is a SINGLE parameter in the function which specifies EITHER
the window's menu handle, OR the child ID of a child window - ie windows
with the "WS_CHILD" style cannot have a menu.

The solution is to use "WM_POPUP" rather than "WS_CHILD" windows.

Chris

-- 
--------------------------------------------------------------------------
| Chris Marriott, Warrington, UK      | Author of SkyMap v2 shareware    |
| chris@chrism.demon.co.uk            | astronomy program for Windows.   |
|      For more info, see http://www.winternet.com/~jasc/skymap.html     |
|      Author member of Association of Shareware Professionals (ASP)     |
--------------------------------------------------------------------------
 
</PRE> 

</HTML>

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -