Re: Prevent Asynchronous operation of beginSheetModalForWindow
Re: Prevent Asynchronous operation of beginSheetModalForWindow
- Subject: Re: Prevent Asynchronous operation of beginSheetModalForWindow
- From: "John Love" <email@hidden>
- Date: Sat, 28 Jun 2008 11:12:06 -0400
> (1) warning: no doSheetSelection:contextInfo method found which, I think,
>> is
>> due to the fact that the external class of mFileSheetDelegate =
>> FileController, yet when referenced in SaveSheetController, it's = id, a
>> general pointer. But, I thought all anonymous pointers were resolved at
>> runtime ... am I just going to force myself to ignore this Build Warning,
>> knowing that it will all go away at runtime???
>>
>
>
> The reason for this is because the sheet controller is not aware of your
> File Controller's methods. Nor should it be. So how to resolve it? The
> answer is to declare the callback method as an informal protocol *within
> SheetController.h* Thus:
>
> I figured this out while I was mowing the lawn yesterday (before reading
this reply) (really!) -- do not have a clue what sort of Freudian psychology
this demonstrates -- cutting off the heads of delegates and informal
protocols, maybe? Regardless of the deviant psychology, I remember thinking
(while pushing the mower) "so that's what informal protocols are good for ..
delaying the presentation of Build Errors until runtime when all unresolved
references are - duh - resolved!!!"
>
> (2)I still get "unrecognized selector" .. but,
>>
>
> That's because you're targeting the wrong object. Here:
>
no psychology here, just plain brain-dead on my part
>
> You have got to get these relationships straight in your mind. It's not
> that hard. I've goaded and prompted you and written your code for you piece
> by piece - that's great, it solves your problem. But has it increased your
> understanding? I fear it hasn't, and it still all seems like voodoo. I'm not
> sure what I can do about that.
>
Amen to that .. no excuses here .. trying to do too many things at once ..
get re-acquainted with C, trying to use the same logic as my application's
AppleScript Studio Project counterpart .. Cocoa delegates .. who does what
to whom behind the scenes.
Anyway, it finally sunk in to keep all UI objects(buttons) local to the
individual sheet controllers and have the file controller worry only about
return codes. I also figured out (quirky psychology as noted above)
informal protocols .. my file controller imports "WhateverSheetController.h"
and to do away with informal protocols would necessitate
"WhateverSheetController.h" to import "FileController.h", aka a perfect
circle, aka failure to compile.
BTW, the reason for my originally passing (NSWindow*)sheet to
"doSheetSelection" within FileController.m was so this method could call
[sheet closeOut:self] .. not required now that I call the latter within the
sheet's didEndSelector.
I'll guarantee you one thing .. no one could ask for a more patient teacher
that you .. trust me, I mean that, every syllable. You remind me of an old
Physics prof I had many, many, many years ago who made physics sound so darn
simple (once it sunk in, which it did with minimal effort since I was so
young at the time).
Anyway, got some more things to understand (Menus and Toolbars) and probably
more questions to ask later, so ...
John
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden