Re: NSView confusion
Re: NSView confusion
- Subject: Re: NSView confusion
- From: Negm-Awad Amin <email@hidden>
- Date: Wed, 20 Aug 2008 17:39:55 +0200
Am Mi,20.08.2008 um 16:25 schrieb Charlie Dickman:
Nobody has anything to offer other than a nebulous "try changing the
declarations"?
I have tried everything I can think of and have tried the
documentation I can find and I still can not figure out what is
going on or what to do about it.
I have an app that contains multiple NSView's which are all visible
at the same time. They are all sub-classes of NSView but not of any
of the others. Each has its initialize, initWithRect and drawRect
methods invoked as it should.
With the exception of the 1st one I defined, the workhorse view, no
methods implemented in any of the others and declared in the
respective .h files are visible to any of the other views at compile
time. I import the appropriate .h files and invoke the method via
[view method... and the compiler reports that no such method can be
found. Yet if I invoke the method via [view performSelector:... at
execution time it works just fine.
This is a possibility, but you should think about a protocol. However
you should check this at run-time:
if( [aView respondsToSelector:@selector( method )] ) {
…
}
If you are *really* expecting a specific class (you import a class!)
not a specific ability (protocols are closer related to abilities),
than you can check for a class, which clarifies your code:
if( [aView isKindOfClass:[MySpecialView class]] ) {
MySpecialView* specialView = (MySpecialView*)aView;
[specialView method];
}
But: Checking for a class is worse than checking for an ability. So
you only should do this, if you really expect a class, not an ability.
I have no idea why the compile time recognition fails. Can someone
explain to me what is going on and what I can do about it? Should
there be a view hierarchy? If so, how structured?
View class hierarchy?
The compiler checks for known methods and put them into relation to
the found classes. If you try to send a method to baseview, the
compiler checks, whether this method exists (is implemented) for that
class. So you cannot send a method message to baseview, if it is
implemented in derivedview.
When you use -performSelector the compiler does exactly the same: He
checks, whether the method – in this case performSelcotr – is
implemented in the receiver's class. -perfromSelector: is implemented
for every class. So there is no problem for the compiler.
But then he was to solve the @selector. Doing so, he needs *any* (i.g.
in any class) prototype for this method. Since you mentioned this
method in a class, you have to import this class. You can put this
method to a protocol, to a totally different class, $somewhere – that
does not matter. The compiler simply needs any knowledge about it.
Also, how does one synchronize events with the update of the various
views? I can instruct each view what to draw and it draws it just
fine (I use lockFocus, etc. when drawing is external to drawRect)
??????????????????????????
and the updated view is seen _eventually_ but I can not synchronize
subsequent activity to happen after the appropriate display is seen.
How can I accomplish this synchronization? And how can I force a
view to update? Invoking [view display] has no effect on forcing the
display toshow the latest update.
-display (NSView) immediatly draws the view – bad design. You should
use something like -setNeedsDisplay:.
Beside this, if there is no update, you have a problem elsewhere.
Cheers,
Amin
Thanks for any help you can provide.
Charlie Dickman
email@hidden
_______________________________________________
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
Amin Negm-Awad
email@hidden
_______________________________________________
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