rae@geac.uucp (Reid Ellis) (03/07/89)
My friends showed me an Amiga when it first came out. Right away, I wanted two things for my Mac. The first was hierarchical menus. I was part way through writing my own MDEF to do this when new system software came out and there it was. Yay! The second thing was the ability to select an item in a menu without "letting go" of the menu. For example, being able to select the baud rate, parity and data bits from a serial settings menu without having to select the same menu [assuming they're all in the same menu] over and over and over. So now I'm thinking, "Hey, how about selecting an item if you hit Enter while that item is highlighted?" Ok, so now I have an idea. The next thing to resolve is its scope. Is it possible to do this only from an MDEF? If I return from an MDEF with the menu still drawn on the screen, will the application immediately get another mouseDown inMenuBar event? Or will I need to write my own MBAR def as well? Reid --- rae@geac.uucp (Reid Ellis) 176 Brookbanks Dr, Don Mills ON, Canada, M3A 2T5, +1 416 446-1644 Copyright 1989 Reid Ellis; you may redistribute only if your recipients may.
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (03/08/89)
In article <3749@geaclib.UUCP> rae@geac.uucp (Reid Ellis) writes: > >So now I'm thinking, "Hey, how about selecting an item if you hit >Enter while that item is highlighted?" Ok, so now I have an >idea. The next thing to resolve is its scope. Is it possible to >do this only from an MDEF? If I return from an MDEF with the menu >still drawn on the screen, will the application immediately get >another mouseDown inMenuBar event? Or will I need to write my own >MBAR def as well? How about emulating the extended selection idea by using the shift key to keep the menu down until you have made your selections? As to how, you will probably have to patch MenuSelect since this routine (or a routine it calls) is responsible for calling the MDEF and tracking the mouse. These things would need to happen in your patch: 1) you will have to check to see if the shift key is down. If not yor patch should emulate the real MenuSelect exactly. 2) If the shift key is down, call the (standard) MDEF with the draw message. (don't forget to save the bits behind the menu). I would use the check mark method of marking selected items rather than highlighting because then you should be able use Apple's MDEF and not write your own. 3) Once the selections are made and the shift key is released you should restore the bits you saved in 2). 4) the tricky part: You really are trying to fake the application into thinking you made many separate menu selections. If only one item is selected, just return that items id and menu number. If there are more items selected, you still return the first item but also post a mouse down event in the menu bar. This will trick the application into calling MenuSelect again. Your MenuSelect returns the next item and posts another event if there's a pending item. The bottom line is: I don't think you need to write a custom MDEF or an MBDF to do what you want. I seem to remember somthing on the net about Apple not wanting anyone to go about writing any custom MBDFs yet anyway. ______________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar (UUCP)
Greg_Mark_Finnegan@cup.portal.com (03/10/89)
I've seen an interesting variation on this MDEF (in Jonathan Draw, I believe). It used only check-items and what you do is pull down the menu and 'gesture' to the left of the item you want to check (i.e. quickly jerk the mouse to the far left side of the item, where the check mark will appear, and low and behold, there it is). Thought it was an interesting effect. Greg.
DFJOHN01@ULKYVX.BITNET (GMAIL_FLAG_PERSONAL_NAME) (03/14/89)
I have given a lot of thought to your MDEF idea but after checking out Apple's Human Interface Guidelines I'm afraid that it may not be so great an idea. The reason is that if someone needs 'multiple selections' then it is probably time to implement a dialog box with appropriate check and radio buttons, edit text fields and popup menus. This gives the user a visual reference for the selections made and data entered. A good example of this is PageMaker. Under the TYPE Menu are hierarchical menus FONT, SIZE, LEADING, and TYPE STYLE. These set the selected text (or the text about to be keyed in) to those settings. But, instead of having to set or change these settings by going to each menu and selecting the desired choice, another menu item under the TYPE Menu is TYPE SPECS. Selecting it brings up a dialog box which allows the user to set the font, size, leading and type style. So, in this case, the user has a choice. Also, the user can 'type ahead' and have edit text fields filled in followed by a return key before the dialog box has a chance to appear on the screen. So, I guess I would have to see a MDEF such as you describe in action before I could personally rule it good or bad. I hope that the above helps from a part-time programmer and full-time user. David F. Johnson Typesetter II Student Printing Services Junior Houchens Bldg Engineering Math and Computer Science University of Louisville Speed Scientific School
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (03/16/89)
In article <8903140439.AA21958@jade.berkeley.edu> DFJOHN01@ULKYVX.BITNET (GMAIL_FLAG_PERSONAL_NAME) writes: >I have given a lot of thought to your MDEF idea but after checking out Apple's >Human Interface Guidelines I'm afraid that it may not be so great an idea. The >reason is that if someone needs 'multiple selections' then it is probably >time to implement a dialog box with appropriate check and radio buttons, edit >text fields and popup menus. This gives the user a visual reference for the >selections made and data entered. I think the motivation for this MDEF idea was to alter the behavior of an existing application. It is much easier to paste in a new MDEF (or patch the MenuSelect trap as I suggested) than it is to convert the menu to a dialog box. I do agree that multiple selections would be better implemented as a dialog box. ______________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) | {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)