Re: How to avoid warning with objc_msgSend
Re: How to avoid warning with objc_msgSend
- Subject: Re: How to avoid warning with objc_msgSend
- From: David Elliott <email@hidden>
- Date: Tue, 5 Oct 2004 14:28:54 -0400
Hi,
Chiming in here as the author of this code.
You can find it at wxWidgets ViewCVS. The relevant change (and
relevant code) is here:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/src/cocoa/
window.mm.diff?r1=1.44&r2=1.45
The latest complete copy is here:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/src/cocoa/window.mm?
rev=1.48&content-type=text/vnd.viewcvs-markup
On Oct 5, 2004, at 12:15 PM, Finlay Dobbie wrote:
On 5 Oct 2004, at 09:46, Ryan Norton wrote:
Anyhow, assuming that GetNSView() is a function returning a pointer
to an NSViewInstance, why don't you just send it normally?
id aView = GetNSView();
NSRect *rects;
int rectCount;
[aView getRectsBeingDrawn:&rects count:&rectCount];
Because this generates both a runtime and compiler warning on 10.2
and lower (using the id instead of a plain GetNSView generates an
extra compiler warning also) :).
This is what I have now
--- code ---
// Set m_updateRegion
const NSRect *rects = ▭ // The bounding box of the region
int countRects = 1;
// Try replacing the larger rectangle with a list of smaller ones:
NS_DURING
// This only works on Panther
// [GetNSView() getRectsBeingDrawn:&rects count:&countRects];
// This compiles everywhere (and still only works on Panther)
objc_msgSend(GetNSView(),@selector(getRectsBeingDrawn:
count:),&rects,&countRects);
NS_HANDLER
NS_ENDHANDLER
--- code ---
Then do this:
id aView = GetNSView();
NSRect *rects = NULL;
int rectCount = 0;
if ([aView respondsToSelctor:@selector(getRectsBeingDrawn:count:)]) {
[aView getRectsBeingDrawn:&rects count:&rectCount];
}
That obviously won't cause a runtime warning on 10.2 and lower. It'll
cause a compile-time warning, removing that would be an exercise for
the reader (hint: define a protocol, but this is really bad practice
as those methods aren't really implemented and thus the warning is
perfectly valid).
Right. I could have used a protocol but I didn't see the point when I
could just as easily call objc_msgSend myself and get (AFAICT) the
exact same result.
The problem I have is not that the compiler issues a warning (it
doesn't, obviously) but that the runtime on 10.2 issues a warning. I
would have thought that the whole point of catching the exception is to
avoid any ill effects that may happen from calling an unimplemented
method. And indeed, without catching the exception the app will crash.
But even when I do catch it it emits a console warning which IMHO is
ridiculous.
I had thought about using respondsToSelector though it seemed there
ought to be a way to have it attempt to call the method and in the
event that it is not implemented simply ignore the error rather than
checking if it is implemented each time before calling the method.
If there is no way to silence the runtime warning I have two choices:
1) use the above method and see if it's implemented before calling it
2) just remove the code since most apps probably won't benefit from
this optimization anyway.
-Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden