Maybe, maybe not. If Transparency = not opaque, then you’d need to select “Transparent” in the inspector as this would tell the macOS that the containercontrol is to allow transparency. Otherwise there are (minor) performance benefits to disabling "Transparent’.
Xojo and transparency are not good friends. I had many visual artifacts after 2016r3 because it lost many transparency capabilities in Windows after that version. Xojo even says to not trust in their “composer” for transparency, because it flattens images to some background that sometimes it disagrees with the designer… Probably your case. Open a FB case and put this simple sample there… Let’s see what William will report back… or fix.
you MUST also set the background color and transparant in the IDE on the window (editor) where the container is on. Otherwise it will not honor it’s defined values (in the container editor) since the Inspector behaviour sets it back to the defaults (when dropped on a window or embedwithin).
I wonder what any new customer will think about that. It is inconsistent and no way out yet for me. My app is ready to market - but I can and will not deliver such an interface.
But at Runtime, as things are flattened to opaque colors, the yellow square is covered, and the blue one is trimmed by the opaque (expected transparent) container.
Not fully. Xojo’s Windows framework does not really support transparency (I wonder if that could be changed by using the WS_EX_LAYERED flag when creating a control), whereby macOS does.
I wonder if the background color property on a container is supposed to work anyway, or if it could be fixed in Xojo‘s framework. Sadly Xojo (in former times) decided to make a ContainerControl a Window subclass, probably because it needs to have a free floating container in its IDE editor and that was based on a window.
Technically, a container is a NSView on macOS instead, not a NSWindow. A NSView does not own a background color property. Or rather indirectly: It must be a layer-backed window, and its optional CALayer has a backgroundcolor property.
So my guess is either this container’s backgroundcolor property is just a part of the virtual window in the IDE and was forgotten to be included as a Layer property (or was never intended to be used and should be hidden in the IDE), or Xojo forgot to set the wantsLayer property when creating the view to embed as a container in runtime.
As the Xojo IDE is said as written in Xojo, it’s interesting to see that they can use it for their own purposes, as we see in the layout editor, but not for users at runtime.
Wow, this seems to help. Thank you Derk and Ulrich, I will try to use that in the fifty places I am using transparency now … and thank you Rick for your thoughts. It appears that the (nice) IDE shows something which is not reflected in Mac and Windows Apps finally without additional code. Again this makes me think about new users and about quality (which is the degree of how something fulfills the expectations).