vishniac@wanginst.UUCP (Ephraim Vishniac) (11/06/85)
This is a technical query about action procedures for controls. That said, most of you can stop reading, unless you want to know what my thumb has to do with anything. According to the Control Manager chapter of IM, the action proc for a particular control will be called repeatedly as long as the mouse is down in some part of the control. True enough, it will. It also says that there are two flavors of action procs, depending on whether or not the control is an "indicator". If it is, the action proc is a parameterless procedure (no arguments, no return value). If not, the action proc receives the control handle and part code as arguments. IM points out that it's important to know what kind of control you're dealing with, since "obviously" your action proc can only be of one type or the other. My problem: when I mouse down in the scrolling or paging regions of my scrollbar, my action proc is called exactly as advertised with the appropriate handle and part code on the stack. When I mouse down in the thumb (the little square item that shows the scroll bar position), my action proc is called without parameters as though the thumb were an indicator! Since I'm writing in assembler, I can deal with this, but I'd still like to know what's going on here. I'd be in serious trouble if I were using a compiled language and couldn't muck with the stack. Has anyone run into this curiosity? Has anyone used a scrollbar action proc and *not* run into this? I can post source if necessary for further discussion. The scrollbar itself, BTW, is built in RMaker as a CTRL resource and referred to a resource control item in the DITL of the current DLOG. The DLOG is running under _ModalDialog. Ephraim Vishniac [apollo, bbncca, cadmus, decvax, harvard, linus, masscomp]!wanginst!vishniac vishniac%Wang-Inst@Csnet-Relay -- Ephraim Vishniac [apollo, bbncca, cadmus, decvax, harvard, linus, masscomp]!wanginst!vishniac vishniac%Wang-Inst@Csnet-Relay
gus@Shasta.ARPA (11/09/85)
> According to the Control Manager chapter of IM, the action proc for > a particular control will be called repeatedly as long as the mouse is > down in some part of the control. True enough, it will. It also says > that there are two flavors of action procs, depending on whether or not > the control is an "indicator". If it is, the action proc is a parameterless > procedure (no arguments, no return value). If not, the action proc > receives the control handle and part code as arguments. IM points out > that it's important to know what kind of control you're dealing with, > since "obviously" your action proc can only be of one type or the other. > > My problem: when I mouse down in the scrolling or paging regions of my > scrollbar, my action proc is called exactly as advertised with the > appropriate handle and part code on the stack. When I mouse down in the > thumb (the little square item that shows the scroll bar position), my > action proc is called without parameters as though the thumb were an indicator! > Since I'm writing in assembler, I can deal with this, but I'd still like > to know what's going on here. I'd be in serious trouble if I were using > a compiled language and couldn't muck with the stack. > > Has anyone run into this curiosity? Has anyone used a scrollbar action > proc and *not* run into this? > ARGH! Yes! I ran into this one this summer when I was writing Pascal code. I ended up writing a very small kluge routine that would provide the two missing parameters to the action proc (which are both really needed at all times) The routine was rather ugly as it had to resort to less-than robust techniques to figure out who was calling me, and where I could find the missing data. I don't remember exactly what I did. (I would have to dig up the Lisa Pascal/assembler source for that.) The problem stems from the fact that the control manager passes the action proc routine address to DragGreyRegion when you click in a draggable indicator. DragGrayRegion does not know anything about control action procs in particular. It just simply has a hook that it calls repeatedly with no parameters. The action proc, however, calls this routine itself when the part does not move. (i.e. is not an indicator or 'thumb') Fortunately, this anomoly is covered in reasonable detail in Inside Mac. Unfortunately, no solution is presented. Perhaps most unfortunately, this is a serious design flaw which can be worked around, but which cannot be fixed because the fix would break most existing work-arounds! Moral, DON'T RELEASE PROGRAMS WITH DESIGN DEFFICIENCIES!!!!
bhyde@inmet.UUCP (11/09/85)
It is clearly a design flaw that the action proc of a control has two different signatures. My solution to this problem was to build my own control, which usually just calls thru to the vanilla control. Then I use the control defproc calls and avoid the action proc entirely. Of course that's still hard to do if your writing in anything but pascal. My C version, for example, requires asm glue.
bmug@well.UUCP (Frederick A. Huxham) (11/11/85)
In article <1283@wanginst.UUCP> vishniac@wanginst.UUCP (Ephraim Vishniac) writes: > >My problem: when I mouse down in the scrolling or paging regions of my >scrollbar, my action proc is called exactly as advertised with the >appropriate handle and part code on the stack. When I mouse down in the >thumb (the little square item that shows the scroll bar position), my >action proc is called without parameters as though the thumb were an indicator! >Since I'm writing in assembler, I can deal with this, but I'd still like >to know what's going on here. I'd be in serious trouble if I were using >a compiled language and couldn't muck with the stack. > You don't need to have an action procedure for a mouse-down in the thumb of a scroll bar, only the arrows or paging regions. Typically I do something like the following: if(partcode == inThumb) { call TrackContr with NIL for an actionProc } else if(partcode != 0) { /* ie. not inThumb */ call TrackControl with an actionProc } Simply check to see whick part of the scroll bar the user has clicked in and then call TrackControl with a NIL actionProc if the partcode is inThumb. Hope this helps, Fred A. Huxham
vishniac@wanginst.UUCP (Ephraim Vishniac) (11/12/85)
> According to the Control Manager chapter of IM, the action proc for > a particular control will be called repeatedly as long as the mouse is > down in some part of the control. True enough, it will. It also says > that there are two flavors of action procs, depending on whether or not > the control is an "indicator". If it is, the action proc is a parameterless > procedure (no arguments, no return value). If not, the action proc > receives the control handle and part code as arguments. IM points out > that it's important to know what kind of control you're dealing with, > since "obviously" your action proc can only be of one type or the other. > > My problem: when I mouse down in the scrolling or paging regions of my > scrollbar, my action proc is called exactly as advertised with the > appropriate handle and part code on the stack. When I mouse down in the > thumb (the little square item that shows the scroll bar position), my > action proc is called without parms as though the thumb were an indicator! Since writing this, I've found that the Control Manager chapter does mention that the thumb of a scroll bar is, generically speaking, the "indicator" of a "dial." This still fails to explain, though, why my actionProc is called with varying argument lists and how one is expected to deal with this. So, I repeat my original question: > Has anyone run into this curiosity? Has anyone used a scrollbar action > proc and *not* run into this? -- Ephraim Vishniac [apollo, bbncca, cadmus, decvax, harvard, linus, masscomp]!wanginst!vishniac vishniac%Wang-Inst@Csnet-Relay
bmug@well.UUCP (Frederick A. Huxham) (11/14/85)
In article <1318@wanginst.UUCP> vishniac@wanginst.UUCP (Ephraim Vishniac) writes: >> >> My problem: when I mouse down in the scrolling or paging regions of my >> scrollbar, my action proc is called exactly as advertised with the >> appropriate handle and part code on the stack. When I mouse down in the >> thumb (the little square item that shows the scroll bar position), my >> action proc is called without parms as though the thumb were an indicator! > >Since writing this, I've found that the Control Manager chapter does mention >that the thumb of a scroll bar is, generically speaking, the "indicator" of >a "dial." This still fails to explain, though, why my actionProc is called >with varying argument lists and how one is expected to deal with this. So, >I repeat my original question: > >> Has anyone run into this curiosity? Has anyone used a scrollbar action >> proc and *not* run into this? >-- >Ephraim Vishniac > [apollo, bbncca, cadmus, decvax, harvard, linus, masscomp]!wanginst!vishniac > vishniac%Wang-Inst@Csnet-Relay On page 20 of the Control Manager (phone book edition) it says: "- If actionProc is NIL, TrackControl performs no additional actions. This is appropriate for simple buttons, check boxes, radio buttons, and the THUMB OF A SCROLL BAR." You shouldn't need to call an actionProc for a mouseDown in the thumb of a scroll bar unless your scroll bar does some very weird things. My last response to this query showed how to handle scroll bar mouseDowns. If your scroll bar (thumb) has to exhibit strange behavior, what is it that its supposed to do. Fred A. Huxham
vishniac@wanginst.UUCP (Ephraim Vishniac) (11/18/85)
> In article <1318@wanginst.UUCP> vishniac@wanginst.UUCP (Ephraim Vishniac) writes: > >> (you've all read this part before, so I'll just skip it) Fred Huxham replies: > On page 20 of the Control Manager (phone book edition) it says: > > "- If actionProc is NIL, TrackControl performs no additional actions. > This is appropriate for simple buttons, check boxes, radio > buttons, and the THUMB OF A SCROLL BAR." > > You shouldn't need to call an actionProc for a mouseDown in the thumb of > a scroll bar unless your scroll bar does some very weird things. > > If your scroll bar (thumb) has to exhibit strange behavior, what is it that > its supposed to do? From the varied replies I've gotten, it seems my original query didn't stress some pertinent points strongly enough. I'm trying to use a scroll bar in a modal dialog, using _ModalDialog. With no action proc, the thumb is entirely functional, just as Fred points out. However, the scrolling arrows and paging regions do nothing. I installed an actionProc because I thought it was the obvious way of implementing scrolling and paging. This resulted in the originally described problem: my action was called with arguments for scrolling or paging and without arguments for thumbing. Correspondents have made essentially three suggestions: 1. On entry to the action proc, check the arguments on the stack for plausibility (esp., does the control handle match?). If implausible, assume that there are no arguments and that the thumb was pressed. This is a real hack. 2. Write a filter proc for _ModalDialog. On each mousedown event, test whether the mouse is in the scroll bar and, if so, what part it's in. Install or remove the actionProc (or swap actionProc's) as appropriate. This is the Apple-approved hack, courtesy of Larry Rosenstein @ Apple. 3. Write a control definition in which the thumb is not an indicator. This might not be as much work as it sounds, since I think I saw the source for the scroll bar CDEF in the last software supplement. For now, I'm sticking with (1). It's simple, robust, and disgusting. -- Ephraim Vishniac [apollo, bbncca, cadmus, decvax, harvard, linus, masscomp]!wanginst!vishniac vishniac%Wang-Inst@Csnet-Relay
tim@k.cs.cmu.edu (Tim Maroney) (11/20/85)
There is an example of using a scroll bar within a modal dialog in the
example programs in the latest Software Supplement. A subset of the
Standard File Package is implemented in the file "EXAMPLE/SFSAMPLE.TEXT" on
the "Examples 2" disk. You could do worse than imitating it.
-=-
Tim Maroney, CMU Center for Art and Technology
tim@k.cs.cmu.edu uucp: {seismo,decwrl,etc.}!k.cs.cmu.edu!tim
CompuServe: 74176,1360 Once it ruled the Earth; now it delivers pizza.