Re: Cocoa window messages in app being ported from Carbon
Re: Cocoa window messages in app being ported from Carbon
- Subject: Re: Cocoa window messages in app being ported from Carbon
- From: Kurt Bigler via Cocoa-dev <email@hidden>
- Date: Sat, 10 Aug 2019 22:43:14 -0700
On 8/10/19 10:30:45 PM, Glenn L. Austin wrote:
On Aug 10, 2019, at 10:20 PM, Kurt Bigler via Cocoa-dev
<email@hidden> wrote:
I implemented hitTest to return self in my NSView subclass. It made no
difference.
After that, I tried having hitTest call the super method to see what it
returned. For the simpler version of my window nib with only one view the
super method was returning self. For the more complex version of the window
nib with 3 views (of the same class), my NSView subclass's hitTest got called 4
times. In 2 cases the super method returned self; in 2 other cases the super
method returned 0. I did not look at further details but it seems likely that
the default implementation actually checks whether the location is in the view
and returns 0 otherwise.
-Kurt
Personally, I'd check to make sure that the coordinate system for that view (or
the underlying layer) isn't resetting it's internal origin to something other
than {0,0}. While that shouldn't necessarily affect hit testing, there's
something unusual about that view -- origin is offset, view is disabled, view
doesn't accept user interaction...?
Here's another couple bits of information though.
First keep in mind the NSSplitView splitter also is not getting clicks, and I
presumably can't mess up that view.
Second, I moved the nib and two class files into another small Cocoa-only app
and added a command to open a window from that nib. The window worked totally
fine in the other app.
So this seems to confirm that the issue has something to do with the particular
way this is a Carbon/Cocoa hybrid, and since the symptom seems to involve
activation and window ordering, it also fits the general pattern that others
have described for the problem areas.
Getting the info.plist right so I can call NSApplicationMain is one of the
things I'm trying. It is not trivial because of some dependencies in the order
of initialization that are currently creating crashes, with the initialization
order needing to change for the NSApplicationMain situation. I'm working on it.
-Kurt
_______________________________________________
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