Re: Cocoa window messages in app being ported from Carbon

[Kurt Bigler via Cocoa-dev]

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 
 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 (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

Re: Cocoa window messages in app being ported from Carbon

[Kurt Bigler via Cocoa-dev]

On 8/10/19 10:20:34 PM, Kurt Bigler via Cocoa-dev wrote:

On 8/10/19 3:04:13 PM, Rob Petrovec wrote:
Either way, instead of going back & forth on this, why don’t you try 
implementing an NSView subclass without hitTest returning self and see if that 
view gets -mouseDown:.  Then override -hitTest in the view to return self and 
see that the view does get -mouseDown.  Then you will see that I am correct.  
Thanks.


It is always worth trying something trivial regardless of arguments.

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.


Because of the other behavior I reported re Window resizing and splitter 
dragging not working once the window is frontmost, I implemented 
acceptsFirstMouse, returning YES.


The result is that my view now receives mouseDown in the same circumstances in 
which the other functions work:  when the window is not frontmost.


So it seems somehow the window is being disabled once it is brought to front, 
either by a click or programmatically via makeKeyAndOrderFront.


Thanks to all for the fantastic help so far, on the weekend no less.  I might 
have been utterly stuck for a long time without it.  I'm still stuck but I have 
a couple good things to try.


-Kurt

___

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

Re: Cocoa window messages in app being ported from Carbon

[Glenn L. Austin via Cocoa-dev]

> On Aug 10, 2019, at 10:20 PM, Kurt Bigler via Cocoa-dev 
>  wrote:
> 
> On 8/10/19 3:04:13 PM, Rob Petrovec wrote:
>>> On Aug 10, 2019, at 3:38 PM, Uli Kusterer  
>>> wrote:
>>> 
 On 10. Aug 2019, at 19:03, Rob Petrovec via Cocoa-dev 
 mailto:cocoa-dev@lists.apple.com>> wrote:
 
> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev 
> mailto:cocoa-dev@lists.apple.com>> wrote:
> 
> The NSView subclasses involved are receiving drawRect: messages but are 
> not receiving mouseDown:.
You need to implement NSView -hitTest: to get mouseDown events.
>>> 
>>> 
>>> No, the default implementation does all you need and is perfectly fine.
>>  I’ll repeat myself, the OP is not getting mouseDown on his NSView 
>> subclass.  So it isn’t perfectly fine in this case.  If he wants mouseDown 
>> events in his NSView subclass he needs to override hitTest to return self, 
>> or whatever subview he wants to get mouseDown.  There is no avoiding it.
>>  The default implementation of NSView hitTest just loops through it’s 
>> visible subviews and calls hitTest on each one that the passed in point is 
>> inside.  It is obviously recursive.  If any of the subviews return a valid 
>> view from their implementations of -hitTest: then that valid view is 
>> returned up the call stack. Whatever view is returned from -hitTest: at the 
>> top of the call stack will get first crack at the mouseDown event.  Since 
>> NSViews don’t have subviews by default, let alone one that returns a valid 
>> view from hitTest, then the default implementation of an NSView -hitTest 
>> will return nil.  Semantics, I know...
>>  Either way, instead of going back & forth on this, why don’t you try 
>> implementing an NSView subclass without hitTest returning self and see if 
>> that view gets -mouseDown:.  Then override -hitTest in the view to return 
>> self and see that the view does get -mouseDown.  Then you will see that I am 
>> correct.  Thanks.
> 
> It is always worth trying something trivial regardless of arguments.
> 
> 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...?

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><


___

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

Re: Cocoa window messages in app being ported from Carbon

[Kurt Bigler via Cocoa-dev]

On 8/10/19 3:04:13 PM, Rob Petrovec wrote:




On Aug 10, 2019, at 3:38 PM, Uli Kusterer  wrote:


On 10. Aug 2019, at 19:03, Rob Petrovec via Cocoa-dev mailto:cocoa-dev@lists.apple.com>> wrote:


On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev mailto:cocoa-dev@lists.apple.com>> wrote:

The NSView subclasses involved are receiving drawRect: messages but are not 
receiving mouseDown:.

You need to implement NSView -hitTest: to get mouseDown events.



No, the default implementation does all you need and is perfectly fine.

I’ll repeat myself, the OP is not getting mouseDown on his NSView 
subclass.  So it isn’t perfectly fine in this case.  If he wants mouseDown 
events in his NSView subclass he needs to override hitTest to return self, or 
whatever subview he wants to get mouseDown.  There is no avoiding it.

The default implementation of NSView hitTest just loops through it’s 
visible subviews and calls hitTest on each one that the passed in point is 
inside.  It is obviously recursive.  If any of the subviews return a valid view 
from their implementations of -hitTest: then that valid view is returned up the 
call stack. Whatever view is returned from -hitTest: at the top of the call 
stack will get first crack at the mouseDown event.  Since NSViews don’t have 
subviews by default, let alone one that returns a valid view from hitTest, then 
the default implementation of an NSView -hitTest will return nil.  Semantics, I 
know...

Either way, instead of going back & forth on this, why don’t you try 
implementing an NSView subclass without hitTest returning self and see if that view 
gets -mouseDown:.  Then override -hitTest in the view to return self and see that 
the view does get -mouseDown.  Then you will see that I am correct.  Thanks.


It is always worth trying something trivial regardless of arguments.

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


___

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

Re: Cocoa window messages in app being ported from Carbon

[Richard Charles via Cocoa-dev]

> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev 
>  wrote:
> 
> I've just started implementing the Cocoa windows.  The NSView subclasses 
> involved are receiving drawRect: messages but are not receiving mouseDown:.

It seems to me like your window is not setup properly or the view is not 
properly configured in the window.

NSApplication dispatches a mouseDown event to NSWindow and the window 
dispatches the event to the NSView. The responder chain is not involved unless 
using the default implementation which simply passes the message to the next 
responder. The method acceptsFirstResponder does not play a roll in mouseDown.

You could subclass NSWindow and override sendEvent: to see what is happening 
during a mouse down.

#0  0x00011355 in -[MyView mouseDown:]
#1  0x7fff8d7db24f in -[NSWindow(NSEventRouting) 
_handleMouseDownEvent:isDelayedEvent:] ()
#2  0x7fff8d7d7a6c in -[NSWindow(NSEventRouting) 
_reallySendEvent:isDelayedEvent:] ()
#3  0x7fff8d7d6f0a in -[NSWindow(NSEventRouting) sendEvent:] ()
#4  0x7fff8d65b681 in -[NSApplication(NSEvent) sendEvent:] ()
#5  0x7fff8ced6427 in -[NSApplication run] ()
#6  0x7fff8cea0e0e in NSApplicationMain ()

--Richard Charles

___

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

Re: Cocoa window messages in app being ported from Carbon

[Richard Charles via Cocoa-dev]

> On Aug 10, 2019, at 3:21 PM, Rob Petrovec via Cocoa-dev 
>  wrote:
> 
> So he needs to implement hitTest to get mouseDown events.

I just made a new Cocoa App project with a custom view. I did not implement 
hitTest:. The view receives mouseDown events just fine.

--Richard Charles

___

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

Re: Cocoa window messages in app being ported from Carbon

[Glenn L. Austin via Cocoa-dev]

> On Aug 10, 2019, at 2:02 PM, Kurt Bigler via Cocoa-dev 
>  wrote:
> 
> On 8/10/19 2:16:41 AM, Uli Kusterer wrote:
>> The Cocoa event handling code uses CarbonEvents under the hood. AFAIR, you 
>> can switch to the Cocoa event loop right away, and Carbon windows will just 
>> keep working.
> 
> You're saying some interesting things.  Given the demise of 32-bit, if this 
> is still true, maybe the rumored internal 64-bit Carbon implementation might 
> be deployed behind the scenes to support any portions of Cocoa that still 
> depend on Carbon.  None of that matters for now since obviously I'm doing the 
> port on an older macOS.

"Carbon" seems to have split pretty early-on in the transition to Cocoa-only 
into what I personally called "Core" and "HIToolbox." Most of the 
underpinnings, such as CF, events, and menus, were brought up to 64-bit as a 
part of "Core," it was the main parts of HIToolbox around windows, controls, 
and views that directly "competed" with AppKit and never made the full 
transition to 64-bit. I *suspect* that underlying the Cocoa window system sat 
on top of the Carbon window system until the Metal version was available.

