kearns@tom.columbia.edu.UUCP (02/10/87)
I noticed that the new LSC has a pop up menu when you option-click in the title bar of a window; Also the choose file dialog in the hfs has a pop up window to change directories. I was thinking how nice it would be to be able to do this in general. It seems that the thing to do would be to make use of the MDEFs that already are around. According to the specification for custom MDEFs these take as an argument the rectangle to draw the menu in, so it seems quite plausible. I tried to do it but was unsuccessfull. How could one call an MDEF by oneself? More generally, how does one call a code resource? None of this is documented in Inside Mac, volumes 1-3. Please mail to me. I will summarize for the net. -steve
joel@gould9.UUCP (02/11/87)
See 'Try Pop-Up Menus!', December 1985 MacTutor (available from
MacTutor, $4, if you don't have it.) Mike Schuster's stuff is
usually very clever and very good.
--
Joel West MCI Mail: 282-8879
Western Software Technology, POB 2733, Vista, CA 92083
{cbosgd, ihnp4, pyramid, sdcsvax, ucla-cs} !gould9!joel
joel%gould9.uucp@NOSC.ARPAfrankb@crash.UUCP (02/13/87)
> I noticed that the new LSC has a pop up menu when you option-click in > the title bar of a window... I was thinking how nice it would be to be > able to do this in general. Pop-up menus are okay in some circumstances, and even desirable for some uses, but not in title bars of window. To wit: You should not change the shape of the zoom-window box or change the interpretation of clicking on the zoom- window box. You should add no other elements to the title bar. Except in the zoom-window box and in the close box, clicking within the title bar should have no effect. -- Inside Macintosh, Volume IV, page 9 Lightspeed C is great, but this one went against the rules. ___________________________________________________________________________ Frank Boosman | "Even more important, Silicon Beach Software | [computing] is fun, and ARPA/UUCP: {sdcsvax, nosc}!crash!pnet01!frankb | therefore intrinsically MCI Mail: fboosman | worth doing." -- Alan Kay, BIX: frankb | Scientific American
dtw@f.gp.cs.cmu.edu.UUCP (02/15/87)
Except in the zoom-window box and in the close box, clicking within the title bar should have no effect. -- Inside Macintosh, Volume IV, page 9 The person who wrote the above was not being very careful. Clicking in the title bar, outside the close and zoom areas, is supposed to setup the window for dragging. So it is supposed to have some effect, and the effect it normally has is even visible. Read the first paragraph on page I-47 in Inside Macintosh. It is not clear from the User Interface Guidelines that LSC is going against the rules with its pop-up menus. They are not activated just by clicking in the title bar. They are activated by clicking there with the Option key held down. Where in the Guidelines is that forbidden? Duane (dtw@k.cs.cmu.edu)
earleh@dartvax.UUCP (02/15/87)
In article <787@crash.CTS.COM>, frankb@pnet01.CTS.COM (Frank Boosman) writes: > > I noticed that the new LSC has a pop up menu when you option-click in > > the title bar of a window... I was thinking how nice it would be to be > > able to do this in general. > > Pop-up menus are okay in some circumstances, and even desirable for some > uses, but not in title bars of window. To wit: > > You should not change the shape of the zoom-window box > or change the interpretation of clicking on the zoom- > window box. You should add no other elements to the > title bar. Except in the zoom-window box and in the > close box, clicking within the title bar should have no > effect. > > -- Inside Macintosh, Volume IV, page 9 > > Lightspeed C is great, but this one went against the rules. > Frank is exactly right here. Everyone knows that when Moses went up into the mountain, he brought back engraved in stone a copy of Inside Macintosh, Volumes I through IV. Haven't we learned from history (Spanish Inquisition, centuries of religious war, the "big/little endian" controversy) that authoritative statements such as those made in IM (bless its name!) are never, EVER to be questioned by ordinary mortals such as ourselves. We have only purchased the Macintosh, we have only parted with our hard earned money, the fruits of our sweat, we have not nearly as much merit as the sainted authors of Inside Macintosh. Who dares to question the sanctity of the title bar? Banish them to ever-lasting torment! They have sinned! Let all who pass them by look the other way! Worse yet, the authors of Lightspeed C have been guilty of the sin of PRIDE. They have attempted to demonstrate more programming expertise than the sainted ones, the authors of the the operating system. They have misused the sacred ROM! They have broken the sacred covenant: THOU SHALT NOT DO ANYTHING CREATIVE BEFORE IT IS DONE IN CUPERTINO. Bring on the lashes, the rack, the Iron Maiden. Let those who have offended pay for their sins in this life, to serve as an example to that fool who would contemplate using the Macintosh for any heritical innovation. Furthermore, for its role in this travesty, let the programming language known as "C" be forevermore banished to the outer darkness. We all know that it was the sin of using "C" that led to this horrible blasphemy. Have I stated your position correctly, Frank?
clubmac@runx.UUCP (02/16/87)
In article <1025@gould9.UUCP> joel@gould9.UUCP (Joel West) writes: >See 'Try Pop-Up Menus!', December 1985 MacTutor (available from >MacTutor, $4, if you don't have it.) Mike Schuster's stuff is >usually very clever and very good. Has anyone tried getting Mike's pop-up menus working in Lightspeed C? I have tried -> no luck so far. Any help would be appreciated. Jason Haines Club Mac - The Sydney University Macintosh Society Snail: Box 213, Holme Building, Sydney University, NSW, 2006, Australia ACSnet: clubmac@runx ARPA: clubmac%runx.oz@seismo.css.gov UUCP: {enea,hplabs,mcvax,prlb2,seismo,ubc-vision,ukc}!munnari!runx.oz!clubmac
julian@riacs.UUCP (02/18/87)
In article <787@crash.CTS.COM> frankb@pnet01.CTS.COM (Frank Boosman) writes: > ... > title bar. Except in the zoom-window box and in the > close box, clicking within the title bar should have no > effect. > -- Inside Macintosh, Volume IV, page 9 > Lightspeed C is great, but this one went against the rules. Microsoft has been going against the rules for a while. If you double click the title bar in MSBASIC, the window expands; double click again and it returns to original size. I imagine there are other companies who skipped this paragraph of IM. -- Who audits the IRS? Julian "a tribble took it" Gomez julian@riacs.edu *** {...decvax!}ames!riacs!julian
frankb@crash.UUCP (02/19/87)
> Frank is exactly right here. Everyone knows that when Moses > went up into the mountain, he brought back engraved in stone a > copy of Inside Macintosh, Volumes I through IV. Haven't we > learned from history (Spanish Inquisition, centuries of religious > war, the "big/little endian" controversy) that authoritative > statements such as those made in IM (bless its name!) are never, > EVER to be questioned by ordinary mortals such as ourselves. We > have only purchased the Macintosh, we have only parted with our > hard earned money, the fruits of our sweat, we have not nearly as > much merit as the sainted authors of Inside Macintosh. Who dares > to question the sanctity of the title bar? Banish them to > ever-lasting torment! They have sinned! Let all who pass them by > look the other way! > > Worse yet, the authors of Lightspeed C have been guilty of > the sin of PRIDE. They have attempted to demonstrate more > programming expertise than the sainted ones, the authors of the > the operating system. They have misused the sacred ROM! They > have broken the sacred covenant: THOU SHALT NOT DO ANYTHING > CREATIVE BEFORE IT IS DONE IN CUPERTINO. Bring on the lashes, the > rack, the Iron Maiden. Let those who have offended pay for their > sins in this life, to serve as an example to that fool who would > contemplate using the Macintosh for any heritical innovation. > Furthermore, for its role in this travesty, let the programming > language known as "C" be forevermore banished to the outer > darkness. We all know that it was the sin of using "C" that led > to this horrible blasphemy. > > Have I stated your position correctly, Frank? In a word--and an emphatic word at that--no. First, "let me make myself perfectly clear" on a couple of issues. I own and use Lightspeed C. I think C is probably the best all-around language these days, and Lightspeed C is, as far as I've seen, the best implementation of it on any computer at any price. Furthermore, I hold the people at Think in very high regard. They're doing some of the most innovative software on the Macintosh these days. I do not mean to reserve all rights to enhance the Macintosh interface to the folks at Cupertino. Developers can and should experiment with the Macintosh interface to try and coax more simplicity and power out of it. But, as has been proved before, those who specifically violate Apple warnings *not* to do something (or to do something only a certain way) are in for trouble. Now I for the life of me can't imagine a future compatibility problem caused by option-clicking on the title bar of a window. But you never know. Sillier things have caused problems with new machines. Something to keep in mind when contemplating changes to the Macintosh interface is the fact that the deep similarity between applications on the Macintosh is the reason it is so easy to use. This, folks, is why the Macintosh is so popular these days. No other consumer computer has such a uniformity of interfaces across applications. That's why the Macintosh is such a pleasure to use. With that in mind, though, it must be acknowledged that the Macintosh interface is not and should not become a static unchanging entity. As we come up with new uses for the Macintosh, we will need to develop new ways to let the user communicate to the machine. This is not a process which Apple Computer, Inc. should undertake alone, and indeed, they do not. It is up to developers to encounter "brick walls" in the Macintosh interface, devise their own ways of overcoming them, and release their ideas to their users and see how they are received. If an idea is obvious enough and gains popularity--if it makes sense--it's a good bet that Apple will notice it and nod approvingly. Apple's first big "nod" is coming in the form of a revised set of Human Interface Guidelines due out soon which will address "power user" enhancements to the Macintosh interface. To a point, this is what Think did with their option-click strategy in Lightspeed C: they devised their own enhancement to the Macintosh interface. The only difference is that their enhancement specifically went against an Apple recommendation, rather than working around it. There are other places they could have placed the pop-up box, or other methods they could have tried. In short: The Macintosh interface is an important standard which developers must respect to the best of their abilities. It will, however, require revisions as needs change. As various developers try different revisions, it is Apple's responsibility to watch this process, choose the best and most necessary of the revisions and incorporate them into the official Macintosh user interface guidelines. Developers should, though, at nearly any cost and under nearly any circumstances, avoid making any changes to the Macintosh interface which specifically violate Apple recommendations. And developers should strive to ensure that their interface revisions are "in the spirit" of the original Macintosh interface. *That's* my position. ___________________________________________________________________________ Frank Boosman | "I'm always hoping that Silicon Beach Software | that you'll end this reign ARPA/UUCP: {sdcsvax, nosc}!crash!pnet01!frankb | / But it's my destiny to MCI Mail: fboosman | be the king of pain." -- BIX: frankb | Sting, King of Pain
ajg@cci632.UUCP (02/20/87)
In article <665@runx.OZ> clubmac@runx.OZ (PUT YOUR NAME HERE) writes: >In article <1025@gould9.UUCP> joel@gould9.UUCP (Joel West) writes: > >>See 'Try Pop-Up Menus!', December 1985 MacTutor (available from >>MacTutor, $4, if you don't have it.) Mike Schuster's stuff is >>usually very clever and very good. > >Has anyone tried getting Mike's pop-up menus working in Lightspeed C? >I have tried -> no luck so far. > >Any help would be appreciated. > >Jason Haines > I got the code listed in that issue of MacTutor to work with Lightspeed C. Althought I did the work in about 5 days more than three months ago while working for the University of Rochester in courseware development. I think there were some problems with the menu calls to place and draw the menu, and a problems with the code that selects the menu item when the cursor moves through the menu. There were also a few changes that had to be due to the difference between the way Lightspeed and Mac C pass points. I'll try to get the people there to post a copy of the sources to mod.mac.sources or mac.sources. I don't think they'll be a problems but I don't know if that code is copyrighted. If it is I'll get a copy and post the things you need to change. Tony Giaccone
clive@druhi.UUCP (02/21/87)
Frank, don't let this guy get you down. He's got wit, it was funny, he's got a point. But we know your heart's in the right place. Because SuperPaint is a really fine program. Thanks for that. Clive
akk2@ur-tut.UUCP (02/25/87)
In article <393@hydra.riacs.edu> julian@hydra.UUCP (Julian E. Gomez) writes: > >Microsoft has been going against the rules for a while. If you double >click the title bar in MSBASIC, the window expands; double click again >and it returns to original size. I imagine there are other companies >who skipped this paragraph of IM. This 'going against the rules' is useful when you are using some of the large screen monitors out there. Imagine resizing your windows to fit the large screens and then not being able to do anything with them on your small Mac screen unless you have the large screen handy at the same time. This being due to the fact that the window size info is saved when you save the document. -- ----------------------- Atul Kacker UUCP: ...seismo!rochester!ur-tut!akk2
munson@ernie.Berkeley.EDU.UUCP (02/25/87)
In article <393@hydra.riacs.edu> julian@hydra.UUCP (Julian E. Gomez) writes: >In article <787@crash.CTS.COM> frankb@pnet01.CTS.COM (Frank Boosman) writes: >> ... >> title bar. Except in the zoom-window box and in the >> close box, clicking within the title bar should have no >> effect. >> -- Inside Macintosh, Volume IV, page 9 >> Lightspeed C is great, but this one went against the rules. > > >Microsoft has been going against the rules for a while. If you double >click the title bar in MSBASIC, the window expands; double click again >and it returns to original size. I imagine there are other companies >who skipped this paragraph of IM. > > > Julian "a tribble took it" Gomez > julian@riacs.edu *** {...decvax!}ames!riacs!julian Since the rule appeared in volume four, it was not published until about the time of the Mac+. Microsoft came up with their solution long before zoom boxes existed (Word 1.05 and Excel also use the double click). I think zooming a window was probably a nifty feature that Apple missed when it designed the original interface. Ethan Munson munson@ernie.berkeley.edu
lsr@apple.UUCP (02/26/87)
In article <1046@ur-tut.UUCP> akk2@ur-tut.UUCP (Atul Kacker) writes: > >This 'going against the rules' is useful when you are using some of >the large screen monitors out there. Imagine resizing your windows to fit >the large screens and then not being able to do anything with them on your >small Mac screen unless you have the large screen handy at the same time. >This being due to the fact that the window size info is saved when you save >the document. > Actually, any application that saves the window size & position with the document, should check to see if the window fits the current screen when it is reopened. You need to make sure that some part of the window's title bar is visible and that the window is no larger than the screen size (or so). The zoom window feature is not a substitute for doing the right thing in the first place. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.CSNET
ranson@crcge1.UUCP (D. Ranson CNET) (07/20/87)
Anybody knows how to use the PopUpMenuSelect trap ($A80B) that comes
with System4.1 ? It looks like its interface is similar to that of
MenuSelect, except there is an extra parameter (menuID?). And how
should InsertMenu be used for a PopUp menu?
My best result so far has been to call PopUpMenuSelect without bombs,
but nothing pops up. And I haven't found any example of its use in
the System (StdFile has its own menu routines).
I have read and reread IM v5, where there are hints about support of
pop-up menus (including the trap name), but no "how to" info. Did any-
body get more info?
Daniel Ranson
...!seismo!mcvax!inria!crcge1!crcge2!ranson
or ...!seismo!mcvax!inria!cnetlu!ransonlsr@apple.UUCP (Larry Rosenstein) (07/21/87)
In article <2695@crcge1.UUCP> ranson@crcge1.UUCP (D. Ranson CNET) writes: > >Anybody knows how to use the PopUpMenuSelect trap ($A80B) that comes >with System4.1 ? It looks like its interface is similar to that of >MenuSelect, except there is an extra parameter (menuID?). And how >should InsertMenu be used for a PopUp menu? The only documentation I have seen has been a cryptic text file I pulled off of a file server here, and the MPW 2.0b1 interface files. I have gotten it to work, however, so I can pass along some info. First the interface to the trap looks like this: FUNCTION PopupMenuSelect(theMenu: MenuHandle; left, top, item: INTEGER): LONGINT; The return result is the same as with MenuSelect. The item parameter is the number of the menu item whose topLeft corner should appear at the specified location. The left and top parameters are given in global coordinates. The new menu defproc will ensure that the popup menu is entirely on the screen. (It will scroll the menu if necessary to bring the selected item at the desired point.) The menu being popped up should be installed in the same way as a hierarchical menu. In other words, you pass -1 as the beforeID to InsertMenu. The other tricky thing to watch out for is determining whether you can use popup menus. The information I have says to do the following: 1. Make sure you have 128K ROMs. 2. If you have 128K ROMs, you next have to see if the new Menu Manager has been initialized by checking if the longword at location $B5C contains $FFFFFFFF. If so, then the new Menu Manager is not installed. (According to the memo, this is necessary because Radius patches out much of the Menu Manager.) 3. Check to see if the GetItemCmd trap ($A84E) is implemented by getting the trap address for it, and comparing that to the trap address for the $9F trap (which is always unimplemented). Remember that this is a Toolbox trap (not an OS trap); see Inside Mac volume 4 for more info. (It seems to me that you could check for the existence of PopupMenuSelect as well.) 4 Check to see if you have the latest MDEF resource. The code for the new Menu Manager is installed by patches at boot time, and therefore does not depend on the current System file. Popup menus, however, require the cooperation of the MDEF, so if someone switch launches to an old System, the old MDEF won't work. You can check the MDEF version by looking at the word at offset 10 (decimal) into the MDEF resource. If it is 10 (decimal) or greater than you have an appropriate resource. According to the Human Interface Note #5, popup menus should be used only for lists of related items and not for commands. For example, if you wanted to set the baud rate for a port, you could allow the users to select from among the available rates. The existence of a popup should be signalled by a 1-pixel drop shadow drawn around the current value; popups should never be invisible. There should also be a label for the value. When the user clicks on the current value, you should invert the label and popup the menu with the current selection under the mouse. (That way if the user immediately releases the button, nothing changes.) PopupMenuSelect only manages the menu itself. You are responsible for inverting the "title" of the popup. I believe that this information is accurate, since it seems to work for me. I have not, however, seen this written up in a draft of Inside Macintosh volume 5, so some of the details might be wrong. (The memo I mentioned was written before the new Menu Manager was finalized, so it doesn't quite correspond with reality.) -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
ranson@crcge1.UUCP (D. Ranson CNET) (07/23/87)
Thanks to infos from Larry Rosenstein, I have managed to make PopUp menus work. On the way, I think I have found a bug in this new menu manager. The problem is with hierarchical popup menus. I guess Apple will strongly discourage the use of submenus in popup menus, but it does work, except a minor redraw bug. This is easy to reproduce: - Open the popup menu. - Open the submenu. - Move into the submenu. - Move back to the submenu title (ie in the first menu) WITHOUT passing over any other item. - When you do this, the submenu title is unhighlighted. This does not happen in "regular" hierarchical menus. I guess it is related to the fact that popup menus are not supposed to have a title. Daniel Ranson ...!seismo!mcvax!inria!crcge1!crcge2!ranson
mendozag@pur-ee.UUCP (Grado) (07/28/87)
Has anybody used the function TrackPropUp from INFO-MAC developed
by Steve Brecher? (MPW-TRACKPOPUP-SAMPLECODE.HQX).
It requires a bunch of Pascal-ish macros he did not include in the
distribution file and which are "Loaded" from a symbol table called
SBMacs.d (Steve Brechers Macros I presume). Does anybody have a copy
of those macros that can be emailed to me? I would appreciate it very much.
Thanks in advance,
-vmg-
mendozag@ecn.purdue.edu
pur-ee!mendozaglsr@apple.UUCP (Larry Rosenstein) (07/29/87)
In article <1340@apple.UUCP> I wrote: > >First the interface to the trap looks like this: > > FUNCTION PopupMenuSelect(theMenu: MenuHandle; > left, top, item: INTEGER): LONGINT; I was wrong about the interface to the trap. I got the left and top parameters switched. The top parameter comes first. The correct parameters are in the MPW interface files. The reason why I was confused is that I was writing a custom menu defproc. In order to support popup menus, custom defprocs have to respond to a new message in order to tell the Menu Manager where to place the popup. It turns out that the hitPt, which is passed to the defproc, is interpreted differently for this message; the h & v coordinates are switched. Naturally, this made the menu appear in the wrong place, but switching the parameters to PopupMenuSelect made it appear in the correct place. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com