Text label on rectangle interface quirks on Windows, but not Mac

So, some of my interface comprises of text labels placed on top of rectangles for design, you know? It is just white text on a blue rectangle.

Anyhow, not one problem on the Mac, but the windows build has graphical glitches. Instead of it showing up like on the Mac, it looks like this:

Any suggestions on how to fix this? I have this issue many places throughout.

Have you set Transparent to True for the Label?

Yes, on the text, but do I need to do that on the blue rectangle as well?

You shouldn’t need to on the rectangle. Which version of Xojo and Windows?

wasn’t there some declares around here to make a textfield have round corners?

On Windows, instead of stacking controls, which is prone to flicker, a better method would be to draw everything on a canvas.

It seems incredible that flicker on windows is still a thing these days.

To avoid flicker they are using a pseudo-transparency. In this case the Label should take the rectangle color as background but is taking the Window background instead. I think there is a feedback case about this.

It’s nothing to do with flicker, if you see flicker you’re doing something wrong.

It used to pick up the color of the parent controls background and use that as its own background when the control was disabled (which would have been perfect for your use case) until this ticket was implemented and it was put back to a grey background instead.

<https://xojo.com/issue/54503>

[cut massive tirade about implementing bodge fixes as it’ll just fall on deaf ears]

The best bet you have now is rather than disabling the control by setting enabled = false is to leave it enabled and implement your own state management to “disable” the control, so trapping the mouse down event, focus gained etc. Yes, a massive pain in the posterior all because a “client” wanted grey back… yay xojo /massive sigh

I’ve asked for this to be reverted as forcing the control to grey when its disabled is shockingly terrible and unusable as Matthew has found out.

<https://xojo.com/issue/56962>

I think Matthew is using Labels and as far as I can tell they are not disabled. The case is talking about Text Fields.

I figured he misspoke as I saw/see no issues like that with labels unless of course he hasn’t put the label inside the round rect so it doesn’t pick up the correct parent and uses the grey of the window, which looking at it now is probably the case.

If that is the case Matthew, when you click the label make sure it highlights the round rect in red, if it doesnt you need to drag the label inside the round rect until the round rect highlights in red then drop the control. If you want fine adjustment then, either use the arrow keys or alter the left and top properties.

Well at least textfields might be looked at :wink: Cheers Alberto :smiley:

I agree that Text Fields need to be looked into. If I select a white background for the text field and I disable it, I expect a background color a little gray (maybe), but if I select red as background I don’t want to be the same gray when disabled, maybe a grayed out red (if there is no other option). In other words, that in Windows behave like in Mac (the text field background is preserved).

Matthew, I did some tests (before I read Julian’s answer), he is right, I think your Label is not fully inside the blue rectangle. You can be sure that the label is inside the blue rectangle if you right click on the label and you can see the Unparent option.

See my test, Label1 is not a child of the blue rectangle, Label2 has the blue rectangle as parent:

when the rectangle is the parent of the label, then you can see the Unparent option, if not, it will be grayed out

Hope this helps.

It has nothing to do with modernity, it has everything to do with Windows itself. And, additionally, with the hardware platform. Mac has screen double buffering in hardware, that is not the case for most every graphic card on PC.

As a developer, you should take into account the hardware and software platform.

My app Watermark on Mac uses several canvases and does not flicker any single bit.

On Windows, the very same source produced an app which was simply unusable since it flickered like fireworks. I refactored it to use a single canvas, and it does not flicker more than the Mac version, meaning not at all.

I do spend most of my development time on Mac, but I always make sure to do the last mile on a regular PC, to make sure my customers will have the best user experience. Unfortunately, Xojo’s promise of “develop once, compile many”, cannot be fulfilled when one platform allows stacking controls, and the other not.

A lot of Xojo developers develop on Mac and generate apps for Windows and Linux that they run in VM, so they have no idea that on a regular PC, their apps become flickery and don’t look professional.

The other way around, an app produced on Windows and carefully tuned to avoid flicker will generate Mac and Linux executables which will be as smooth as silk.

[quote=450213:@Michel Bujardet]It has nothing to do with modernity, it has everything to do with Windows itself. And, additionally, with the hardware platform. Mac has screen double buffering in hardware, that is not the case for most every graphic card on PC.

As a developer, you should take into account the hardware and software platform.

My app Watermark on Mac uses several canvases and does not flicker any single bit.

On Windows, the very same source produced an app which was simply unusable since it flickered like fireworks. I refactored it to use a single canvas, and it does not flicker more than the Mac version, meaning not at all.

I do spend most of my development time on Mac, but I always make sure to do the last mile on a regular PC, to make sure my customers will have the best user experience. Unfortunately, Xojo’s promise of “develop once, compile many”, cannot be fulfilled when one platform allows stacking controls, and the other not.

A lot of Xojo developers develop on Mac and generate apps for Windows and Linux that they run in VM, so they have no idea that on a regular PC, their apps become flickery and don’t look professional.

The other way around, an app produced on Windows and carefully tuned to avoid flicker will generate Mac and Linux executables which will be as smooth as silk.[/quote]

Yes, I have always had to do the windows fine tuning as a last step for years. From windows being activated … behind windows, or certain interface elements glitching, or whatever. Is there a reason windows doesn’t double buffer? It seems like a superior solution with no apparent heavy performance hit.

“Modern” Windows Languages like .NET and Windows Forms are DoubleBuffered by default. I don’t know why Xojo isn’t on Windows. :slight_smile:

Lack of time to implement that feature ?

Part of the problem for a company like Xojo is that MS cant make up its mind about what IS the “new UI”
Winforms ? WPF ? whatever it is now ?
With this vagueness in MS “direction” Xojo has remained using Win32
Which does not natively support double buffering and compositing
Xojo has implemented pseudo-transparency to make it more like macOS
Its closer but still has some issues

Windows machines are often game oriented. And games access the screen memory more or less directly.

Modern graphic cards are able to provide double, and even triple buffering. But it requires going under the hood for setting that.

You cannot count on a plain out of the box to provide any kind of double buffering anyway.

True, .Net controls and UWP apps benefit from double buffering. But at the price of some speed loss.

There is a long standing feature request for having a .Net version of Xojo, which would then benefit from double buffering controls. But with a whole lot on their plate, I doubt Xojo will get to that any time soon. Personally, I would rather have Android than .Net for now.

I located the feature request :

28733 - The Windows framework should be implemented in .NET instead of Win32

<https://xojo.com/issue/28733>

It is 14th.