Yesterday I upgrade Xojo from release 2016_3 to release 2016_4.1
The first thing noticed was the label text, which shows the seconds, started to flicker on every second update. When the label showing the hh:mm was updated it flickered too. This was seen in the IDE as well as in the compiled version of the application.
When I did fall back to 2016_3 there was no flickering anymore of the label text for the seconds and the hh:mm. All showed a smoothly change, like expected. The window was quiet as it was before.
To be sure it was not the HW, I ran the IDE and the compiled version also on another PC with a 22" screen and also on a beamer with all the same results. The 2016_4 IDE and compiled versions did flicker and shows a nervous window when the label text was updated while the 2016_3 version was smoothly.
Is this a bug introduced in 2016_4?
I am running Windows 10 on a quad-core Intel machine with 8Gb memory. The default screen is a 32" HD.
Graphically, our main app is much slower under 2016r4 compared to 2016r3, to the point of not being able to hand it to customers. It’s going to have to get a lot better just to get back to where it was in r3.
Indeed, you are right, when tranparency is turned off it is not flickering anymore. Unfortunately I have a black background for this label now, which is a different color then I want… :-s
I think I will stick to 2016_3 till the problems are solved in a 2017 release.
I do need rotation, that’s probably why I originally used stringshape and then stuck with it.
Regardless, the issue with using either method is that you cannot see it in the IDE and so it becomes a guessing game. Unless of course you have a label over the top and turn off visibility, but that’s a lot of extra work - but probably what I will have to do in the end.
It reminds me of an old phototypesetting machine that I used in the mid 80’s. Text, and simple graphic primitive shapes had to be programmed via the command line, then a crude image was displayed on a green-screen monitor and finally produced onto phototypesetting paper via a series of lenses (font size) and various glass etched slides (the font face).
Although I enjoyed that time (some 30yrs ago) I didn’t expect to have to fiddle about positioning text using hard coded xy co-ordinates in the 2000’s let alone 2017.
Being a Windows programmer, this is a major pet peeve of mine. “Flashing Labels” look very unprofessional - I’m not a professional programmer, but nevertheless it doesn’t look good.
Fixing this issue would be the ONLY reason I would upgrade from 2016R3. 2016R4.1 introduced even more issues for windows programmers so I didn’t upgrade. Seems 2017R1 still holds no joy.
One wonders what would happen if the 2017R1 release introduced “flashing labels” for MAC OS users. I’m sure I would hear the screams all the way over here in Oz.
Nothing prevents you from using a Container Control where you place the invisible label as marker, and draw in the Container Control’s Paint event. But the label will never show rotated text anyway.
IMHO 2016R4.1 and 2017R1 Windows are not ready for prime time. I’ll stay with 2016R3 for now.
I haven’t got into using container controls yet - but it does seem like another “work-around” where there shouldn’t have to be one.
Thanks for the advice on sticking with 2016R3. I have to get my coding correct first anyway. Stopping the labels from flashing will be the “fairy dust” applied at the end.
Steve, workarounds are the essence of programming. Either because of bugs, or because you want to go further than what the language is supposed to allow.
As a matter of fact, your employing StringShape is a perfect example of going further than what poor little label does.