If you send a CarbonEvent that corresponds to a Cocoa event, the Cocoa event 
"engine" will accept and handle it - vice versa with Cocoa events and 
CarbonEvents.  NSRunLoop is sitting on top of CFRunLoop - so if your Carbon 
event code ever calls CFRunLoopStop, your entire event engine will just stop. 
Never call CFRunLoopStop unless you want to quit - or you've nested the runloop 
inside of another - like for modal dialogs.

I did much of the porting of a major application to a mixed Carbon and Cocoa 
application and spent a lot of time working on getting events, menus, views, 
and windows to "just work." They did, but there was a *lot* of code to 
implement work-arounds for the most egregious of Carbon/Cocoa interaction 
issues.


-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><



___

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

Re: Cocoa window messages in app being ported from Carbon

[Rob Petrovec via Cocoa-dev]

> On Aug 10, 2019, at 3:38 PM, Uli Kusterer  
> wrote:
> 
>> On 10. Aug 2019, at 19:03, Rob Petrovec via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>> 
>>> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev 
>>> mailto:cocoa-dev@lists.apple.com>> wrote:
>>> 
>>> The NSView subclasses involved are receiving drawRect: messages but are not 
>>> receiving mouseDown:.
>>  You need to implement NSView -hitTest: to get mouseDown events.
>> 
>> —Rob
> 
> 
> No, the default implementation does all you need and is perfectly fine.
I’ll repeat myself, the OP is not getting mouseDown on his NSView 
subclass.  So it isn’t perfectly fine in this case.  If he wants mouseDown 
events in his NSView subclass he needs to override hitTest to return self, or 
whatever subview he wants to get mouseDown.  There is no avoiding it.

The default implementation of NSView hitTest just loops through it’s 
visible subviews and calls hitTest on each one that the passed in point is 
inside.  It is obviously recursive.  If any of the subviews return a valid view 
from their implementations of -hitTest: then that valid view is returned up the 
call stack. Whatever view is returned from -hitTest: at the top of the call 
stack will get first crack at the mouseDown event.  Since NSViews don’t have 
subviews by default, let alone one that returns a valid view from hitTest, then 
the default implementation of an NSView -hitTest will return nil.  Semantics, I 
know...

Either way, instead of going back & forth on this, why don’t you try 
implementing an NSView subclass without hitTest returning self and see if that 
view gets -mouseDown:.  Then override -hitTest in the view to return self and 
see that the view does get -mouseDown.  Then you will see that I am correct.  
Thanks.

—Rob


___

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

Re: Cocoa window messages in app being ported from Carbon

[Kurt Bigler via Cocoa-dev]

On 8/10/19 2:21:05 PM, Rob Petrovec wrote:



On Aug 10, 2019, at 3:12 PM, Kurt Bigler  wrote:

On 8/10/19 10:03:00 AM, Rob Petrovec wrote:

On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev 
 wrote:

The NSView subclasses involved are receiving drawRect: messages but are not 
receiving mouseDown:.



You need to implement NSView -hitTest: to get mouseDown events.


I have 5 working Cocoa apps, and none implement hitTest.  It is apparently needed 
for special circumstances, per the docs "to have a view object hide mouse-down 
events from its subviews”.

The OP said NSView subclasses.  Not NSControl.  So he needs to implement 
hitTest to get mouseDown events.  If you read the sentence before the line you 
quoted:  "This method is used primarily by an NSWindow object to determine 
which view should receive a mouse-down event.”.  NSView returns nil from hitTest by 
default, so raw NSViews don’t get mouseDown events.


I am the OP.  :)

I do have on this Mac 5 working Cocoa apps with at least one NSView subclass 
that receives mouseDown events but does not implement hitTest.  In short I have 
never implemented hitTest, and have always had my NSView subclasses receive 
mouseDown events.  This hybrid app situation is the first exception.


So maybe nil from hitTest has a special interpretation.

