brian@natinst.UUCP (Brian H. Powell) (04/14/88)
We're working on a program with some custom menus. (Actually, some
are custom, some are normal.)
In Inside Mac Volume I, it says "For menus of your own definition, you
may set up the data defining the menu items any way you like..." That's
what we've done. Our MENU resource data is substantially different (after
the first few standard header bytes) from a regular MENU.
If you look at one of the custom MENUs with ResEdit, you get lots of
gibberish. In particular, the standard MENU template shows that an "N"
appears in the MenuKey equivalent box. Herein lies the problem.
We have a situation where "New" (normally cmd-N) is grayed out.
Further down the menu bar is our custom menu. MenuKey returns the custom
menu's ID if "New" is grayed out.
The bug is that MenuKey doesn't notice that we have specified a
different menu defproc for that menu, so it looks at our custom data for
a menu key equivalent. There just happens to be an "N" in that location, so
it decides that that's what we want.
This does strange things to our program.
Ideally, there should be another message that can be sent to an MDEF that
can figure out Menu Keys.
An even worse bug in MenuKey appeared because of this. The custom
menu I mentioned above is really a hierarchical menu that's one step off
the top-level menus. (i.e., if you click on the menu bar, you won't see our
custom menu, but if you go down and select the proper menu item, it'll appear
(hierarchically) to the side.) There are situations where both "New" and
the menu parenting the custom menu are grayed out. MenuKey still returns
the ID of the custom menu.
This is completely different from using the mouse; if you click on the
grayed out parent of a hierarchical menu, you don't see the child menu. It
doesn't seem like MenuKey should be able to go any further past the grayed
out parent either.
Does this mean that if you want to completely disable a hierarchical
menu, you not only have to disable the parent, but you have to disable
all of the children as well?
Brian H. Powell National Instruments Corp.
brian@natinst.uucp 12109 Technology Blvd.
ut-sally!im4u!natinst!brian Austin, Texas 78727-6204
(512) 250-9119 x832
or if that doesn't work, you can use brian@sally.utexas.edu.oster@dewey.soe.berkeley.edu (David Phillip Oster) (04/14/88)
I hope Apple leaves things mostly the way they are. I've been writing
custom menu definition routines for a long time, and I always leave the
standard data structures specifically so I can use all the standard
routines like SetCheckItem() in my custom menus. It would break a lot of
existing programs if Apple suddenly stopped scanning my menus just because
they have a custom MDEF.
--- David Phillip Oster --When you asked me to live in sin with you
Arpa: oster@dewey.soe.berkeley.edu --I didn't know you meant sloth.
Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edujoachim@iravcl.ira.uka.de (04/17/88)
In article <330@natinst.UUCP>, brian@natinst.UUCP (Brian H. Powell) writes: > the first few standard header bytes) from a regular MENU. > If you look at one of the custom MENUs with ResEdit, you get lots of > gibberish. In particular, the standard MENU template shows that an N > appears in the MenuKey equivalent box. Herein lies the problem. > We have a situation where NEW (normally cmd-N) is grayed out. > Further down the menu bar is our custom menu. MenuKey returns the custom > menu's ID if NEW is grayed out. Add a filler of two zero bytes after the standard components of the record. This will stop MenuKey from interpreting the rest of the record. It also stops ResEdit from displaying garbage, but it does not stop it from truncating the menu :-( Joachim Lindenberg, University of Karlsruhe Federal Republic of Germany - West Germany.