On 11/24/19 1:37:17 PM, Allan Odgaard via Cocoa-dev wrote:
On 24 Nov 2019, at 22:28, Kurt Bigler via Cocoa-dev wrote:
[…] The idea for least inefficiency given the global updating pass is to defer
(akin to lazy evaluation) the actual menu item updating until the last
possible moment
I have an app in final stages of conversion from Carbon to Cocoa. It uses a
legacy architecture for menu item enabling that originated with the Think Class
Library. It is not really practical to consider redoing the entire
implementation so I am retrofitting it. The method used is to make a
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
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
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
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
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 over
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&g
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
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
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
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
I would like to be able to traverse the top-level object list in a macOS nib
without instantiating the objects. But I'd like to be able to get at the
attributes of each top-level item to decide whether to instantiate it, and then
of course to control instantiation on an object-by-object basis
13 matches
Mail list logo
