This is When-are-myWindow-IDs-valid?-(was:-Re:-mouseMoved,-anyone? in view mode; [Up]
Date: Sun 23-Oct-1991 07:44:56 From: mcgredo@bluto.ie.orst.edu (Don McGregor) Subject: Re: When are myWindow IDs valid? (was: Re: mouseMoved, anyone? Michael D Mellinger writes > >I don't think the 'window' id is inititialized in your "-init" method. >Set a break point in Gdb and check window. I did this in my mouseDown >loop, where 'window' is nonNil and it *all* of the mouseMove events >were responded to. > > [window setEventMask:([window eventMask] | NX_MOUSEMOVEDMASK)]; > > >I'm not sure when it's safe to assume that 'window' is a valid id. > I was confused about this too. Another trip to gdb shows that the window instance variable is set when the view is placed into a view heirarchy associated with a window. This makes sense. When you initFrame: the view, it can't know what window it's going to be in. When you place it as a subview of a view already associated with a window, the window instance var should be set to that window. So, during and after initFrame: the window instance variable is nil. After the view is placed into another view with an addSubview:thisView message, the window instance var is set. (if the superview is associated with a window, that is.) To get the program to work, you might try something like thisView = [[View alloc] initFrame:&foo]; [anotherView addSubview:thisView]; [[thisView window] setEventMask:([window eventMask] | NX_MOUSEMOVEDMASK)]; See the windowChanged: method of View for a way to explicitly set the window.
Date: Sun 23-Oct-1991 21:03:23 From: johnr@oceania.com (John Robison) Subject: Re: When are myWindow IDs valid? (was: Re: mouseMoved, anyone? In article <r5dHnsp93@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) > > In article <sd1=B=y00VAtA=40Uw@andrew.cmu.edu> bh1b+@andrew.cmu.edu (Brian C. Hobbs) writes: > > I'm trying to implement a mouseMoved from within a view. > > [window setEventMask:([window eventMask] | NX_MOUSEMOVEDMASK)]; > > from within the view's init: method does nothing (as in the mouseMoved > method is not used within the view implementation). > > I don't think the 'window' id is inititialized in your "-init" method. > > I'm not sure when it's safe to assume that 'window' is a valid id. > The appDidInit: method is a pretty safe bet. You can count on all id's really pointing to something at that point. It is also called before the first user even is processed, so it would be an ideal place to set the event mask at a "global" level. (As opposed to setting the mask inside the mouseDown: as shown in the NeXT examples.) John
Date: Sun 24-Oct-1991 00:24:10 From: melling@cs.psu.edu (Michael D Mellinger) Subject: Re: When are myWindow IDs valid? (was: Re: mouseMoved, anyone? In article <1991Oct23.210323.6306@oceania.com> johnr@oceania.com (John Robison) writes: The appDidInit: method is a pretty safe bet. You can count on all id's really pointing to something at that point. It is also called before the first user even is processed, so it would be an ideal place to set the event mask at a "global" level. (As opposed to setting the mask inside the mouseDown: as shown in the NeXT examples.) This seems like a messy solution. For a given object, I want to know when IB has instantiated its ids. I suppose that I can call all of my objects from appDidInit, but I was hoping for a better solution. -Mike
Date: Sun 24-Oct-1991 08:04:17 From: wb1j+@andrew.cmu.edu (William M. Bumgarner) Subject: Re: When are myWindow IDs valid? (was: Re: mouseMoved, anyone? <5o5H14ba3@cs.psu.edu> If you load your __NIB sections from code (usually within the - init method), then you are guaranteed that your outlet ids have been appropriately initialized (except stuff pointing to something in a window that is deferred-- those won't be initialized until the window is brought onto the screen). This also has the advantage of: - speed; you only load those nib sections that are needed... the program is less bulky in memory and should initially start faster - versatility; this is the way to support multiple documents. Also, it is extremely easy to have multiple inspectors or an inspector w/a customizable section of IB stuff (like Preferences). - cleanliness; You know EXACTLY when and where your nib section will be loaded and when the various variables will be in a given state. How it works: externalNib= [[Something alloc] init]; (where Something is the File's Owner class of whatever nib you are going to load). In the - init method of the Something class, you do a: [NXApp loadNibSection:"Something's Nib Name" withOwner:self ....]; This will load the nib section and tie all the IB stuff with the instance variables of self. After the loadNibSection call is successfully complete, you can initialize all the IB stuff you need to via the now initialized instance variables. --- - Because it is an external nib from the core of the App, you can't tie menu commmands to actions in the external nib (nor can you make direct connections between objects in different nibs). Nor can you have instances of your external nib in the main app-- it must be loaded through code (as demonstrated by the above) - Solution: use your applicaiton controlling class to manage all the external nibs (either in List objects or an id variable for single instances). This provides a central point from which you can get at the various UI stuff. - or you can keep track of stuff like that in the Class (+) methods. This is a little more complex, but can be really useful. For example, the Application class does this. It can't respond to init, but if you send the Application class a + new method, it will return the already created Application object (if there is one) since there can only be one instance of the Application class per running Application. - to pass menu stuff around, use FirstResponder. Since I understand it only well enough to get by and the explanation would be fairly lengthy (but a GOOD demonstrative explanation is sorely needed-- this is a difficult concept), I'm not going to mention much other than it basically entails adding a method to the FirstResponder instance in the main app (or whatever nib section) and then writing a corresponding method in whatever objects (that must inherit from Responder directly or indirectly) should be able to respond to said message (a copy may mean something completely different between windows-- for example, the type of the objects copied). Then, as your app is running, the window manager will move the First Responder focus between objects depending on which window is key-- though the hierarchy can be changed from code as well. - make sure and add the .nib files to your projects. If you don't, make debug will execute properly, but make install won't because it won't be able to find the nib sections. --- b.bum b.bumgarner | Disclaimer: All opinions expressed are my own. wb1j+@andrew.cmu.edu | I officially don't represent anyone unless I NeXT Campus Consultant | explicity say I am doing so. So there. <Thpppt!> "I ride tandem with the random/Things don't run the way I planned them.."
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.