Hi Bob I still have to get used to the IB. One of the things I find confusing is that after I define something using the IB I don't see the generated code . I think that initially I will rely less on the IB and more on the code. Many Thanks, David.
On Dec 4, 2012, at 9:19 AM, Robert Carl Rice wrote: > Hi David, > > AppDelegate doesn't inherit from NSWindowController so you would need a > MacRuby outlet to obtain a link to the Main Menu window or any other object > instantiated in the NIB, but usually you don't need this. This outlet doesn't > need to be named "window". You could rename it to something like > :mainMenuWindow to be less confusing. Usually you would add additional > outlets to change controls within the Main Menu. These outlets don't need to > be in an NSWindowController subclass. The attr_writer or attr_accessor > pre-processor macros will define a class variable that you would reference > with a leading "@". > > If you instaintiate a subclass of NSWindowController by adding an object to > the XIB that you assign to your own subclass, then NSWindowController will > automatically add an IB outlet for "window" to your subclass that you would > normally "hookup" in IB to your own subclass of NSWindow instantiated by the > same NIB. You should not create MacRuby accessors for "window" in an > NSWindowController subclass rather you use the self.window superclass method. > The @window class variable should be undefined in your NSWindowController > subclass . Cocoa does not define MacRuby class variables; only MacRuby code > can do that. You would only get the same NSWindow instance for both your > AppDelegate and your NSWindowController subclass if you connect both your > AppDelegate and your NSWindowController subclass to the same window in IB. > > Bob Rice > > > On Dec 4, 2012, at 1:25 AM, david kramf <dakr....@gmail.com> wrote: > >> Hi Bob >> I never programmed in Objective-C. >> When I open a MacRuby project I automatically get a window attar_accessor >> defined in my AppDelegate created code, but not in the controller which I >> write by my own. If I connect, using IB , the window to my controller >> parameter (object variable) , I get the same window property created both in >> my WindowController and in the appDelegate. So far during my plays with the >> code I don't encounter any other problem apart from the willLoad and didLoad >> delegates which I expected to be called . Since the @window variable is >> already instantiated when my awakeFromNib is called, I have a feeling that >> the Cocoa code already called them before he created MyController class. I >> am not sure about that , since this reasoning leads to a conclusion that >> this is some kind of a bug in Cocoa , but Cocoa exists for a long time and >> used a lot , so I am not sure. >> Since this is the only problem I faced so far , I decided to move on and be >> careful upon relying on these 2 delegates. >> Thanks, David. >> >> On Dec 4, 2012, at 2:06 AM, Robert Carl Rice wrote: >> >>> Hi David, >>> >>> You should consider the "window" Objective C property to be "owned" by >>> NSWindowController and it's confusing to define a Ruby class variable with >>> the same name. It should automatically appear as an IB outlet for your >>> NSWindowController subclass that you would "hook up" in IB just as you >>> would a MacRuby outlet assuming that you instantiate your >>> NSWindowController subclass with the same NIB with your NSWindow. >>> >>> As per the NSWindowController documentation, you would read the window >>> property using the method window() or self.window which will first load the >>> window if it not already loaded. >>> >>> You could set the window property using setWindow( window ), but normally >>> you have NIB expansion call setWindow. >>> >>> Similarly NSWindow automatically defines the delegate property that you can >>> hook up to your window controller in IB assuming that you instantiate your >>> NSWindowController subclass with the same NIB with your NSWindow. >>> >>> I removed a lot of initialization code from my applications once I better >>> understood how NIB file expansion works. You can hook up most of your >>> delegates and target actions in IB. You can even initialize static Popup >>> and comboBox option lists in IB. However, don't hookup dataSource in IB for >>> NSTableView or NSOutlineView because it will attempt to load table data >>> before you get awakeFromNib. >>> >>> Bob Rice >>> >>> On Dec 3, 2012, at 1:35 AM, david kramf <dakr....@gmail.com> wrote: >>> >>>> Hi Bob >>>> My code crashes if I omit the attr_accessor. >>>> Can you refer me to instructions of how to configure the IB to link to my >>>> controller as delegate (?) . In the examples I have in my book and ,if I >>>> am not mistaken, lectures I viewed in iTunes U ( the Stanford series ), >>>> they all used the awakeFromNib as point of initialization . >>>> Thanks, David >>>> On Dec 3, 2012, at 6:24 AM, Robert Carl Rice wrote: >>>> >>>>> Hi David, >>>>> >>>>> A couple of things I notice offhand in you code: >>>>> >>>>> The NSWindowController class defines accessor methods for "window" so you >>>>> shouldn't redefine it with the Ruby attr_accessor method. Note: similarly >>>>> NSViewController defines accessor methods for "view". >>>>> >>>>> You can configure IB to link the window delegate when the Nib is expanded >>>>> so that you don't need to set it in awakeFromNib. >>>>> >>>>> Bob Rice >>>>> >>>>> >>>>> On Nov 29, 2012, at 6:50 PM, david kramf <dakr....@gmail.com> wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> In the copied below code only the awakeFromNib is executed . Can someone >>>>>> explain me what do I do wrong ? Window is displayed and I expected all >>>>>> other methods to be called. >>>>>> Thanks, David >>>>>> >>>>> >>>>> _______________________________________________ >>>>> MacRuby-devel mailing list >>>>> MacRuby-devel@lists.macosforge.org >>>>> http://lists.macosforge.org/mailman/listinfo/macruby-devel >>>> >>>> _______________________________________________ >>>> MacRuby-devel mailing list >>>> MacRuby-devel@lists.macosforge.org >>>> http://lists.macosforge.org/mailman/listinfo/macruby-devel >>> >>> _______________________________________________ >>> MacRuby-devel mailing list >>> MacRuby-devel@lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo/macruby-devel >> >> _______________________________________________ >> MacRuby-devel mailing list >> MacRuby-devel@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macruby-devel > > _______________________________________________ > MacRuby-devel mailing list > MacRuby-devel@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macruby-devel