-Kurt



—Rob






___

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

Re: Cocoa window messages in app being ported from Carbon

[Uli Kusterer via Cocoa-dev]

> On 10. Aug 2019, at 23:21, Rob Petrovec via Cocoa-dev 
>  wrote:
> 
>> On Aug 10, 2019, at 3:12 PM, Kurt Bigler  wrote:
>> 
>> On 8/10/19 10:03:00 AM, Rob Petrovec wrote:
 On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev 
  wrote:
 
 The NSView subclasses involved are receiving drawRect: messages but are 
 not receiving mouseDown:.
>> 
>>> You need to implement NSView -hitTest: to get mouseDown events.
>> 
>> I have 5 working Cocoa apps, and none implement hitTest.  It is apparently 
>> needed for special circumstances, per the docs "to have a view object hide 
>> mouse-down events from its subviews”.
>   The OP said NSView subclasses.  Not NSControl.  So he needs to 
> implement hitTest to get mouseDown events.  If you read the sentence before 
> the line you quoted:  "This method is used primarily by an NSWindow object to 
> determine which view should receive a mouse-down event.”.  NSView returns nil 
> from hitTest by default, so raw NSViews don’t get mouseDown events.
> 
> —Rob

Have you actually tried creating a custom NSView, because this is simply not 
the behavior I've observed in the last 10+ years as a Cocoa UI programmer.

The only reason to override hitTest is if you want a view through which clicks 
pass through under certain circumstances (i.e., it has a non-rectangular shape 
or a built-in shadow through which clicks should pass to underlying views) or 
if you want to handle clicks that are actually destined for one of your sub 
views.

A plain NSView will do all the correct hit-testing for subviews and itself by 
default. 

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

___

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

Re: Cocoa window messages in app being ported from Carbon

[Uli Kusterer via Cocoa-dev]

> On 10. Aug 2019, at 19:03, Rob Petrovec via Cocoa-dev 
>  wrote:
> 
>> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev 
>>  wrote:
>> 
>> The NSView subclasses involved are receiving drawRect: messages but are not 
>> receiving mouseDown:.
>   You need to implement NSView -hitTest: to get mouseDown events.
> 
> —Rob


No, the default implementation does all you need and is perfectly fine.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

___

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

Re: Cocoa window messages in app being ported from Carbon

[Uli Kusterer via Cocoa-dev]

> On 10. Aug 2019, at 23:02, Kurt Bigler  wrote:
> Currently if I call NSApplicationMain instead of my regular Carbon event loop 
> (which is based on ReceiveNextEvent), NSApplicationMain returns immediately.  
> I don't call NSApplicationMain immedately because there is scads of 
> initialization that I do without relation to incoming events.

 NSApplicationMain looks at your Info.plist to decide which Cocoa NIB to load 
at startup and what your NSPrincipalClass is (usually NSApplication). If you 
haven't set up your app as a proper Cocoa app, NSApplicationMain will be 
unhappy and won't work. Every time I've ported a Carbon app to Cocoa so far, I 
basically moved the main() function's contents (except the call to 
RunApplicationEventLoop()) into applicationDidFinishLaunching: etc. in an app 
delegate. Then it usually worked as before.

 ReceiveNextEvent() seems a bit of an odd choice. In general, you want 
RunApplicationEventLoop() and timers, performSelector:afterDelay:0.0 or threads 
to get processing time reliably for other things during the event loop.

> This makes me wonder about NSApplicationLoad, which I do call.

 NSApplicationLoad() is basically the "turn a Carbon app into enough of a Cocoa 
app to run Cocoa code"-call, so shouldn't be needed in a fully Cocoa app. And 
your guess why NSApplicationMain didn't work was pretty close, I think.

Cheers,
-- Uli Kusterer
http://www.zathras.de

___

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

Re: Cocoa window messages in app being ported from Carbon

[Rob Petrovec via Cocoa-dev]

