Carbon-dev closing on 6/30

Hi everyone, I’ve been informed that the carbon-dev list will be closing down this weekend, on June 30th. It’s been a pleasure and an honor to assist you with your Carbon programming issues over the years. Thank you all for your help in making Mac OS X a success! -eric

Re: Cocoa application menu, standard items (Hide Others etc)

> On Aug 25, 2018, at 12:54 PM, James Walker wrote: > >> That will work also, although I must caution you that those aren’t public >> API methods on NSApplication, so could be removed or changed in behavior in >> the future, and you probably wouldn’t be allowed to place applications using

Re: Cocoa application menu, standard items (Hide Others etc)

> On Aug 24, 2018, at 5:36 AM, Lars C. Hassing wrote: > > Based on the content of the menubar in a newly created Cocoa app in Xcode > I created the complete menubar programmatically. > Using >[NSApp setServicesMenu:servicesMenu]; >[NSApp setWindowsMenu:windowsMenu]; >[NSApp

Re: Cocoa application menu, standard items (Hide Others etc)

> On Aug 22, 2018, at 6:56 PM, Rob Petrovec wrote: > Carbon also only supported a small set of languages. Cocoa supports 100+ > localizations, including Right-To-Left localizations like Hebrew & Arabic. > So Cocoa is much more flexible & localizable compared to Carbon. Not strictly true,

Re: Cocoa application menu, standard items (Hide Others etc)

> On Aug 22, 2018, at 5:19 PM, Lars C. Hassing wrote: > > Thanks, but I would like to avoid an .xib file. > However, like you suggested I have created a new Cocoa app in Xcode, and I > look at its content as a basis for creating the menubar programmatically. > > Still, this doesn’t doesn’t

Re: Thread safety of HITheme drawing?

> On Apr 15, 2018, at 4:46 PM, Sean McBride <s...@rogue-research.com> wrote: > > On Thu, 12 Apr 2018 08:43:11 -0700, Eric Schlegel said: > >>> It is usable from an NSView that canDrawConcurrently? >> >> We make no guarantees that it is. > > Tha

Re: Image Capture crash only under High Sierra

Thanks. What’s the bug number? -eric > On Apr 12, 2018, at 10:37 AM, Admin Free <thimeau.ad...@free.fr> wrote: > > Just filed a bug. > > Le 12 avr. 18 à 01:14, Admin Free a écrit: >> Le 12 avr. 18 à 01:07, Eric Schlegel a écrit: >>>> On Apr 11, 2018, at

Re: Thread safety of HITheme drawing?

> On Apr 12, 2018, at 6:22 AM, Sean McBride wrote: > > Hi all, > > Now that NSView's canDrawConcurrently actually works in macOS 10.13 > (according to AppKit release notes), I'd like to use it in some of my custom > NSViews. > > HITheme.h says HIThemeDrawTrack() is

Re: Image Capture crash only under High Sierra

Seems likely to be a High Sierra regression. Have you filed a bug? It would be especially useful if you could try simplifying your case down to a simple test app (even better, if it’s a Cocoa app). -eric > On Apr 11, 2018, at 3:31 PM, Admin Free wrote: > > A Carbon

Re: Implementing radio menu items in Carbon

> On Sep 29, 2017, at 8:14 AM, Andreas Falkenhahn > wrote: > > I need to implement radio menu items in Carbon. I've checked the Menu Manager > reference but there isn't any mentioning of radio items. Are there any > dedicated > radio menu item APIs or do I just have

Re: Are always on top windows possible with Carbon?

> On Sep 14, 2017, at 10:53 AM, B.J. Buchalter wrote: > > Hey Eric, > > While you are talking about this stuff, is there any way to do the equivalent > of Carbon floating windows (e.g. windows that are always on top of the app’s > windows, but not on top of all the other

Re: Are always on top windows possible with Carbon?

> On Sep 13, 2017, at 10:28 AM, Andreas Falkenhahn > wrote: > > Thanks, but unfortunately I can't get it to work. The following call returns > NULL which makes SendWindowGroupBehind() fail with "windowGroupInvalidErr": > >theWindowGroup = >

Re: Are always on top windows possible with Carbon?

> On Sep 13, 2017, at 9:04 AM, James Walker wrote: > > On 9/13/2017 6:51 AM, Andreas Falkenhahn wrote: >> On Cocoa, I can just do the following to have my window appear above all >> other >> windows: >> >>[win setLevel:NSFloatingWindowLevel]; >> >> Is there any

HICocoaView use

Hi, I’m gathering data about how many Carbon applications are currently using the HICocoaView class to embed NSViews into Carbon windows. If you use HICocoaView, please reply directly to me with information about your application. I’m also interested in knowing if anyone uses layer-backed

Re: QDBeginCGContext and QDEndCGContext removed

> On Aug 17, 2017, at 1:18 PM, Robert Ball wrote: > > Hi all, > > This page: > > > https://developer.apple.com/library/content/releasenotes/General/APIDiffsMacOSX10_11/Objective-C/ApplicationServices.html > > lists the two calls QDBeginCGContext and

Re: FontToScript errors in Sierra

> On Dec 4, 2016, at 9:19 AM, Eric Schlegel <eri...@apple.com> wrote: > > >> On Dec 4, 2016, at 2:00 AM, Howard Rodstein <how...@wavemetrics.com> wrote: >> >> Possibly related: >> >> When called for Arial font on MacOS 10.12.0 and 10.12.1,

Re: FontToScript errors in Sierra

> On Dec 4, 2016, at 2:00 AM, Howard Rodstein wrote: > > Possibly related: > > When called for Arial font on MacOS 10.12.0 and 10.12.1, the > FMGetFontFamilyTextEncoding routine returns paramErr (-50). The problem does > not occur on any earlier OS version. I reported

Re: FPShowHideFontPanel crash on Sierra

> On Nov 28, 2016, at 10:49 PM, Info wrote: > > Hello Eric, > > You wrote: >> Just to set expectations properly - the issues with the color picker in this >> case are not new in Sierra. They occurred in earlier versions of mac OS >> (including El Cap) as well. I don’t

Re: FPShowHideFontPanel crash on Sierra

> On Nov 26, 2016, at 11:57 AM, Info wrote: > > Hello Jeff, > > Well the problem appear to be in the color picker control of the fonts panel, > my app does not use colored text at this point so it is not a major problem > for me. Apple knows about this and can repeat it

Re: Sierra crash in HICheckBox::GetOptimalSizeSelf / GetThemeFontInfo

Hi Lars, We’re fixing this in 10.12.1. -eric > On Oct 20, 2016, at 7:48 AM, Lars C. Hassing wrote: > > I have a checkbox (CreateCheckBoxControl) that I want to have bold text: > > CTFontUIFontType UIFontType = > HIThemeGetUIFontType(kThemeEmphasizedSystemFont); >

Re: ThemeBrush and Yosemite

On Oct 31, 2014, at 1:16 PM, Lars C. Hassing l...@ccieurope.com wrote: It seems that eg. kThemeBrushListViewEvenRowBackground is still light blue on Yosemite, where a light gray would have been expected. Are the colors going to be updated ? I don’t think we have any Radars currently

Re: ThemeBrush and Yosemite

On Oct 31, 2014, at 1:33 PM, Martin Crane martincr...@mac.com wrote: I must admit that I did notice that all DataBrowsers with alternating lines enabled are blue on Yosemite, although I didn’t file a bug, I did now (rdar://18840953 rdar://18840953). It’s a shame, as DataBrowser already