[comp.sys.mac.programmer] scroll bar problem

rpitt@caen.engin.umich.edu (Raymond Jeczen Pittman) (04/01/89)

Here's a question for ya:


i
I am writing an application that uses multiple windows and I would
like to know how I can access the control list in the window record

to reference a particular controlhandle such as the scroll bars.  I

don't declare my scroll bar handles globally, I like to keep it
dynamic.    The control is declared locally in a procedure but the
control is tagged to the window with the NewControl rom call.

(My routine only passes the window ptr into this procedure.
 


Any ideas?



Is this approach the 'mac standard' from a commercial perspective?  Or
is there an entirely different, easier, more efficient way of setting
this up?



Thanks.



R.J.  Pittman        rpitt@caen.engin.umich.edu




:wq

oster@dewey.soe.berkeley.edu (David Phillip Oster) (04/01/89)

In article <425ca822.1285f@maize.engin.umich.edu> rpitt@caen.engin.umich.edu (Raymond Jeczen Pittman) writes:
>I am writing an application that uses multiple windows and I would
>like to know how I can access the control list in the window record
>to reference a particular controlhandle such as the scroll bars. 
1.) look at how the dialog manager associates a TEREcord with a window:
it defins a struct that has a WindowRecord as its zeorth element, and
has a field holding a handle to the TE further along.
2.) I like to put a handle to a struct in the refcon of my windows. My
window structs have fields for the data that describes the contents of my
windows. Two common fields I use are hScroll vScroll: the scroll bars of
the  window (or pane, for multiple panes, each with their own scroll
bars.)

Searching the ((WindowPeek)thePort)->controlList for the control you
want will work, but is seems pretty funky to me.


--- David Phillip Oster            --"When we replace the mouse with a pen,
Arpa: oster@dewey.soe.berkeley.edu --3 button mouse fans will need saxophone
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --lessons." - Gasee

jackiw@cs.swarthmore.edu (Nick Jackiw) (04/03/89)

In article <425ca822.1285f@maize.engin.umich.edu> rpitt@caen.engin.umich.edu (Raymond Jeczen Pittman) writes:
> I am writing an application that uses multiple windows and I would
> like to know how I can access the control list in the window record
> to reference a particular controlhandle such as the scroll bars.  I
> don't declare my scroll bar handles globally, I like to keep it
> dynamic.    The control is declared locally in a procedure but the
> control is tagged to the window with the NewControl rom call.
> Any ideas?
> Thanks.
> R.J.  Pittman        rpitt@caen.engin.umich.edu
----
Sure you can do it this way if you want. TheWindow^^.ControlList heads a
linked list of all of your controls.  How do you recognize a particular
control (e. g. horiz scroll) once you've got the ControlList?  You'll have
to slap an identifying constant into the control's RefCon field.

At this point you should begin to wonder how dearly you wish to stick to
those principles of application hygene learned in CS courses.  While you
have no global variables, and therefore are guaranteed to enforce "side-
effect-free" discipline, you DO have a global declaration of the identifying
constant, which makes your code just as difficult to read as a global var;
AND you lose efficiency because you have to search the window's entire
control list instead of having a variable already pointing to your control.

As long as you document thoroughly that a routine relies upon, or sets, a
global var, why not use one?  Their disadvantages are all theoretical, their
advantages are all immensely practical.



-- 
+-------------------+-jackiw@cs.swarthmore.edu / !rutgers!bpa!swatsun!jackiw-+
|  nicholas jackiw  | jackiw%campus.swarthmore.edu@swarthmr.bitnet           |
+-------------------+-VGP/MathDept/Swarthmore College, Swarthmore, PA 19081--+
"Ah...I've got this CHRONIC pain."                             _True Believer_

ech@pegasus.ATT.COM (Edward C Horvath) (04/04/89)

In article <425ca822.1285f@maize.engin.umich.edu> rpitt@caen.engin.umich.edu (Raymond Jeczen Pittman) writes:
> I am writing an application that uses multiple windows and I would
> like to know how I can access the control list in the window record
> to reference a particular controlhandle such as the scroll bars...

From article <2642@masada.cs.swarthmore.edu>, by jackiw@cs.swarthmore.edu (Nick Jackiw):
> Sure you can do it this way if you want. TheWindow^^.ControlList heads a
> linked list of all of your controls.  How do you recognize a particular
> control (e. g. horiz scroll) once you've got the ControlList?  You'll have
> to slap an identifying constant into the control's RefCon field.

> At this point you should begin to wonder how dearly you wish to stick to
> those principles of application hygene learned in CS courses...

One other "clean" solution already suggested is to put a handle to a struct
in the window's refCon.  Another method is to take a page from Apple's book
(single-inheritance OOPLs, really).  Note that WindowRecord has GrafPort as
a prefix; similarly, DialogRecord has a WindowRecord as a prefix.  Since
a Dialog "IS A" Window "IS A" GrafPort, this makes perfectly good sense.

The windowKind field is there for you to use as a tag for a "safe union."
While the WindowMgr will set that to userKind (8), any value >=8 is available
for your use.  Hence declarations like

enum { unspec = userKind,
	windowType1,... };

typedef struct {
	WindowRecord theWindow;
	/* my stuff ... */
} window1;

are perfectly reasonable; you allocate space for a window1, pass its address
to NewWindow, then set theWindow.windowKind appropriately and flesh out the
other fields.  The address of a window1 is usable as a WindowPtr or GrafPtr
in all contexts.

About the only drawback to this approach is if you want some of your windows
to be non-modal dialogs (the DialogMgr wants a windowKind of 2).  Not a
killer, but it would be nicer if we could just set and forget windowKind.

=Ned Horvath=

ph@cci632.UUCP (Pete Hoch) (04/06/89)

jackiw@cs.swarthmore.edu (Nick Jackiw) writes:
> rpitt@caen.engin.umich.edu (Raymond Jeczen Pittman) writes:
> > I am writing an application that uses multiple windows and I would
                                          ^^^^^^^^ ^^^^^^^
> > like to know how I can access the control list in the window record
> > to reference a particular controlhandle such as the scroll bars.  I
> > don't declare my scroll bar handles globally, I like to keep it
                                                  ^ ^^^^ ^^ ^^^^ ^^
> > dynamic.    The control is declared locally in a procedure but the
    ^^^^^^^
> > control is tagged to the window with the NewControl rom call.
> > Any ideas?
> > Thanks.
> > R.J.  Pittman        rpitt@caen.engin.umich.edu
> ----
> Sure you can do it this way if you want. TheWindow^^.ControlList heads a
> linked list of all of your controls.  How do you recognize a particular
> control (e. g. horiz scroll) once you've got the ControlList?  You'll have
> to slap an identifying constant into the control's RefCon field.

Or since you are in control of how the window is built you can always
add the vertical control first and the horizontal control next.  Then
follow with any ofther controls you may want in that window.  Then when
you walk the control linked list you will know that the first control
is the vertical and the second is horizontal.

> At this point you should begin to wonder how dearly you wish to stick to
> those principles of application hygene learned in CS courses.  While you
> have no global variables, and therefore are guaranteed to enforce "side-
> effect-free" discipline, you DO have a global declaration of the identifying
> constant, which makes your code just as difficult to read as a global var;
> AND you lose efficiency because you have to search the window's entire
> control list instead of having a variable already pointing to your control.

This can still be done in a "clean" manner by putting all of you scrollbar
handleing routines in one unit.  The unit would have routines for adding
scroll bars, adjusting scrollbars, and adjusting the window content based
on the value od the scroll bars.  There does not have to be any side effects
and you remove the need for your global variables.

> As long as you document thoroughly that a routine relies upon, or sets, a
> global var, why not use one?  Their disadvantages are all theoretical, their
> advantages are all immensely practical.
 
The oringinal poster stated that he was writting a program with multiple
windows.  Now if the program is to be artificialy limited to 20 windowes
then an array of control handles could be easily used.  But if you want
to remove the window limit, maintaining a list of global controlHandles
in no longer "immensely preactical".  

> |  nicholas jackiw  | jackiw%campus.swarthmore.edu@swarthmr.bitnet           |


Pete Hoch
Computer Consoles, Inc.
ph@cci632.cci.com

pepke@loligo.cc.fsu.edu (Eric Pepke) (04/12/89)

I always have the refcon of the window hold a handle to a structure, record,
or object which contains all of the information about the window, including
handles to the scroll bars.  This does not require dinking with any of the
Window or Control Manager's data structures, using global variables, assuming 
anything about the order of controls, or arbitrarily limiting the number
of windows.  The only assumption this makes is that a refcon is large enough
to hold a handle.

Eric Pepke                                     ARPA:   pepke@gw.scri.fsu.edu
Supercomputer Computations Research Institute  MFENET: pepke@fsu
Florida State University                       SPAN:   pepke@scri
Tallahassee, FL 32306-4052                     BITNET: pepke@fsu

Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.