Troubles moving from Carbon to Cocoa

Targets macOS
1

I’ve seen the blog post about Carbon being removed from 2014r3, and I’m now trying to have one of my projects running properly under Cocoa.

After removing resources I’m now able to compile and run the project, with some issues. One I’ve already reported (case 34443) about antialias=false not being honoured when drawing upscaled pictures to a canvas.

Then I’m finding myself in troubles properly setting focus/activation between document windows and floating palettes with editable list boxes. In this sense, do I have to consider a bug any behaviour different from the one I had with Carbon, and report it with FeedBack attaching a demo project, or there are new Apple-driven directives that Cocoa adhere to, and I have to find my way around?

I’ve just posted inquiry 34446 with the simplest example project. For the app I’m trying to port, this change is ruining the user experience.

I’m ready to complicate the project 34446 a little bit by adding a control to the palette, but first I’d like to here the comments on the differences found between Carbon and Cocoa execution for the simple configuration I provide.

Thanks!

2

This was discussed in this thread. The relevant code for a workaround is:

[code]
Sub Paint(g as graphics, areas() as Realbasic.Rect)
declare sub CGContextSaveGState lib “Cocoa” ( context as integer )
declare sub CGContextSetInterpolationQuality lib “Cocoa” ( context as integer, quality as integer )
declare Sub CGContextRestoreGState lib “Cocoa” ( context as integer )
Dim CGContextRef as integer = g.handle( g.HandleTypeCGContextRef )

CGContextSaveGState CGContextRef
CGContextSetInterpolationQuality CGContextRef, 1

// ---------------------- Do drawing stuff here

// ---------------------- Finished, then restore the previous state.
CGContextRestoreGState CGContextRef
end sub[/code]

3

Thanks for pointing me at that. Actually my case 34443 has been very quickly merged with 25365 and declared fixed and waiting for verification from the testing staff. So hopefully the declare-based workaround may be avoided with a future Xojo version.