Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!agate!usenet
From: fjlim@garnet.berkeley.edu
Newsgroups: comp.sys.mac.programmer
Subject: Re: THINK Class Library Questions
Keywords: THINK C
Message-ID: <1989Aug17.075500.9811@agate.berkeley.edu>
Date: 17 Aug 89 07:55:00 GMT
References: <480@lloyd.camex.uucp>
Reply-To: fjlim@garnet.berkeley.edu ()
Organization: University of California, Berkeley
Lines: 79

In article <480@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes:
>
>1) How does CDesktop handle a non-rectangular desktop made of more
>than one screen?  Does it say that the bounds is the same as bounding
>box of the collection?

CDesktop uses the bounds of the GrayRgn as the bounds of the Desktop,
so it is the same as the bound box of the collection.

>2) When does the gGopher change behind my back, and when should my
>objects change him?  (Or should it be her?  We need ruling on this
>one...gBartender and gDecorator too.)

The gGopher gets set to gApplication when the program starts. It then
changes automactically when:

	* the current gGopher is disposed/deactivated (usually occurs
	when a window is deactivated or closed). In this case, the
	supervisor of the gGopher is made the new gGopher.

	* a Director is activated (usually occurs when the window
	controlled by the Director is activated). In this case, the
	object referenced by the itsGopher instance variable of the
	Director is made the gGopher. By default, itsGopher is set
	to the Director itself in the IDirector() method. You can
	set itsGopher to something else (a Pane in the window for
	example) if you want to. It's also OK to explicitly change
	the value of gGopher (e.g. in a MacDraw-like program, you
	could set gGopher to the currently selected graphical object.
	You would then change gGopher directly when the user selects
	a different object.)

In general, gGopher should point to the object which wants first crack
at handling all menu commands and keystrokes--the so called "active
object."

To avoid being sexist, I recommend using "it" to refer to objects.

>3) CStaticText has a ScrollToSelection method, but no other mention of
>selections?  Can the user copy from static text?  Where does that
>happen?

CStaticText does not have any other methods dealing with selections, so
the user can not copy from static text. However, the ScrollToSelection()
method was placed in CStaticText rather than CEditText to allow programmers
to create subclasses of CStaticText which do handle selections, but not
necessarily for the purpose of copying text. For example, you may want
to have a subclass of CStaticText where you can perform a search. After
finding the search string, you could set the TextEdit selection to the
beginning of the found string, then do a ScrollToSelection() to make
the found string visible within the scrolling text.

>4) Is there a way to have some objects compile with 68020/68881 code,
>but not others?  Use libraries?  I am imagining two versions of the
>same object, one does SANE calls, one calls the 68881/2 directly.  Or,
>some objects might use 68020 instructions, with a 68000 version also
>there.  Would decide which types to create at initialization time.

I'll leave this one to Rich.

>5) Why don't buttons need a draw method?  Where does their drawing
>take place?

CButton inherits the Draw() method from its superclass, CControl. This
is a perfect example of the power of inheritance. CButton, CRadioButton,
and CCheckBox all inherit the Draw() method from CControl. CScrollBar,
however, overrides Draw() because scroll bars behave differently from an
ordinary control in that they hide themselves when they are inactive.

>6) Might you folks ever port this object library to other platforms,
>or is the very idea too revolting?

Another question best left for Rich.

-------
Gregory H. Dow, Ursa Major Software.

Disclaimer: I wrote the THINK Class Libray but am not an employee of
Symantec Corp. All comments and opinions are mine alone.