Article View: comp.sys.next.programmer
Article #1040Re: the big demo / matrices
From: Brian Willoughby
Date: Mon, 14 Sep 1992 20:09
Date: Mon, 14 Sep 1992 20:09
63 lines
4400 bytes
4400 bytes
andrew abernathy writes | I have a (hopefully) quick question about matrices, cells and | tags. I use browsers in several places to allow the user to select some | entity. When I load the matrices, I set the cells tags to unique values | so that I can easily identify a selected cell. Well, I can get the cell | that is being selected, but it's tag always returns as -1. I'm having to | identify cell by their stringValues, which is very inconvenient. Does | anyone have any ideas why I might be getting the behavious I am? | -- | andrew_abernathy@wire.gwinnett.com (NeXTmail gleefully accepted) I am very familiar with this NXBrowser problem and I know exactly what the cause is (although I don't know why NeXT designed it this way). If you look closely at the NeXTstep References for the AppKit classes, you'll see that NXBrowserCell is a subclass of Cell. If you read the -tag and -setTag: methods for the Cell class, you'll note that they are not implemented for some reason. Instead, they are designed to be overridden and implemented in subclasses of Cell. If NeXT had written NXBrowserCell as a subclass of ActionCell instead of Cell, then your code would work as you wrote it. The solution, which I have working under System 2.2a, is to subclass both NXBrowserCell and NXBrowser. You can't make a category of NXBrowserCell since you need to add an instance variable to hold the tag. So, in your subclass of NXBrowserCell, just add an instance variable named "tag" and write the (obvious) code for the -tag and -setTag: methods. You should also override the -initTextCell: method and initialize this instance variable to something predictable like -1. I skipped the implementation of -read: and -write: since I never archive my browsers (other programmers may need to fill in these last two methods as well). You also need to write a subclass of NXBrowser because I have found no other reliable method of setting the cell class and cell prototype (i.e. one that doesn't eventually cause the program to crash). You must call -setCellClass with the name of your NXBrowserCell subclass within the +initialize method for your NXBrowser subclass. #mount _soap_box This is a prime example of how NeXTanswers is nearly useless. appkit.827 says to -setCellClass inside -initFrame:, appkit.816 says to -setCellClass in -appDidInit:, appkit.761 says that you must -setCellClass in +initialize because -init is too late, implying that -appDidInit would be far too late. It took a great deal of experimentation and searching to figure out what worked. Of course the simpler approaches didn't work and they were what I tried first. #dismount _soap_box Within my main program, I call -setCellPrototype before using the browser. This can probably be done in -appDidInit, but since I have several .nib files I use the -setBrowserOutlet initialization method for the nib owner to accomplish this (where browserOutlet would be the name of my instance variable). My only remaining problem is determining whether I should worry about -free'ing the cell prototype when I free the nib instance. I could assume that NXBrowser will free its cell prototype within its own -free method since the program crashes when I -free the cell prototype myself. If anyone reads this far and can offer a hint, I would appreciate it. MallocDebug finds so many other memory leaks that I can't tell whether NXBrowser is freeing the prototype cell. Sorry I didn't post source code, but this stuff is not packaged as an example. It is hidden deep within a program that I am currently writing. -- Brian Willoughby Software Design Engineer, BSEE NCSU BrianW@SoundS.WA.com Sound Signal Processing Software and Consulting NeXTmail welcome - NO EMAIL SOLICITATION without prior permission
Technical Details
Message-ID:
<BuL3zL.K2y@sounds.wa.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!nwnexus!sounds!brianwReferences:
<1992Sep5.040934.8445@wire.gwinnett.com>Show Full Headers
Complete Article Headers
Newsgroups: comp.sys.next.programmer Path: arc1-ca.pugleaf.net!sparky!uunet!nwnexus!sounds!brianw From: BrianW@SoundS.WA.com (Brian Willoughby) Subject: Re: the big demo / matrices Message-ID: <BuL3zL.K2y@sounds.wa.com> Sender: brianw@sounds.wa.com (Brian Willoughby) Reply-To: BrianW@SoundS.WA.com Cc: andrew_abernathy@wire.gwinnett.com Organization: SoundSoftware, Bellevue, WA, USA References: <1992Sep5.040934.8445@wire.gwinnett.com> Date: Mon, 14 Sep 1992 20:09:21 GMT Lines: 63