Carbon Combobox on Yosemite

carbon version

cocoa version

The above two image is a screen shot of my application compile using the latest version of Xojo and running on Yosemite.

notice the dropdown section that look really weird on Carbon.

Richard, the images are not displayed.

Julen

carbon

cocoa

I have seen something similar a few years ago with 4th Dimension on Win 7…
Seems like Carbon time is over :frowning:

it only appear like this in Yosemite… so i guess if my client is using Yosemite, i need to move them off carbon.

Just to report what I observed so far:

  • This is on a Retina MBP with OSX 10.10.
  • ComboBoxes are dynamically generated members of a control set.
  • Built for Cocoa.
  • The strange step between the text input area and the drop-down arrow on the right of the control is only visible when the control is disabled and any text has been cleared.
  • When the combo is enabled and text is added, then the combo looks ok.

I have a computed property BackColor and its Set method looks like this:

[code]Set
mBackColor = value

#If TargetCocoa
Try
Dim c As NSColorMBS = NSColorMBS.colorWithDeviceRGB(value.Red/255,value.Green/255,value.Blue/255)
Dim n As NSComboBoxMBS = Me.NSComboBoxMBS
If n <> Nil Then
n.drawsBackground = True
n.backgroundColor = c
End If
End Try
#EndIf
End Set
[/code]

I see this glitch also in AppWrapper 2.5 - but there it appears on a retina display and on a standard resolution display in the same (wrong) way:

Unfortunately I have not yet been able to reproduce this in a new project. I am still trying to find out what is different in my code that causes this glitch.

Check the height of your ComboBox.

Default height for comboboxes (Cocoa, Yosemite) seems to be 20 and this is what I am setting it to. I must be missing something in my code …

It was the same code, same target (Cocoa) and on Mavericks it looked fine, but on Yosemite not.

strange… cocoa look ok for me… not carbon though… mine on carbon look exactly like your image above.

I’m still hit by this issue, since OSX 10.10 and for the good of me, I am not able to find its cause, neither am I able to reproduce it in a new project.

  • This is on a Retina MBP with OSX 10.10.
  • ComboBoxes are dynamically generated members of a control set.
  • Built for Cocoa.
  • The strange step between the text input area and the drop-down arrow on the right of the control is only visible when the control is disabled and any text has been cleared.
  • When the combo is enabled and text is added, then the combo looks ok.

I checked allover in my code, whether I am changing height somewhere. I hardcoded setting the height and checked in debugger - I can’t get this fixed.

It works fine on Mavericks but since Yosemite I have this problem.

Any ideas, anyone?

Have you tried instead of clearing the text entirely, to use a space or non breakable space ? It may suffice for the control to be happy. Just a thought, since I cannot reproduce this here…

Thanks Michel! I think I just caught this one, occurs only on OSX 10.10 when retina is enabled:

  1. Add a combobox to a cocoa project and disable it
  2. Add a build script to enable retina resolution
  3. Run the project and zoom to the control: the surrounding border is not straight (see picture above)

build script:

[code] Dim App As String = CurrentBuildLocation + “/”"" + CurrentBuildAppName + “.app”""
Call DoShellCommand("/usr/bin/defaults write " _

  • App + “/Contents/Info ““NSHighResolutionCapable”” YES”)
    [/code]

Can anyone reproduce it? If yes, then I will file a bug report (after my lunch break)

feedback://showreport?report_id=36594

I would advise doing so sooner rather than later, Apple is really chopping off functionality for older APIs (even 32-Bit saw some functionality removed in Yosie).

[quote=142397:@Oliver Osswald]It works fine on Mavericks but since Yosemite I have this problem.
Any ideas, anyone?[/quote]

You may need to use some declares to alter the FrameSize of the control. I found that on Retina if you use Tick Marks with a slider, you have to use the declare otherwise the top 1-pixel is clipped, no matter what size the control is set to.
feedback://showreport?report_id=35011

Sub setFrameSize(extends r as rectControl, newSize as NSSize) #if TargetCocoa then declare sub setFrameSize lib appKit selector "setFrameSize:" ( NSControlHandle as integer, value as NSSize ) setFrameSize( r.handle, newSize ) #endif End Sub

and pass it a NSSize of the same dimensions as the Xojo control.

cSlider = slider( w.control( l ) ) rectControl( w.control( l ) ).setFrameSize nsSizeMake( cSlider.width, cSlider.height )

[quote=142543:@Sam Rowlands]I would advise doing so sooner rather than later, Apple is really chopping off functionality for older APIs (even 32-Bit saw some functionality removed in Yosie).
[/quote]

Since no ones mentioned it here, this was in the Xcode 6 release notes:

[quote]Deprecations
Carbon Tools

Tools that support Carbon development are deprecated with Xcode 6. These include: BuildStrings, GetFileInfo, SplitForks, ResMerger, UnRezWack, MergePef, RezWack, SetFile, RezDet, CpMac, DeRez, MvMac, and Rez. (10344338)
[/quote]

Carbon probably doesn’t have much time left.

[quote=142543:@Sam Rowlands]I would advise doing so sooner rather than later, Apple is really chopping off functionality for older APIs (even 32-Bit saw some functionality removed in Yosie).

You may need to use some declares to alter the FrameSize of the control. I found that on Retina if you use Tick Marks with a slider, you have to use the declare otherwise the top 1-pixel is clipped, no matter what size the control is set to.
feedback://showreport?report_id=35011

Sub setFrameSize(extends r as rectControl, newSize as NSSize) #if TargetCocoa then declare sub setFrameSize lib appKit selector "setFrameSize:" ( NSControlHandle as integer, value as NSSize ) setFrameSize( r.handle, newSize ) #endif End Sub

and pass it a NSSize of the same dimensions as the Xojo control.

cSlider = slider( w.control( l ) ) rectControl( w.control( l ) ).setFrameSize nsSizeMake( cSlider.width, cSlider.height )[/quote]

I guess “NSSize” and “appkit” are parts of macoslib? I’m getting a ‘Cant find type’ and ‘This item does not exist’ error here…

Case 35011 must be private, I guess?

[quote=142543:@Sam Rowlands]<…>
You may need to use some declares to alter the FrameSize of the control. <…>[/quote]
I was wondering if I could use MBS plugins to do this, and tried the following code, as a method to a subclassed combobox:

Sub imSetFrameSize(w As Double, h As Double) #If TargetCocoa Me.NSViewMBS.setFrameSize(w,h) #EndIf End Sub

It runs without error, but it does not change anything on the combobox, they still look odd when running empty, disabled and retina-enabled on Yosemite.

NSSize is a structure often used in OS X declares, consisting of width and height as Singles.
Appkit is the main FrameWork of the Cocoa Layer. You may as well use “Cocoa.framework”

[quote=142550:@Oliver Osswald]I guess “NSSize” and “appkit” are parts of macoslib? I’m getting a ‘Cant find type’ and ‘This item does not exist’ error here…

Case 35011 must be private, I guess?[/quote]
Sorry about that, NSSize is just a structure consisting of two single.

width as single height as single

AppKit is a constant I use with AppKit functionality, the constant is just “AppKit”.

And the feedback was made in relation to a r3 Alpha, I’ll ask it to be made public.

And… It doesn’t solve this issue, I guess the next step is to open Xcode on a Yosemite machine, create a new window, add a combo box and configure it, then run the window in the Cocoa simulator. It may be a bug in Yosemite…

Carbon has been on life support for some time
They’re now starting to turn its oxygen supply off and pulling the plug won’t be far behind