> On 12. Aug 2019, at 05:26, Kurt Bigler via Cocoa-dev
> wrote:
>
> On 8/10/19 2:38:00 PM, Uli Kusterer wrote:
>>> 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), NSApplica
On 8/11/19 8:26:38 PM, Kurt Bigler via Cocoa-dev wrote:
So now I'm getting osEvt, mouseDown, and updateEvt, but no activateEvt, and so
the mouseDown only tries to activate each time. I can probably workaround that
by accepting the first click.
Adding a Carbon window event handler seems to be
On 8/11/19 8:26:38 PM, Kurt Bigler via Cocoa-dev wrote:
...Yes, doing that yields an app that is closer to working than what I've seen
yet. Mouse ups are sometimes being dropped though. And while Carbon portions
are working much better, Cocoa windows are now non-interactive, no longer
getting
On 8/10/19 2:38:00 PM, Uli Kusterer wrote:
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
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 simple
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 -hitT
> 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 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:
Th
> 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 n
> 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
___
> 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.
>
> Yo
> 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 subcl
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 mous
> 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 recei
> 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
> 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
> 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:.
>
>> Y
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 wo
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
> 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
__
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@
> 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 Carbon
22 matches
Mail list logo
