kent@lloyd.camex.uucp (Kent Borg) (08/16/89)
Get ready Rich, here come the first of what will be a million questions about the object library Think is including with the new `Think' C compiler: 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? 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.) 3) CStaticText has a ScrollToSelection method, but no other mention of selections? Can the user copy from static text? Where does that happen? 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. 5) Why don't buttons need a draw method? Where does their drawing take place? 6) Might you folks ever port this object library to other platforms, or is the very idea too revolting? That's enough for now. (I hope you are looking forward to this Rich. There is a long road ahead.) Thanks. Kent Borg kent@lloyd.uucp or ...!husc6!lloyd!kent
fjlim@garnet.berkeley.edu (08/17/89)
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.
siegel@endor.harvard.edu (Rich Siegel) (08/18/89)
In article <1989Aug17.075500.9811@agate.berkeley.edu> fjlim@garnet.berkeley.edu () writes: >In article <480@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: > >>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. > You could use libraries, but mixed-mode projects are still tricky. I'd recommend two separate versions of the same program, each with its own compile settings. >>6) Might you folks ever port this object library to other platforms, >>or is the very idea too revolting? It's not a revolting idea, but I can't comment on the likelihood. (Company policy, you know. :-)) --Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When it comes to my health, I think of my body as a temple - or at least a moderately well-managed Presbyterian youth center." - Emo Phillips ~~~~~~~~~~~~~~~
kent@lloyd.camex.uucp (Kent Borg) (08/18/89)
In article <1989Aug17.075500.9811@agate.berkeley.edu> fjlim@garnet.berkeley.edu () writes: [answers to a few questions on the Think C class library] >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. This is great! We have both the object library's author on the net and Rich. We might get this figured out yet! Thanks Gregory, Rich, Think, Symantec, net-fate, etc. Kent Borg kent@lloyd.uucp or ...!husc6!lloyd!kent