I opened an old project in 19R1.1 to make some modifications … The main window has a SegmentedControl on it… in the IDE it is invisible (and yes visible is true and the transparent property setting can be either true or false), but when I run the SegmentedControl is visible and works normally.
I have seen this behavior on 2 different Macs (both running High Sierra) with this project
As I thought it might be some project specific corruption I created a new project and dragged a SegmentedControl onto the default window… It is invisible… and yes it is set to visible
I opened the project in 18R3 and the segmentedControl shows in the IDE as expected…
Don’t know about windows
I can’t find a bug report on this in Feedback but i can’t believe I am the only one who has the issue if it Not something somehow specific to me… (or maybe High Sierra?)
Does anybody else see this?
BTW I see the same behavior (invisible segmentedControls in the IDE) in the latest alpha.
When I searched for SegmentedControl I did not not find those (needed to search for “Segmented Control”- but that is not the Class name) so I created another report:
<https://xojo.com/issue/56440>
As this was know since 2018r4 (which I skipped) and HS is a supported OS version, this behavior should have been fixed before 2019R1.1 And this behavior is STILL present in the latest 2019R2 alpha
If a known and verified issue like this is not going to be fixed in a release it should be included in a Known Issues section in the release notes which should be carried forward So because it was neither fixed nor documented , I wound up wasting my time troubleshooting
Venders for other software I use do include know issues to help customers not waste their time and I do aways check that!
Tested 10.12.6 and 10.14.5 on real hardware, 10.13.6 virtual.
From Dave’s comment, I guess he used a real laptop with High Sierra.
Reading <https://xojo.com/issue/54435> I think John was using a real machine with High Sierra and after Norman’s comment, updated to Mojave and that fixed the issue.
The really confusing part is that we actually ask the OS to render these for us, and the fact that they are rendering correctly in other versions makes me wonder if it’s a bug in 10.13 or in the 10.14 SDK.
The really confusing part is that we actually ask the OS to render these for us, and the fact that they are rendering correctly in other versions makes me wonder if it’s a bug in 10.13 or in the 10.14 SDK.[/quote]
My guess is some SDK bug with High Sierra, because:
[quote=446091:@Alberto DePoo]My guess is some SDK bug with High Sierra, because:
it doesn’t happen with Xojo 2018r3
only happens with High Sierra after Xojo 2018r4[/quote]
It may not be as simple as that.
In 2018r4, we jumped from the 10.9 SDK all the way to the 10.14 SDK in one shot. It’s entirely possible that this problem happened somewhere in between and we just didn’t know about it. Unfortunately we had to make this change to correctly support macOS dark mode.
There’s one API I use which works (as documented) on 10.11 & 10.13, it’s broken on 10.12 and on 10.14 it requires things to be done differently (I haven’t gotten far enough in Catalina testing to know what the outcome is there). None of this is in the documentation. 4 different versions of the macOS, 3 different outcomes.
Recently I’ve been wondering what the outcome might be if I were to hack the SDK version in the Mach-O file.
We have several framework items that depend on the newer APIs now. I suspect that at least on 10.14 youd get a crash. Remember, just because you dont use a feature in your code, does not mean that its not hooked up behind the scenes in our frameworks.