Hi David and Jean-Denis, I haven't been following the list for a while so I'm just catching up and see my message about initialization sparked some responses.
I haven't observed the behavior that you mention of "awakeFromNib" being called more than once for an object instantiated by NIB file expansion and I log calls to "awakeFromNib" in my applications, but I haven't used the "initWithCoder" method yet either. I think all all MacRuby subclass objects are "custom" objects and will receive an "init" message in addition to or in lieu of "initWithCoder". I should give "initWithCoder" a try to reduce my app startup time. I load some data from CSV files and the Ruby CSV file parser is so incredibly slow that I have to parse the files one line at a time in an NSTimer loop to avoid getting the "waiting" icon and crashing my USB device drivers. A large CSV file of about 2,000 lines takes 20-30 seconds of processing time to load! I probably should pre-parse the CSV files then load the data from binary files. Do you know what would cause "awakeFromNib" to be called more than once for an object instance? I have considered "awakeFromNib" to be an initialization method and I've been using it as such without a problem. My understanding is that the NIB file expansion instantiates objects by unarchiving but then uses your attr_writer or attr_accessor construction methods to set up outlet connections and it calls setTarget and setAction methods to establish action connections before calling "awakeFromNib". Bob Rice On Dec 10, 2012, at 5:38 AM, david kramf <dakr....@gmail.com> wrote: > Hi Jean-Denis > 1. Thank you for your advice about awakeFromNib and InitWithCoder. > 2. "That is a bonus you ..". This is not a bonus. This is Ruby. If you define > a Ruby class you expect that any object will get instantiated through > "initialize". I have a feeling that all who responded to me on the forum > started their programming track from Objective-C and proceeded to Ruby. I am > coming from the opposite direction. I come from Ruby and wants to deal with > Objective-C as little as possible. So I expect MacRuby to be as much "Ruby" > as it is possible. > Many Thanks, David > On Dec 10, 2012, at 11:27 AM, Jean-Denis MUYS wrote: > >> >> On 7 déc. 2012, at 19:48:39, david kramf <dakr....@gmail.com> >> wrote: >>> >>> Message: 1 >>> Date: Fri, 7 Dec 2012 19:48:39 +0200 >>> From: david kramf <dakr....@gmail.com> >>> To: "MacRuby development discussions." >>> <macruby-devel@lists.macosforge.org> >>> Subject: Re: [MacRuby-devel] Problem with a window controller >>> Message-ID: <1f1681c7-9de6-4971-8d17-722f5ec63...@gmail.com> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> Hi Bob, >>> "As you become more familiar with IB, you will probably do more >>> initialization of objects in IB and less in MacRuby. Nib file expansion >>> instantiates objects and then makes calls to initialize the objects using >>> the same methods that you are using to initialize objects in MacRuby. >>> Actually, in a large application, it would difficult to hook up all of the >>> outlets without using IB." >>> >>> From my modest acquaintance with MacRuby that is not exactly the case since >>> when the NIB instantiates an NSWindowController object , it does not call >>> "initialize" >> >> Cocoa, whether accessed from Ruby, Python, Objective-C or any language, uses >> the Cocoa initialization patterns. It's unrealistic to assume the framework >> patterns to change when you change the client language. >> >>> ,as defined in Ruby , but calls "awakeFromNib". >> >> It does, but caveat: awakeFromNib is *not* an initialization method, even >> though it is often used as such. I was bitten before. The correct >> initialization method to use for Nib files is initWithCoder:. What's the >> difference, says you (and me)? Behold: awakeFromNib can be called several >> times in the lifetime of an object. This is no big deals for most >> initializations, but becomes a major issue in others. In my case, I was >> registering for notifications in awakeFromNib. Since I was registered >> several times, I got the notifications multiple times, and since I only >> unsubscribed once in dealloc, my app would crash. >> >> Many cases when awakeFromNib is called more than once are programming >> errors, but not all. And since there *is* a real initializer, I recommend >> using it. >> >> So in that case why is there an awakeFromNib method at all? It is because at >> initWithCoder: time, IB outlets are not yet loaded and are all nil. So >> awakeFromNib is meant to for initialization code that configures outlet. >> >> So here is a recipe: >> >> 1- Does you initialization code requires IB outlets to be alive? If not, >> override initWithCoder: >> 2- If so, put it in awakeFromNib >> 3- Does that awakeFromNib initialization code need to be called once only? >> if so, make it conditional on it having been already be called. >> 4- Optional: assert that awakeFromNib was not called before, and if that >> assert fires, investigate whether the case is legitimate or due to a bug in >> your code. >> >>> Only when you instantiate your controller from the code itself , you get >>> your "initialize"method called. >> >> That is a bonus you just can be happy to have due to the deep integration of >> MacRuby in the Objective-C runtime system. There is no reason to assume that >> bonus to expand to objects created by the framework. >> >>> I know I still have a lot of practicing on IB. What I find disturbing ,is >>> that when I do something with IB I cannot see the code created to >>> accommodate my actions ( maybe because I only work in MacRuby and not >>> Objective-C?). >> >> No. This is simply because there **no code created**. At all. IB does't >> generate code. And lest I forget: Interface Builder is not a code generation >> tool. IB instantiates and populates objects, and then serializes them to >> disk. Those objects are then simply deserialized from disk in your app. At >> no point ever is any code generated. Therefore, there is no "code created to >> accommodate your actions" for you to see. Even in Objective-C. >> >> Best regards, >> >> Jean-Denis >> >> _______________________________________________ >> 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 https://lists.macosforge.org/mailman/listinfo/macruby-devel
