Thanks much to Matt ... On Jul 26, 2010, at 1:51 PM, Matt Neuburg <m...@tidbits.com> wrote:
> What do you mean "there is supposed to be a mechanism"? Do you mean the > normal nib-loading KVC-based setting out outlets? If so, there is not > "supposed" to be a mechanism; there *is* a mechanism. If that is what the mechanism is called, then that is what I mean; this is the first time I have had any occasion to be aware of it except as a silent, transparent entity that did its job well. It appears to be malfunctioning at the moment ... > If this was not > working you need to figure out why. That was the goal of my experimental "extra" load of the relevant nib file; the fact that after adding it, all works (view appears, operations involving the IBOject slots set in the nib file's owner succeed, et cetera) is modest evidence (though certainly not conclusive) that the nib file and code are set up properly. > There is no point substituting an > unknown for another unknown. There are many reasons why outlets come out as > nil at load time; a common one is that you didn't really draw the outlet in > the nib; Checked and double-checked, and the File's Owner slots show the expected bindings in the IB inspector. > another is that you have a setXXX method that is not the accessor > for the corresponding ivar. They are all set up as properties, and the mere act of deliberately loading the nib file did cause the bindings to get made properly. My very tentative guess would be that something has messed up the normal nib-file load in such a way as to break both the slot-binding mechanism and the response to rotation of the device or simulator. That error may well be entirely my own, and a stupid newbie mistake as well, but I still have to identify it before I can fix it. :-) I don't intend to leave hacks in place in production code, but they might shed light on what is going on, as a dignostic mechanism. > Also, at this point I have to wonder - is the controller's view actually > getting added to the window? That's an outlet from the file's owners in that > second nib, after all. If that's nil, then no view is added to the window. > If the view is not present in the window, the controller is not going to get > asked about rotating it. You may be right: Before I added the deliberate load of the nib file, I am not sure if the view was loaded; it is hard to tell visually without some of those operations that depend on the broken slots. After adding the code for the deliberate extra load of the nib file, the view is definitely there -- I can see its content. However, even though the "extra" load takes place before the "addSubview" call wherein the call to "shouldAutorotate..." takes place, "shouldAutorotate..." still is not getting called. That is, the experimental insertion of the "extra" load has fixed one problem (broken links) but not the other. Perhaps that is a clue ... ? > >> > > ... but the nib's owner is still responsible for doing memory management on > the top-level objects in the nib. Does it have accessors (probably > synthesized) for all its outlets, and do they all use (probably through a > property declaration) a retain policy? All are properties with retain. > You're just being so coy about your code. Why don't you just *show* the > revelant parts of the code? Just trying to save net.bandwidth; the "shouldAutorotate..." and "didFinishLaunching" (forgot its name at the moment) methods I started with were *precisely* those generated by the Xcode template, and they did not work. My changes to them to date comprise only logging calls and the nib file load for which I did give code. What else would you like to see? (The view and controller for this project are pretty simple, but the model is complicated, I doubt you want all the code.) > Or at least, why not continue doing what I > suggested before - make an essentially blank app and prove to yourself that > this basic mechanism works there, and then ask yourself how what you're > doing differs from that? Sorry I did not make clear; that was an excellent idea; I made one, it worked, and not only does the relevant code (just mentioned) look the same in my app, but also the connections between top-level objects in the nib files look the same. Go figure ... I may well be missing something, of course. If this turns out to be a stupid beginner error on my part -- as is likely -- I promise to eat lots of crow ... :-) -- Jay Reynolds Freeman jay_reynolds_free...@mac.com http://web.mac.com/Jay_Reynolds_Freeman > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
