Re: Tracking rectangles with Cocoa views in Carbon windows
Re: Tracking rectangles with Cocoa views in Carbon windows
- Subject: Re: Tracking rectangles with Cocoa views in Carbon windows
- From: David Elliott <email@hidden>
- Date: Sat, 18 Aug 2007 00:27:21 -0400
Hi Uli,
On Aug 17, 2007, at 5:30 PM, Uli Kusterer wrote:
On 16.08.2007, at 18:31, David Elliott wrote:
It seems there is a bug with tracking rectangles when they are set
from a Cocoa view living in a Carbon window. The specific case is
that of a Cocoa PDE running on Tiger.
Are you saying you somehow managed to get a Cocoa view into a
Carbon window? That's not supported as of Tiger, but various times
it has been said that it was the intention to eventually support
this. Or are you just talking about a Cocoa window in a Carbon app,
for which you've triggered creation of a Carbon WindowRef by
calling -windowRef?
No, what I am saying is that Apple has gotten a Cocoa view into a
Carbon window. Search for Cocoa PDE with plain old Google and you'll
find this:
http://developer.apple.com/samplecode/CarbonPrintingSample/index.html
There is a much cleaner example in the Leopard section which is more
of a stub and thus easier to understand at first glance but obviously
I'm not going into detail about that on this list. Instead I'll put
things in terms of this public example.
This example, like any Cocoa plugin, has an NSPrincipalClass which in
this sample's case is the AppCustomPDE class which implements the
PDEPanelsForType:withHostInfo: instance method.
That returns an array of objects which adhere to an informal
protocol, one of the methods being panelView which returns the NSView
you want to use for the print panel. The print dialog itself is
apparently Carbon because if you drop into the debugger and examine
the result of its window method you can clearly see the returned
window is of class NSCarbonWindow.
All of this is running on Tiger.
Thinking about it a bit further, consider that Cocoa has always
supported the auxiliaryView when invoking printing from Cocoa and so
it would seem rather obvious that if the print dialog has been a
Carbon window (and I can't verify this is necessarily true pre-Tiger)
then Apple has been doing at least a bit of Carbon/Cocoa integration
behind the scenes for some time now.
NSCarbonWindow has existed for a very long time now, check this
message on this list:
http://lists.apple.com/archives/Cocoa-dev/2002/Feb/msg01788.html
And of course there has been [NSWindow -initWithWindowRef:]
supposedly since 10.0 according to the documentation so it would seem
that putting Cocoa views on a Carbon window has been possible for
some time now.
As for my specific problem, I've had a chance to try the dummy window
method and it didn't work because the window server does take window
ordering into account when doing the tracking rects. So that's out.
The latest thing I'm working on is observing the CFRunLoop at the
kCFRunLoopExit phase. From there, I am able to use use
[NSApplication -currentEvent] to get the Cocoa event that is about to
be returned from nextEventMatchingMask:untilDate:inMode:dequeue:. If
you aren't aware, the CFRunLoop runs entirely from within the
nextEvent… method and typically exits for the purposes of returning
to its caller (not really nextEvent… but effectively so via
DPSNextEvent) which will then of course return to [NSApplication -
run] which proceeds to call sendEvent: and then do it all over again.
So it seems to me that by hooking the event loop I can avoid doing
any method swizzling with NSApplication and hopefully even avoid the
need for NSApplication to be the one driving the event loop. That is
that I seriously hope when I try this on a Carbon app I'll still be
able to use currentEvent from the CFRunLoopObserver.
The way I see it, I am using a documented interface
(CFRunLoopObserver) and the only thing I'm doing that's not
documented is depending on [NSApplication -currentEvent] to work from
that runloop point. Obviously if I am able to observe events at this
low level then I should be able to look for the mouse entered/exited
events and ship them off to my code one way or another.
If you or anyone else has any bright ideas I'm certainly willing to
hear them. For what it's worth, this is part of the work I'm doing
on improving the wxCocoa port of the wxWidgets open source project,
so the code for this will be available in the public svn repository.
-Dave
_______________________________________________
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