Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!lll-lcc!styx!ames!ucbcad!ucbvax!jade!eris!mwm From: mwm@eris.UUCP Newsgroups: comp.sys.amiga Subject: Re: Menu bug Message-ID: <3072@jade.BERKELEY.EDU> Date: Tue, 7-Apr-87 03:59:26 EST Article-I.D.: jade.3072 Posted: Tue Apr 7 03:59:26 1987 Date-Received: Fri, 10-Apr-87 04:32:27 EST References: <609@puff.WISC.EDU> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) Organization: Missionaria Phonibalonica Lines: 43 Keywords: DPaint II or Intuition? In article <609@puff.WISC.EDU> beilke@puff.WISC.EDU (Matthew Beilke) writes: > Now that there are a reasonable amount of fonts available, I thought I >would play with them, so I put them all in fonts:, then I brought up >DPaint II, to look at them. However, in XXX by 200 mode the menu is longer >than the screen, and Amy doesn't like it (I am visted by my friend the >Guru). My question is: (1) Does DPaint II have a design flaw in that it >did not anticipate large menus, or (2) is there something inherently wrong >with intuition? If the answer is (1) I can live with just not having a >lot of fonts in fonts:, but if the answer is (2), are there any plans to >fix the problem? Please, are you listening C/A? Take a look at how the >Mac solves the problem. The problem is actually (1) (DPAINT bug), but some (2) is involved. The Intuition Menu system is _very_ unforgiving if the menus are "non-standard" in some way. For instance, if you have a menu with no entries, expect your Amiga to go off the deep end. Likewise, if your menu is longer than the screen, expect odd results (I got funny screen wraps with 1.1; I now code to avoid it, so haven't seen what it does for 1.2. For all I know, 1.2 doesn't die with empty menus.). However, any program dealing dynamic menu creation should check the menu to see if it's going to walk off the bottom of the screen, and wrap it to another column if it does. Likewise, it should check to see if the column is going to stick past the edge of the screen, and do something appropriate if that's the case. The "correct" solution for menus that stick past the end of the screen, as far as I'm concerned, is either a requestor instead of a menu, or a menu entry for paging the menu back and forth. But on a 640 x 200 screen, you get (roughly - your mileage will vary) 5 menus by 20 entries, or 100 entries. Having more files (or fonts, or whatever) than that is rare (Fish disk #13 being one of the few examples) so I punted, and just indicated that there was more.