6500stom@hub.UUCP (12/21/89)
> The beta documentation is indeed a major mess, but that's to be > expected. But what's the problem with the discussion of the pop-up > menu CDEF on pages 172-175? Granted, it should mention explicitly that > TrackControl causes the index of the selected item to be stashed in the > control value field, but that's fairly obvious. (Now I just hope that > really is how it works! This seems to be very strongly implied by the > comments about the minimum being set to one and the max being set to > the number of items....) This sounds very much like the popupmenu CDEF that I'm working on right now and maybe I'll introduce it because I should be done with v2.0 today. The main feature is that there is zero flickering if you use it non-abusively. It conforms almost exacly to the pictures in IM V and even has code to center itself within the CNTL bounds if you want. I found that it wasn't a good idea to have the max set to the number of items in the menu because then if you changed the menu dynamically you can't make the selected item greater than the previous number of items. If anyone is interested I could explain how I eradicated the flicker. / Josh Pritikin T Ignorance is bliss. \ | Internet: 6500stom@ucsbuxa.ucsb.edu | I must be in hell. | | AppleLink: Josh.P | My room is proof that entropi | \ GEnie: J.Pritikin ! exists. /
tim@hoptoad.uucp (Tim Maroney) (12/22/89)
In article <3379@hub.UUCP> 6500stom@hub.UUCP writes: >This sounds very much like the popupmenu CDEF that I'm working on >right now and maybe I'll introduce it because I should be done with >v2.0 today. The main feature is that there is zero flickering if you >use it non-abusively. I wanted to comment on this "abusiveness" issue when someone made it last week, but I'm doing it now instead. The claim is that pop-ups don't exhibit the itemless scrolling behavior as long as they're used correctly. I must disagree strongly. Most dialogs should be modeless and have drag bars. If you do this, there is no way to allow legitimate dragging while preventing the pop-up from being close to the bottom of the screen, creating this obnoxious behavior. Modeless dialogs are hardly "abusive"; if anything, modal dialogs are the abusive ones. This behavior is a bug in PopUpMenuSelect, not the fault of application programmers. >It conforms almost exacly to the pictures in >IM V and even has code to center itself within the CNTL bounds if you >want. You do realize that it will be obsoleted when Comm. Toolbox is released? >If anyone is interested I could explain how I eradicated the flicker. Sure, I don't even know what flicker you mean. I read this group to learn, though. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com This message does represent the views of Eclectic Software.
levin@bbn.com (Joel B Levin) (12/22/89)
In article <9376@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: |I wanted to comment on this "abusiveness" issue when someone made it |last week, but I'm doing it now instead. The claim is that pop-ups |don't exhibit the itemless scrolling behavior as long as they're used |correctly. I must disagree strongly. Most dialogs should be modeless |and have drag bars. If you do this, there is no way to allow |legitimate dragging while preventing the pop-up from being close to the |bottom of the screen, creating this obnoxious behavior. Modeless |dialogs are hardly "abusive"; if anything, modal dialogs are the |abusive ones. This behavior is a bug in PopUpMenuSelect, not the fault |of application programmers. I assume you are referring to the way popups have of allocating sufficiently large rectangles that are mostly full of whitespace if the top end of the menu is initially selected while being popped up at the bottom of the screen, for example. I agree that it is not preventable with the current standard methods, and I'd add that it's not necessarily a bad thing if it is required, as it seems to be now, that (a) the mouse not be moved and (b) the programmer be allowed to start the menu at any specified item. As a user, I find the Suntools method much more disconcerting: If the menu doesn't have enough room to pop up, the current mouse position is moved _by the system_ so that there will be enough room for the menu. This can be even worse if a hierarchical menu is invoked. I prefer the Mac way in this case. My $.02. /JBL = Nets: levin@bbn.com | "There were sweetheart roses on Yancey Wilmerding's or {...}!bbn!levin | bureau that morning. Wide-eyed and distraught, she POTS: (617)873-3463 | stood with all her faculties rooted to the floor."
6500stom@hub.UUCP (12/23/89)
From article <9376@hoptoad.uucp>, by tim@hoptoad.uucp (Tim Maroney): > In article <3379@hub.UUCP> 6500stom@hub.UUCP writes: >>This sounds very much like the popupmenu CDEF that I'm working on >>right now and maybe I'll introduce it because I should be done with >>v2.0 today. The main feature is that there is zero flickering if you >>use it non-abusively. > I wanted to comment on this "abusiveness" issue when someone made it > last week, but I'm doing it now instead. The claim is that pop-ups > don't exhibit the itemless scrolling behavior as long as they're used > correctly. I must disagree strongly. Most dialogs should be modeless > [etc...] I don't think you understood what I ment by abusiveness. I certainly wasn't talking about that.. > You do realize that it [my popup] will be obsoleted when Comm. Toolbox is > released? Now I do. When I posted this message I didn't realize that the Comm Toolbox would include a "blessed" popupmenu CDEF. I'm sorry for causing all the trouble. >>If anyone is interested I could explain how I eradicated the flicker. > Sure, I don't even know what flicker you mean. I read this group to > learn, though. Actually I was just speculating when when I was talking about flicker. Maybe Apple has figured out how to eradicate it too. The flicker would occur if you click on the popupmenu so fast that the menu doesn't actually pop up, if they haven't fix it. Before I embarrest myself by describing a weird way to eradicate the flicker could somebody please tell me if Apple has solved the problem? Its fairly tricky unless they found a simple way to do it than I did. / Josh Pritikin T Ignorance is bliss. \ | Internet: 6500stom@ucsbuxa.ucsb.edu | I must be in hell. | | AppleLink: Josh.P | My room is proof that entropi | \ GEnie: J.Pritikin ! exists. /
tim@hoptoad.uucp (Tim Maroney) (12/24/89)
In article <9376@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >|The claim is that pop-ups >|don't exhibit the itemless scrolling behavior as long as they're used >|correctly. I must disagree strongly. Most dialogs should be modeless >|and have drag bars. If you do this, there is no way to allow >|legitimate dragging while preventing the pop-up from being close to the >|bottom of the screen, creating this obnoxious behavior. In article <50039@bbn.COM> levin@BBN.COM (Joel B Levin) writes: >I assume you are referring to the way popups have of allocating >sufficiently large rectangles that are mostly full of whitespace if >the top end of the menu is initially selected while being popped up at >the bottom of the screen, for example. Not exactly. I'm referring to the fact that if the popup is very close to the bottom of the screen, then you get a short menu consisting of nothing but an up arrow and a down arrow, with no menu items displayed or selectable. Pretty obnoxious. >I agree that it is not >preventable with the current standard methods, and I'd add that it's >not necessarily a bad thing if it is required, as it seems to be now, >that (a) the mouse not be moved and (b) the programmer be allowed to >start the menu at any specified item. True of the behavior you mean; not true of the behavior I mean, which is A Bad Thing no matter how you slice it. >As a user, I find the Suntools method much more disconcerting: If the >menu doesn't have enough room to pop up, the current mouse position is >moved _by the system_ so that there will be enough room for the menu. Ouch. But then, Suntools is a pain in the ass all around. Still, you'd think even it would be friendly enough not to jump the mouse around without warning. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "In any religion or form of worship, followers should be allowed to think for themselves. In every religion that has a god other than Jesus Christ, adherents are not allowed to think for themselves." -- Lauren Stratford, "Satan's Underground"
tim@hoptoad.uucp (Tim Maroney) (12/24/89)
From article <9376@hoptoad.uucp>, by tim@hoptoad.uucp (Tim Maroney): >> You do realize that it [my popup] will be obsoleted when Comm. Toolbox is >> released? In article <3398@hub.UUCP> 6500stom@hub.UUCP writes: >Now I do. When I posted this message I didn't realize that the Comm >Toolbox would include a "blessed" popupmenu CDEF. I'm sorry for causing >all the trouble. I'm sorry if I offended you; obviously you haven't created any trouble. I just thought you'd like to know that such a CDEF will be becoming part of the standard system software. >>>If anyone is interested I could explain how I eradicated the flicker. >> Sure, I don't even know what flicker you mean. I read this group to >> learn, though. > >Actually I was just speculating when when I was talking about flicker. >Maybe Apple has figured out how to eradicate it too. The flicker would >occur if you click on the popupmenu so fast that the menu doesn't >actually pop up, if they haven't fix it. Before I embarrest myself by >describing a weird way to eradicate the flicker could somebody please >tell me if Apple has solved the problem? Its fairly tricky unless >they found a simple way to do it than I did. The pop-ups do flicker in this way in the Comm. Toolbox configuration dialogs. But I don't see why it's really a problem. This is not a normal usage mode, it's an error mode, and it doesn't do anything confusing or unexpected when the user makes the error. But let's hear how yoiu got rid of it. It seems like it would be pretty easy by just waiting for a fraction of a second before calling PopUpMenuSelect.... -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Every year, thousands of new Randoids join the ranks. Most tend to be either too-rich self-made tycoons or picked-on computer nerds (the romantic, heroic individualism of Rand's novels flatters the former and fuels the latter's revenge fantasies)." -- Bob Mack, SPY, July 1989
6600pete@hub.UUCP (12/24/89)
From article <9390@hoptoad.uucp>, by tim@hoptoad.uucp (Tim Maroney): > you'd think even [SunTools] would be friendly enough not to jump the mouse > around without warning. Actually, I rather like that feature. Moves the pointer to default buttons, etc. Disconcerting from a Mac point of view, but then QuicKeys is sometimes even worse -- it'll move the pointer and leave it there long enough for you to reorient yourself to its new position, then move it BACK. ------------------------------------------------------------------------------- Pete Gontier | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa Editor, Macker | Online Macintosh Programming Journal; mail for subscription Hire this kid | Mac, DOS, C, Pascal, asm, excellent communication skills
6500stom@hub.UUCP (12/24/89)
>>>>If anyone is interested I could explain how I eradicated the flicker. >>> Sure, I don't even know what flicker you mean. I read this group to >>> learn, though. >>...The flicker would >>occur if you click on the popupmenu so fast that the menu doesn't >>actually pop up, if they haven't fix it... > The pop-ups do flicker in this way in the Comm. Toolbox configuration > dialogs. But I don't see why it's really a problem. This is not a > normal usage mode, it's an error mode, and it doesn't do anything > confusing or unexpected when the user makes the error. But let's hear > how you got rid of it... Oh good. My popupmenu CDEF wont be completely outdated. The problem looks like this, when TrackControl is called the Contrl Mgr issues the following messages to the CDEF: (from MacTutor, Jan '89, p 11) init testCntl drawCntl loop autoTrack testCntl after mouseup autoTrack drawCntl The problem is that when the popup gets a draw message it needs to draw the whole popupmenu. This might not sound disasterous but look at the messages again. The CDEF gets drawn once during init and once after mouseup. If the selection wasn't changed in the autoTrack, we get a lot of flicker. Now this isn't such a terrible this except that I can't stand it... and I think a lot of people agree with my assessment of flicker. The solution is rather involved. The CDEF needs to know that it should ignore any draw messages during a TrackControl unless the autoTrack routine bids it (ie, the selection has changed and updating is needed). The first method I used was to set up a flag in the contrlData field of the ControlRecord. Then the application could flip this flag on just before the TrackControl and off just after. If the flag was set the draw routine simply didn't draw unless it was called by the autoTrack routine. This method worked great except if you let the Dialog Mgr deal with the CDEF itself. You see, the Dialog Mgr doesn't know that it should flip flags. The latest method works like this: my CDEF patches the TrackControl routine so that I can warn the draw routine not to draw. I wont bore you with the details but everything falls into place nicely. The patch isn't a tail patch and I remove the patch as soon as it wont be needed anymore. I conceed that this method isn't compat. consious as the first method put its more elegant from the programmer's point of view. / Josh Pritikin T It takes real genus to see \ | Internet: 6500stom@ucsbuxa.ucsb.edu | the obvious. | | AppleLink: Josh.P | Just don't say no if they | \ GEnie: J.Pritikin ! don't ask you. /
tim@hoptoad.uucp (Tim Maroney) (12/25/89)
In article <3417@hub.UUCP> 6500stom@hub.UUCP writes: >If the selection wasn't changed in the autoTrack, >we get a lot of flicker. Now this isn't such a terrible this except >that I can't stand it... and I think a lot of people agree with my >assessment of flicker. Oh? I doubt very many others have even noticed it. How many people go around clicking really fast on pop-up menu items in dialogs? Why would anyone do such a thing? Now that I think about it, the "flicker" may be a good thing. If someone doesn't know how pop-ups work and just quickly single clicks on one of them, then the "flicker" will at least show the user the menu -- they'll understand immediately what happens when you click on a pop-up and that they could select something from a menu if they just held the mouse down and dragged instead of single-clicking. This is called advertising your features, and it's one of the basic principles of friendly interface design. >The latest method works like this: my CDEF patches the TrackControl >routine so that I can warn the draw routine not to draw. I wont >bore you with the details but everything falls into place nicely. >The patch isn't a tail patch and I remove the patch as soon as it >wont be needed anymore. I conceed that this method isn't compat. >consious as the first method put its more elegant from the programmer's >point of view. There are some of us who consider any trap patch inherently inelegant, the kind of awkward maneuver one should undertake only if the goal can't be reached any other way, and a necessary evil even then. Given that the patch is being used here to overcome behavior that is at worst a very minor annoyance and at best an important way for software to advertise its behavior to naive users, I think "elegant" is hardly the word. Sorry. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Gorbachev is returning to the heritage of the great Lenin" - Ronald Reagan
6500stom@hub.UUCP (12/29/89)
> ...Given > that the patch is being used here to overcome behavior that is at worst > a very minor annoyance and at best an important way for software to > advertise its behavior to naive users, I think "elegant" is hardly the > word. Sorry. Well, your simply wrong. Heehee. (all comments >dev/null) / Josh Pritikin T It takes real genus to see \ | Internet: 6500stom@ucsbuxa.ucsb.edu | the obvious. | | AppleLink: Josh.P | Just don't say no if they | \ GEnie: J.Pritikin ! don't ask you. /
tim@hoptoad.uucp (Tim Maroney) (12/30/89)
In article <3428@hub.UUCP> 6500stom@hub.UUCP writes: >> ...Given >> that the patch is being used here to overcome behavior that is at worst >> a very minor annoyance and at best an important way for software to >> advertise its behavior to naive users, I think "elegant" is hardly the >> word. Sorry. > >Well, your simply wrong. Heehee. (all comments >dev/null) Thanks for your thoughtful and mature response. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "The men promise to provide unconditionally for their wives. The women in turn serve unconditionally to provide the other household services necessary for the men to fulfill their obligations to the women. The women are satisfied because they have the men working for THEM." -- Colin Jenkins, soc.women
dorner@pequod.cso.uiuc.edu (Steve Dorner) (01/08/91)
I have a couple of popup font menus in one of my dialog boxes. I'm using the popup CDEF from the Communications Toolbox. The first time the dialog box is used (in standard GetNewDialog/ModalDialog/ DisposDialog fashion), it works JUST FINE. Subsequent uses of the dialog draw the popups fine, but cause crashes if the popups are pressed on (frequently also corrupting my application heap). I've commented out all the code that acts on what the user selects; all interaction with the popups are taking place solely through the dialog manager. I defined the popups with ResEdit (2.1), and they look fine in the DITL editor. Rezdet is happy with my application. The same behavior happens if I use the popupUseAddResMenu variation code or a static menu. The same behavior happens if I have the CTB installed in my system folder, or just copy the CDEF into my app. It happens whether or not I use my whizzy dialog filter. It happens whether or not I've called InitCRM and InitCTBUtilities. Traces in SADE of the control record and the associated menu handle look practically identical every time the dialog is up. This is on an 8meg SE/30. Does this sound familiar to anyone? -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
dorner@pequod.cso.uiuc.edu (Steve Dorner) (01/08/91)
I wrote: >I have a couple of popup font menus in one of my dialog boxes. I'm using >the popup CDEF from the Communications Toolbox. > >The first time the dialog box is used (in standard GetNewDialog/ModalDialog/ >DisposDialog fashion), it works JUST FINE. Subsequent uses of the dialog >draw the popups fine, but cause crashes if the popups are pressed on Alex Kazim (may he be forever blest :-)) gave me the answer. The popup CDEF requires that the menu used has the same menu id as it does resource id. I am unable to find documentation for this restriction, but it is certainly there. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner