I know that overlapping controls can be problematic and I’m willing to live with the pseudo transparency speed hit
But I’m finding a really simple set up isnt ever making a container control transparent no matter what
In a new desktop app make sure supports hi dpi and dark mode are enabled (they should be by default)
Add a push button to the default window
Add a container control to the project
Add an instance of this container to the default window
Position it so it covers 1/2 the push button
Run
The button is not visible through the container
Quit running app
Change container to transparent = false
Run
No difference
I cannot find any settings that make the button show through
and this code works fine on macOS but ont windows I cant make the thing transparent and I have spent a decent amount of time trying all kinds of combinations of params and even a few windows declares
From what I understand, only the “background color” shows through. As in, the ContainerControl will show the background color (from the window) but not the controls that are under it.
Edit: I changed ContainerControl Transparent to False expecting to get the gray background, but still shows the same color as the containing window. So I don’t know how Transparent works in this case.
This situation is symptomatic of Xojo’s “we know better what’s good for you” attitude.
Sure, the adoption of Direct2D has advantages, but was it really necessary to sacrifice true transparency on the alter of “modernity” ?
To me, progress means improvement, not regression, whatever explanations to justify that hindrance.
Besides, indeed, a project created on Mac with truly transparent controls will now look ugly and sloppy. This negates Xojo’s claim to cross platform ability, just as badly as iOS and it’s idiosyncratic “New platform only”.
It looks more and more as if Xojo has lost it’s mojo
While Xojo/RS/RB always had its issues, it seems to me what the main locus of problems have changed.
In the old days (pre Xojo) the problems were mostly bugs and incomplete features… Those still happen but since then from my point of view there have also been a lot more unfortunate design decisions that have had an overall negative impact on the progress of the product then the before even though some things have gotten better
To me, something seemed to have changed in the technical vision (for lack of a better term) and not for the better.Maybe it was from personnel changes, or maybe it’s my perception as i became more experienced with it and expected more , but that is how it has felt to me. For sure I am no longer as excited about the product and new releases as I once was.
What is disconcerting to me is the fact that a former Xojo engineer, and not the least of them either, is puzzled by a problem that the community (or at least the subset present here on the forums) has been complaining about since day one. There were numerous feedback notes on the topic. And much discussion here, although this is not a proper communication channel back to Xojo.
Is it just me reading too much into the situation, or is the Xojo development team so remote ( in the proverbial ivory tower) that issues reported by the user base are not taken seriously, or the impacts of the issues are simply dismissed? I hope that I am just reading too much in this situation.
Perhaps a great deal has to do with a lack of top management. Since the unfortunate iOS that was compatible with itself down to the disappearance of string, and the advent of Direct2D which signed the demise of transparency, I am not sure there is a pilot in the plane anymore.
It is the responsibility of the top manager to make sure what comes out of the company conforms to standards. Even if it means ruffing the feathers of coders who would prefer to do it their way. Even if coders pretend it cannot be done.
I remember when iOS came, back in December 2014 or so. The disappearance of String ? Platform necessity. And that was done to protect you. No Parent for controls ? Platform necessity. No colors for controls ? That’s the platform…
BS I tell you. Big horse manure. After being unable to complete Check Printer with that solution, I went somewhere else who does Basic for iOS, and guess what ? Every single property is available for each control. String too, of course.
Way back when, in 2000 or so, I moved to RB because of its Mac/Windows ability with no fuss. It is a pity that two decades later, I was forced to abandon part of it because of what appears to be a lack of care for users opinion.
As for Norman discovering the pitiful lack of transparency, it just shows that up until now, he did not have to contend with a poorly designed piece of engineering. Hell, how difficult is it to make a control transparent ?
Just run the Platform Specific/Windows/CustomWindowShape sample project. And it works in 2019R1.1.
Found this by using Canvas instead of ContainerControl with some controls and changing the DoubleBuffer value at design time. The docs for Canvas.DoubleBuffer say that Canvas loses its transparency but then say:
that led me to believe that it will not be any change, but it did lose its transparency.
So, if there is a way to make Canvas and ContainerControl lose its transparency (by changing DoubleBuffer to True), why have a Transparency option on Mac that it is always transparent and on Windows that is never transparent. Any test on Linux?
I don’t know what DoubleBuffer should do, the docs only say:
[quote]If True, the Canvas will be double-buffered.
When True, reduces flickering on Windows when the ContainerControl is scrolled.[/quote]
how non-professional programmers know when is a good idea to use that option? I guess we need to search for more info.
