I need to assign a background color to the container control where is says “Plan 2” because I have a visibility problem with the controls below when scrolling. According to the docs Color.FillColor should do the trick. But at least on macOS BS the color is a bit darker. What is the correct color?
[quote=496085:@Beatrix Willius]I need to assign a background color to the container control where is says “Plan 2” because I have a visibility problem with the controls below when scrolling. According to the docs Color.FillColor should do the trick. But at least on macOS BS the color is a bit darker. What is the correct color?
[/quote]
It could be that the background colour can no longer be represented by integers.
You might be able to do this by using NSVisualEffectMBS. Here is some code that I use to switch off the translucent effect in modal dialogs on Big Sur. You might be able to use parts of this to do what you want.
[code]#If TargetMacOS Then
Const kNSVisualEffectViewMaterialWindowBackground = 12
Dim nsWindowObj As NSWindowMBS
Dim appearanceObj As NSAppearanceMBS
Dim nsVisualEffectViewObj As NSVisualEffectViewMBS
Dim caLayerObj As CALayerMBS
nsWindowObj = Self.NSWindowMBS
'set the window appearance to aqua so that the controls look the same as non modal windows (especially important for edit field backgrounds)
appearanceObj = NSAppearanceMBS.appearanceNamed(NSAppearanceMBS.NSAppearanceNameAqua)
If appearanceObj <> Nil Then
NSAppearanceMBS.setAppearance(Self, appearanceObj)
End If
'set the background colour
If Self.HasBackColor = False Then
'we don’t have a custom background colour
'set the window background to look the same as a non modal window
nsVisualEffectViewObj = New NSVisualEffectViewMBS(0, 0, Self.Width, Self.Height)
nsVisualEffectViewObj.autoresizesSubviews = true
nsVisualEffectViewObj.material = kNSVisualEffectViewMaterialWindowBackground
nsVisualEffectViewObj.autoresizingMask = NSViewMBS.NSViewWidthSizable + NSViewMBS.NSViewHeightSizable
nsWindowObj.contentView.addSubview(nsVisualEffectViewObj, -1, nil)
Else
'we do have a custom background colour
'set the background colour by creating a core animation layer with our background colour
nsWindowObj.contentView.wantsLayer = True
caLayerObj = nsWindowObj.contentView.layer
If caLayerObj <> Nil Then
caLayerObj.backgroundColor = CGColorMBS.CreateDeviceRGB(Self.BackColor.Red / 255, Self.BackColor.Green / 255, Self.BackColor.Blue / 255, 1.0)
End If
End If
#Endif[/code]
The background color is tricky on macOS because of a number of reasons. First is that Apple likes to dabble with patterns for their backgrounds. [quote=496089:@Kevin Gale]It could be that the background colour can no longer be represented by integers.[/quote]
Right. To expand on that, Apple uses floating point numbers between 0 and 1 and technically support billions of colors.
And then there is the translucency thing they added when dark mode was introduced… even in light mode.
for my current app (at windows) i use this Color.FillColor as template and have a config window for self selection.
The correct color is a dynamic color that’s designed to be used with a NSBox (Xojo calls these GroupBoxes). Or as Kevin suggests, you can use a NSVisualEffectView.
When scrolling, the “Plan” view is transparent, so the controls from the view below, bleed through right.
The solution is to clip a scroll document (the view that moves with all the controls on it), by assigning that view into a another.
Let me try and explain it a different way. Take a canvas and name it “clipView” place it where you want the scrollable content to “show”.
Take another canvas and name it “scrollDocument”, on this canvas layout your UI.
At run time, move the scrollDocument canvas so it’s atop the clipView canvas and set it’s parent to the clipView. When you scroll, simply adjust the top of the scrollDocument.
I hope that this makes sense.
@Kevin Gale: thanks, tried the code. I can’t see a difference.
@Greg O’Lone: translucency is depressing. It’s absolutely useless and on macOS BS it’s more distracting than ever.
@Sam Rowlands : yup, you describe the problem. I use stack views from Martin Trippensee. That should take care of the bleed through. Unfortunately, Xojo doesn’t always get the memo. So far the problem only shows up on BS. I have another window where I don’t get the bleed through.
@Markus Rauch: have you tried the FillColor on BS? The color is much darker than the default window color.
I found another solution: default color be hanged. I define my own color and use that all over the window. Urghh… my window is totally foobared in DarkMode on BS. The IDE doesn’t change the windows back when changing from DarkMode to LightMode. Another BS bug.
Yup, before using a background color DarkMode was okay. And now even the toolbar is foobared. Back to square one.
Why is the window looking like below when using background colours:
I don’t get it.
It may not be a Xojo problem, although it would help if Xojo supported native scrollviews!
I don’t care who is the culprit. Working with windows that have lots of containers is way better than having no containers. Still it’s not fun with DarkMode and that blasted translucency. If all else fails I’ll add the container with the plan name to the stack views.
Do you have a simple project that demonstrates the problem?
@Kevin Gale: I wish. The window has 26 classes and containers.
One problem solved: Kevin’s code looks okay in Light Mode and foobars the window in DarkMode. Even if I use black as background colour.
[quote=496155:@Beatrix Willius]@Kevin Gale: I wish. The window has 26 classes and containers.
One problem solved: Kevin’s code looks okay in Light Mode and foobars the window in DarkMode. Even if I use black as background colour.[/quote]
For Dark Mode, you might need to use a different NSAppearanceMBS value or a different material constant (we dont bother supporting dark mode). MBS has some of the material constants defined in his class but some were missing so I had to look them up in Apples developer documentation.
The code I provided was something I came up with at the end of last week to address the following issues we noticed with modal dialogs on Big Sur so you might not need it all:
Edit Field backgrounds were transparent rather than white which made it harder to tell if a field was enabled or not (first part of the code).
The background was translucent rather than the same colour as non modal windows and it wasnt possible to set a custom background colour (second part of the code).
We are applying the changes to an entire window but it is my understanding that the properties can be applied to individual controls.
I’m now using background colours with a refresh. Does look a bit odd when switching between Modes but for now my solution is good enough.
@Kevin Gale: the differences between enabled vs. disabled, something clickable vs. something not clickable aren’t important anymore according to the fruit company. Unfortunately, users love DarkMode so I have to support it.