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.