This is window-object-and-awake-method in view mode; [Up]
Date: Sun 30-Nov-1989 01:47:03 From: Unknown Subject: window object and awake method i've got a problem. i've created a subclass of a window which i built with IB. my awake method in this subclass never gets called nor does its finishUnarchiving method. what's wrong? ==+==+==+==+==+==+==+==+==+==+==+==+==+== ..umbc3.umbc.edu!tron!kgw2!dennisg + Dennis P. Glatting + Xetron Corporation + Cincinnati, Ohio + I want my own NeXT, 16 MB RAM, + 660 MB SCSI, NeXT Printer. + Accepting Donations. ==+==+==+==+==+==+==+==+==+==+==+==+==+== >From: ed@DTG.COM (Edward Jung)
Date: Sun 03-Dec-1989 18:52:49 From: Unknown Subject: Re: window object and awake method In article <128@kgw2.UUCP>, dennisg@kgw2 (Dennis Glatting) writes: > >i've got a problem. >i've created a subclass of a window which i built with IB. >my awake method in this subclass never gets called nor does >its finishUnarchiving method. what's wrong? > When Interface Builder creates your classes, it is not "unarchiving" them. Archiving and archiving is performed by the read:/write: method pair. Interface Builder creates objects through the run-time system, thereby making the process essentially language independent (recall that the only language dependent parts of Interface Builder are the parse and unparse operations). If you want to change the behavior of the window, use the the Window class). If you want to do something after everything is set up, you could try working with the key and main related window methods (e.g. via a delegate, or override orderFront:/orderWindow:relativeTo:, you get the idea.).
Date: Sun 06-Dec-1989 01:53:37 From: Unknown Subject: Re: window object and awake method In article <128@kgw2.UUCP> dennisg@kgw2.UUCP (Dennis Glatting) writes: >i've got a problem. >i've created a subclass of a window which i built with IB. >my awake method in this subclass never gets called nor does >its finishUnarchiving method. what's wrong? IB doesn't store windows in the .nib file; instead it stores WindowTemplates. WindowTemplates are read in and sent awake messages; Windows are still created with the good old newContent:style:backing:buttonMask:defer: method. The best is to have a common initialization routine that is called by both your new methods and the read/awake pair. This way the initailization will get done properly no matter how the object is created. Ali >From: cbenda@unccvax.UUCP (carl m benda) use an XT front end...
Date: Sun 05-Dec-1989 22:14:32 From: Unknown Subject: Re: window object and awake method In article <1989Dec3.185249.5197@uunet!dtgcube>, ed@DTG.COM (Edward Jung) writes: > In article <128@kgw2.UUCP>, dennisg@kgw2 (Dennis Glatting) writes: > > > >i've got a problem. > > ...nor does > >its finishUnarchiving method. what's wrong? > > > > When Interface Builder creates your classes, it is not "unarchiving" > them. Archiving and archiving is performed by the read:/write: method i've found that indeed the getNewContent factory method is used to create the object. Therefore i overrode it. after i did a [super ...] i initialized my subclass variables (which contain other objects). I can't associate buttons/actions yet since the controls aren't created at that point. therefore i was going to do it in "awake". (oh, i've subclassed the window.) what am i doing? well, i developing a large app. i've broken down the major window segments into seperate modules under IB (about 10-12). when a item is selected from a menu, or sub-menu, the delegate of the menu matrix, my app coordinator object, looks in its hash table for the selection. if not found it is then loaded from a IB module. i suppose what i should do after its loaded is call a myAwake method. that rids all of the bull. you know? this thing is cool. needs better docs though (online 1.0 stuff isn't good enough).
Date: Sun 07-Dec-1989 18:08:44 From: Unknown Subject: Re: window object and awake method In article <12934@polya.Stanford.EDU>, ali@polya.Stanford.EDU (Ali T. Ozer) writes: > In article <128@kgw2.UUCP> dennisg@kgw2.UUCP (Dennis Glatting) writes: > >its finishUnarchiving method. what's wrong? > > The best is to have a common initialization routine that is called by both > your new methods and the read/awake pair. This way the initailization will > get done properly no matter how the object is created. > i've overrode the getNewContent method but the controls and other objects aren't allocated at that point. i need to manipulate some of those objects (since i'm inserting some custom objects). since i have multiple .nib files being loaded on demand, i believe i can work around the problem by overriding the getNewContent method then calling a myAwake method after it is read in. if there is an established technique, like awake, then that is what i preferr to use. so when a .nib file is loaded the file's contents aree a template. does this imply that, since i currently override the getNewContent method, that the objects i create after [super..] vanish? (i guess what i'm really asking is whether the object created with getNewContent is the object or is it copied?) could you point me in a direction that i could educate myself better on this process?
Date: Sun 08-Dec-1989 22:18:15 From: Unknown Subject: Re: window object and awake method In article <306@kgw2.UUCP>, dennisg@kgw2 (Dennis Glatting) writes: > >so when a .nib file is loaded the file's contents aree a template. does >this imply that, since i currently override the getNewContent method, that >the objects i create after [super..] vanish? (i guess what i'm really >asking is whether the object created with getNewContent is the object or >is it copied?) could you point me in a direction that i could educate >myself better on this process? > You might want to look at the description for the finishUnarchiving method (for example in Object). This mechanism can allow a template to return another object, sort of like: - finishUnarchiving { Window * new_window; new_window = [Window newContent...] // init from // template's instance variables [self free]; return new_window; } So if you had overridden the newContent... method, your self would really be the "true" object and no copying needs to be involved. Note, of course, the actual class to which the new method is sent would not be hard-coded, but specified from information kept by Interface Builder.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.