watt@eleazar.dartmouth.edu (Gill Watt) (06/06/91)
howdy, The Situation: I am currently facing a tough decision concerning the use of the Think Class Libraries and am looking for opinions. I would like to use the Think Class Libraries to write my application which does: Data display (in color) Dialog boxes for display parameter selection Text display of character sequences (<32K) Control for a NuBus card. The First Problem (no colors): The problem I have encountered is that the TCL windows and whatnot are all defined based on the WindowPtr. For my application I need to use the full palette of colors and therefore the CWindowPtr. I originally thought it would be as simple as creating my own subclass of CWindow (called CCWindow) that uses GetNewCWindow() in its initialization instead of GetNewWindow(). The Resulting Problem (CWindow name dependency): However, I discovered, much to my dismay, that windows are assumed to be CWindows in many separate parts of the Class Libraries. For instance, CDirector->itsWindow is defined as a CWindow. Foolishly thinking that this was the only conflict, I created my own versions of CDirector and CDocument that use CCWindows instead of CWindows. I named these CCDocument and CCDirector. The Problem Blossoms (Name dependencies everywhere): Unfortunately, the interdependencies run much deeper, as I discovered that CPrinter->IPrinter() requires a CDocument argument and won't accept one of these new-fangled CCDocument things. Enough of this. The crux of the matter is this. The TCL cannot easily be converted to use CWindowPtrs as well as WindowPtrs and I am left pondering my next step. 1. Should I persevere and effectively create an entire parallel Class Library that is, for all intents and purposes, identical to the Think Class Libraries, except for the fact that the CCWindow Class uses CWindowPtrs? 2. Should I take the shortcut and just edit the existing CWindow Class to use CWindowPtrs and the other classes will never know the difference? (I tried this before, but am a little wary after witnessing the effect of those modifications on the AutoWeave updater.) 3. Should I just abandon the Class Libraries and tackle the programming head on, using straight C code? Opinions welcome. (If they weren't would I have posted to the net??) -Gill -- --------------------------------------------------------------------- Gill Watt (watt@eleazar.dartmouth.edu) Thayer School of Engineering, Dartmouth College, Hanover, NH 03755 ---------------------------------------------------------------------
sho@gibbs.physics.purdue.edu (Sho Kuwamoto) (06/06/91)
In article <1991Jun5.191451.26662@dartvax.dartmouth.edu> watt@eleazar.dartmouth.edu (Gill Watt) writes: >The problem I have encountered is that the TCL windows and whatnot >are all defined based on the WindowPtr. For my application I >need to use the full palette of colors and therefore the CWindowPtr. This is how you would add color windows to the Starter demo program... #include <CColorWindow.h> [...] void CStarterDoc::BuildWindow (Handle data) { CColorWindow *win; [...] win = new(CColorWindow); win->IColorWindow(WINDStarter, FALSE, gDesktop, this); itsWindow = win; [...] } That's it! CColorWindow is a descendant of CWindow which is defined in the More Classes folder. Although the itsWindow field of the CDocument class is defined to be a CWindow*, you can assign a CColorWindow* to it with no hassle. -Sho -- sho@physics.purdue.edu
bitting-douglas@cs.yale.edu (Douglas Bitting) (06/06/91)
>[someone wrote some stuff about wanting to get color out of TCL] While I have never tackled the problem of getting color out of TCL, I do have some stuff to say about the name dependencies you think you are running into. Assume you have an object called MyObj, and a subclass of this call MyOtherObject. If you have a function that looks like this: void SomeFunction(MyObj *anObj) { anObj->AFunctionCall(some/no arguments); } You can still call this as SomeFunction (anOtherObject) where anOtherObject is a MyOtherObject. The appropriate functions of the MyOtherObject class will be called. *However,* this assumes that the function being called exists in the MyObj class. If this function (really, its a method) is overridden in the MyOtherObject class, the method from MyOtherObject will be the one that called. In other words, the only way that you will run into name dependency is if you have some methods in MyOtherObject which don't exist in MyObject that you wish to call. I hope that made sense... So, theorectically (and I don't really know because I haven't looked into it...) you should be able to do color by writing subclasses of the necessary things and overriding the functions which need to be overridden. The one thing you need to make sure of is that all objects which are created my new() are your subclasses (those that need to be your subclasses, that is). Yes, this would take some work, but I don't know that it requires re-writing the entire class library. I think it is a shame that Symantec didn't include color in its class library. However, perhaps they will put it in the mythical version 5.0. Anyway... perhaps I just restated what was said before... however, it is a lot clearer in my mind now... :-) --Doug -- Doug Bitting | "And we know that in all things God works PO Box 3043 Yale Station | for the good of those who love him..." New Haven, CT 06520 | --Romans 8:28 bitting@cs.yale.edu +------------------------------------------
watt@eleazar.dartmouth.edu (Gill Watt) (06/07/91)
Thanks to everyone who sent me advice about the Think Class Libraries. Yes, the problems can be worked around by casting the CColorWindow object to a CWindow before assigning it to the CDirector's *itsWindow. As follows: itsWindow = (CWindow *) new ( CColorWindow ); I have also found this technique to be helpful in other places where I would like to enhance the functionality of the pre-existing classes without disturbing them. After initializing, I just cast my objects into their superclass for passing around the class library and whenever I require the additional methods, I recast them back into my own subclass. Summary: It's cool, it's powerful, and I can't help but think that it is a dangerous kludge. Why can't we have OOP for the mac without a spiders web of interdependencies between classes? Thanks again. -Gill -- --------------------------------------------------------------------- Gill Watt (watt@eleazar.dartmouth.edu) Thayer School of Engineering, Dartmouth College, Hanover, NH 03755 ---------------------------------------------------------------------
jbr0@cbnews.cb.att.com (joseph.a.brownlee) (06/07/91)
In article <1991Jun5.191451.26662@dartvax.dartmouth.edu> watt@eleazar.dartmouth.edu (Gill Watt) writes: > I would like to use the Think Class Libraries to write my > application which does: > Data display (in color) > [...] > The problem I have encountered is that the TCL windows and whatnot > are all defined based on the WindowPtr. For my application I > need to use the full palette of colors and therefore the CWindowPtr. > [...] > The crux of the matter is this. The TCL cannot easily be converted to > use CWindowPtrs as well as WindowPtrs [...] Well, I wouldn't say that exactly. I generally don't like making modifications to the TCL itself, but this is the one place where I have made an exception. I simply changed the IWindow() method to create a color window using NewCWindow() if the Mac has Color QD. I have done several things using this code, and I have had no problems. -- - _ Joe Brownlee, Analysts International Corporation @ AT&T Bell Labs /_\ @ / ` 471 E Broad St, Suite 1610, Columbus, Ohio 43215 (614) 860-7461 / \ | \_, E-mail: jbr@cblph.att.com Who pays attention to what _I_ say? "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (06/08/91)
Douglas Bitting writes in a message to All
DB> I think it is a shame that Symantec didn't include color in its
DB> class library. However, perhaps they will put it in the mythical
DB> version 5.0.
Doesn't ArtClass have color windows, etc?
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.org