> On Aug 10, 2019, at 3:12 PM, Kurt Bigler  wrote:
> 
> On 8/10/19 10:03:00 AM, Rob Petrovec wrote:
>>> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev 
>>>  wrote:
>>> 
>>> The NSView subclasses involved are receiving drawRect: messages but are not 
>>> receiving mouseDown:.
> 
>>  You need to implement NSView -hitTest: to get mouseDown events.
> 
> I have 5 working Cocoa apps, and none implement hitTest.  It is apparently 
> needed for special circumstances, per the docs "to have a view object hide 
> mouse-down events from its subviews”.
The OP said NSView subclasses.  Not NSControl.  So he needs to 
implement hitTest to get mouseDown events.  If you read the sentence before the 
line you quoted:  "This method is used primarily by an NSWindow object to 
determine which view should receive a mouse-down event.”.  NSView returns nil 
from hitTest by default, so raw NSViews don’t get mouseDown events.

—Rob


___

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

Re: Cocoa window messages in app being ported from Carbon

[Kurt Bigler via Cocoa-dev]

On 8/10/19 10:03:00 AM, Rob Petrovec wrote:

On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev 
 wrote:

The NSView subclasses involved are receiving drawRect: messages but are not 
receiving mouseDown:.



You need to implement NSView -hitTest: to get mouseDown events.


I have 5 working Cocoa apps, and none implement hitTest.  It is apparently 
needed for special circumstances, per the docs "to have a view object hide 
mouse-down events from its subviews".


-Kurt
___

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

Re: Cocoa window messages in app being ported from Carbon

[Kurt Bigler via Cocoa-dev]

On 8/10/19 2:16:41 AM, Uli Kusterer wrote:

The Cocoa event handling code uses CarbonEvents under the hood. AFAIR, you can 
switch to the Cocoa event loop right away, and Carbon windows will just keep 
working.


You're saying some interesting things.  Given the demise of 32-bit, if this is 
still true, maybe the rumored internal 64-bit Carbon implementation might be 
deployed behind the scenes to support any portions of Cocoa that still depend on 
Carbon.  None of that matters for now since obviously I'm doing the port on an 
older macOS.


However, also you make me realize that I didn't have it pinned down what "switch 
to the Cocoa event loop" might prove to mean.  I assumed it meant calling 
NSApplicationMain.  I did try that already.


Currently if I call NSApplicationMain instead of my regular Carbon event loop 
(which is based on ReceiveNextEvent), NSApplicationMain returns immediately.  I 
don't call NSApplicationMain immedately because there is scads of initialization 
that I do without relation to incoming events.


This makes me wonder about NSApplicationLoad, which I do call.  It would seem 
offhand that one calls NSApplicationLoad only because one is not calling 
NSApplicationMain, but now I'm in the position of possibly needing both. 
Without calling NSApplicationLoad my Cocoa menu bar does not come up.  The 
NSBundle loadNibNamed:... call that loads the menus is done shortly after where 
NSApplicationLoad is called and seems to depend on it.  Maybe there is some 
other application initialization structures I need to have in place. 
NSApplicationMain "loads the main nib file from the application’s main bundle", 
and maybe depends on certain standard things being in place which are not in 
place in this app.  (I have no main nib file as such.)  All of which would then 
be part of what "switch to the Cocoa event loop" means.  I do have an 
AppDelegate but it is not doing much yet.



Incidentally Cocoa menus and modal dialogs are already working, so that is a 
sign that Cocoa events are to some degree alive and well.


  Modal Cocoa dialogs run their own Cocoa event loop, that's why they work  


Yes I do call runModalForWindow:.


It's also the most tested part of Carbon/Cocoa mixing, as that's what Apple used 
for NSOpenPanel & Co. Cocoa menus are Carbon menus under the hood as well, NeXT 
had no Mac-style menu bar (they had windows containing the deprecated NSMenuView), 
so that was based on the Carbon code from the start. There's even a private 
_NSGetCarbonMenu() call that Apple uses internally to get at the MenuRef backing an 
NSMenu.

  Just be aware that there are various small bugs and issues that make it 
impractical to ship an application that mixes modeless Carbon and Cocoa windows,


Well it doesn't really make sense to ship an application with Carbon in it at 
this point, since after all getting rid of Carbon very quickly is the reason for 
the current porting effort.



mainly to do with window activation/ordering and application 
activation/ordering. What works (since that is what AppKit used itself) is 
modal Cocoa windows in an otherwise Carbon app. HICocoaView worked for some 
views, but not for all of them. Modeless windows will randomly re-order, 
sometimes causing the current modal window to end up behind another window and 
blocking the user from interacting with it.


Thanks, it is good to know what issues are in store for me.

-Kurt


Cheers,
-- Uli Kusterer


___

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

Re: Cocoa window messages in app being ported from Carbon

[Rob Petrovec via Cocoa-dev]

> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev 
>  wrote:
> 
> The NSView subclasses involved are receiving drawRect: messages but are not 
> receiving mouseDown:.
You need to implement NSView -hitTest: to get mouseDown events.

—Rob


___

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

Re: Cocoa window messages in app being ported from Carbon

[Uli Kusterer via Cocoa-dev]

On 10. Aug 2019, at 11:16, Uli Kusterer via Cocoa-dev 
 wrote:
> So this mixing is an ideal approach for slowly porting, but will not get you 
> anything shippable until your UI is fully Carbon.

fully Cocoa. Sorry.
___

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

Re: Cocoa window messages in app being ported from Carbon

[Uli Kusterer via Cocoa-dev]

> On 10. Aug 2019, at 08:24, Kurt Bigler via Cocoa-dev 
>  wrote:
> As part of a process of porting an app from Carbon to Cocoa I'm needing to 
> have Carbon and Cocoa windows present at the same time.  The Carbon event 
> loop is therefore still in place.

The Cocoa event handling code uses CarbonEvents under the hood. AFAIR, you can 
switch to the Cocoa event loop right away, and Carbon windows will just keep 
working.

> I've just started implementing the Cocoa windows.  The NSView subclasses 
> involved are receiving drawRect: messages but are not receiving mouseDown:.
> 
> Incidentally Cocoa menus and modal dialogs are already working, so that is a 
> sign that Cocoa events are to some degree alive and well.

 Modal Cocoa dialogs run their own Cocoa event loop, that's why they work  
It's also the most tested part of Carbon/Cocoa mixing, as that's what Apple 
used for NSOpenPanel & Co. Cocoa menus are Carbon menus under the hood as well, 
NeXT had no Mac-style menu bar (they had windows containing the deprecated 
NSMenuView), so that was based on the Carbon code from the start. There's even 
a private _NSGetCarbonMenu() call that Apple uses internally to get at the 
MenuRef backing an NSMenu.

 Just be aware that there are various small bugs and issues that make it 
impractical to ship an application that mixes modeless Carbon and Cocoa 
windows, mainly to do with window activation/ordering and application 
activation/ordering. What works (since that is what AppKit used itself) is 
modal Cocoa windows in an otherwise Carbon app. HICocoaView worked for some 
views, but not for all of them. Modeless windows will randomly re-order, 
sometimes causing the current modal window to end up behind another window and 
blocking the user from interacting with it.

 So this mixing is an ideal approach for slowly porting, but will not get you 
anything shippable until your UI is fully Carbon.

Cheers,
-- Uli Kusterer
___

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

Cocoa window messages in app being ported from Carbon

[Kurt Bigler via Cocoa-dev]

Hi,

As part of a process of porting an app from Carbon to Cocoa I'm needing to have 
Carbon and Cocoa windows present at the same time.  The Carbon event loop is 
therefore still in place.


I've just started implementing the Cocoa windows.  The NSView subclasses 
involved are receiving drawRect: messages but are not receiving mouseDown:.


Incidentally Cocoa menus and modal dialogs are already working, so that is a 
sign that Cocoa events are to some degree alive and well.


There is one other curious symptom.  The Cocoa windows can be resized from the 
corner, and in the window with a split view, the splitter can be dragged. 
However, either can only be done when the window involved is *not* frontmost. 
(Of course immediately after the drag that window becomes frontmost so a similar 
drag can not be repeated on the same window.)


In theory obviously I can rip out the Carbon event stuff and just rebuild from 
the ground up, but I'm hoping I can solve these issues since I foresee a more 
gracious process this way.


Thanks in advance for any help.

-Kurt Bigler
___

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