Hi Michael
I have had to do this same thing, and have encountered the same problem.
In my case the main thing I wanted to accomplish was to get the scroll view in
the main window to reflect the scroll position of my overlay window. It was not
working very well, but then in my main window, I turned off scrollsDynamically
then did a scrollPoint, then turned the scrollsDynamically back on again. I'm
not sure if that is relevant to your situation.
That made it significantly better, but it's still not the same as scrolling in
the main window when I don't have the overlay window there, so if you find out
any more info, I'd be keen to hear.
For sending events to the main window from the overlay, I have been creating a
new event from the existing event like this:
NSEvent *newEvent = [NSEvent
mouseEventWithType:[theEvent type]
location:mapWindowPoint
modifierFlags:[theEvent modifierFlags]
timestamp:[theEvent timestamp]
windowNumber:[parentWindow windowNumber]
context:[NSGraphicsContext
graphicsContextWithWindow:parentWindow]
eventNumber:[theEvent eventNumber]+1
clickCount:[theEvent clickCount]
pressure:[theEvent pressure]];
[NSApp postEvent:newEvent
atStart:NO];
Where mapWindowPoint is the event location converted to the location in the
parent window's coordinates, and incrementing the event number is just a guess
at what I might be supposed to do (seems to work).
I'm also curious to know whether there is any advantage or disadvantage to
using the NSOperationQueue to close your window instead of using
performSelector:withObject:afterDelay:
Regards
Gideon
On 12/05/2012, at 11:35 AM, Michael Crawford wrote:
> I'd like to act on -mouseDown when it occurs within the bounds of an
> NSImageView, which is a subview of a transparent overlay child window. Some
> of you may be wondering why I'm trying to do this so I'll try to explain that
> up front. There are bugs in Snow Leopard regarding the use of Core Animation
> with layer-backed views and NSOutlineView. In order to avoid these bugs,
> which I'm told Apple will not be fixing for 10.6, I'm using a transparent
> overlay to do the required animation and implement something like QuickLook
> or a preview function.
>
> I tried the following code but it resulted in really bad latency and
> coordinate issues (I think) in the parent window's event handling.
>
> #pragma mark - NSEvent Handling Methods
>
> - (void)mouseDown:(NSEvent *)event
> {
> [self.parentWindow sendEvent:event];
> #if 0
> [super mouseDown:event];
> [self.parentWindow removeChildWindow:self];
> [[NSOperationQueue mainQueue] addOperationWithBlock:^{
> [self close];
> }];
> #endif
> }
>
>
> I'm thinking that the way I'm forwarding events to the parent is wrong. So
> I'm looking for advice on implementing a proper mouse filter that can forward
> events and generate the same result as if the event was originally sent to
> the parent window.
>
> -Michael
> _______________________________________________
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/gideon%40novamind.com
>
> This email sent to gid...@novamind.com
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
