Some controls not drawing transparent in Windows

Can someone point me to a code snippet that will allow sliders, checkboxes, etc. to be drawn transparent in Windows? When these are placed in a window or canvas that contains a background they draw like this:

I seem to remember that this was discussed (ad nauseum) in an old RB NUG thread, but I can’t find where to even search these anymore.


-bill k

Transparent is to set ON each object sliders or labels in Xojo Inspector Behavior.

Search the archives:

Sorry Norman, but I searched and can’t find the discussion that I vaguely remember.

…can you offer any insight as to how to fix this?

So I think that I’ve quantified this a little better and have attached a link to an example:

  1. When Sliders, Checkboxes, etc. are place directly on a window with a background, they will draw correctly.
  2. When they are placed on a canvas with a background, they actually display with the background color of the window that the canvas is placed on.

I think that this is a bug, but I’d like some confirmation.

Example Project

-bill k

One of many discussions here, this one started in 2006:

IMO it’s a bug, I’ve discussed it with XoJo Support, an engineer, and on the Forums until I was blue in the face, and ended up filing a Feedback report. I have no idea why but I don’t have these problems with any other Vendor/Controls/IDEs on Windows other than Xojo / RS.

Personally, I wore out a long ago and just subclassed a container control to mimic the Group Box (although the label transparency behaves differently than on Real Studio and Xojo – haven’t had time to work that out). And I’ve had more success with Checkboxes on a Rectangle control than a Canvas if all you want is a different background color.

Take this line from the forum discussion that the user made:

“RB is somehow able to display the transparency correctly in the development environment, though as discussed it doesn’t do so in the compiled executable. That is what really makes me wonder if a workaround isn’t possible.”

Then 3 years pass and not one peep out of Real on that statement the user made. I found out last year what the reason was, in the IDE, the TabPanel control is drawn by Real Studio in the IDE and in the compiled app it uses a native Windows control. Now, you would think that be a pertinent piece of information to respond to the users with, right? I get the feeling this issue is not important to them, but this makes the Windows versions look like crap until you go through all kinds of hoops and stunts to get it to looking right on Windows.

Very frustrating issue.


I read through that thread, and can very much understand and agree with your ongoing frustration. There is no reason why basic built-in controls shouldn’t be drawn correctly in every conceivable situation (directly on a window, over a background image, etc.). I have never had this issue with other development tools, and asking the framework to display these things correctly certainly isn’t being unreasonable, especially since that thread was started, and the bug reported, nearly SEVEN years ago!

[rant]While I understand that there will always be tradeoffs when developing a cross platform tool (hell, my programs are cross-platform and I’ve made plenty of tradeoffs), I do not believe that Xojo will ever be thought of as a viable alternative for developing complex, robust, native applications on any platform if they can not even solve basic problems like these. The fact that even their own internal development efforts need to jump through hoops, ignoring much of the built in functionality of the UI in exchange for custom controls, has to be an indication that things are awry. [/rant]

I would love to see Xojo succeed as a serious development platform, but I think that there needs to be a better platform in place to truely understand and address the frustrations and needs of serious developers than just voting on what bugs and features need to be prioritized. Sure I’d love to be able to use Xojo to develop mobile apps for iOS or other platforms, but I’d much rather have a more robust framework for current desktop platforms, because if the current state of the tool is any indication of the attention to detail that will be present in future offerings, it is destined to, at best, be just a niche development platform or, at worst, be looked down at by “serious” developers as the “beginners” choice. Xojo has the promise (and potential) to be a first rate development platform, and it certainly doesn’t deserve either of these reputations.


-bill k

I dug into this a while ago- and the actual technical issue is somewhat counter-intuitive in the case of control transparency on Windows. Where they use native Win32 controls- they don’t have transparency because it isn’t provided by those. Where they use their own custom controls (what you see in the IDE, BevelButtons, UpDownArrows, etc) they do have transparency. Generally speaking using native controls is the best path, but they do have their limits. This is one of them on Windows.

On Windows today, you can set the background color of the parent controls and be OK. That’s as far as you can go with the native controls. Any kind of custom image drawn outside of that wouldn’t work. I ended up going for a single color background myself and moved on at the time.

There are some options for the environment going forward, like using the .NET framework controls instead of the straight up Win32 ones. I’d bet/hope we see something like that in the future…

I’m a beginner with programming and of course, I thought I was doing something wrong. I’ve spent a great deal of time trying to understand what I should be doing to correct this issue only to learn that it’s Xojo that needs to get off their butts and get this addressed. As I said, I’m a beginner but it’s not rocket science to believe that this is not a complex issue to overcome. I would like to be using container controls in my current project but do to the negative aesthetics in appearance I wont have the luxury of organizing my controls in a manageable way without a sacrifice.

Placards are the only controls that allow transparency with these controls allowing me to be somewhat creative in the design but this does nothing for the organization of the project.

And unfortunately after more than 3 years since the original post this seems to still be an unresolved issue? Xojo 2016r3 on Win7.

Have you read the answers? It is not possible. At least on a framework level so that it work in all cases. You’ll find ten thousand entries in StackOverflow regarding this question. And all answers are either “it’s not possible”, ugly hacks or suggestions of solving it somehow for a very specific case. There is just no way (at least up to Windows 7) to make Windows controls have a transparent background. Native controls on Windows just don’t support that. Even Microsoft’s own WinForms controls, which are .NET controls, are not able to manage transparency. Why: they are based on the Windows native controls…

So your apps will automatically look right when installed on anything that you can build for. Have you tried turning off all of the prettiness of Windows 7? When Windows looks like Windows 2000, so does your app. If we didn’t use native controls, we’d have to have a variant in every theme with every possible color combination to even get close, or suffer the fate of some other tools where you get Windows XP-ish controls on a Windows 10 machine.

Perhaps what is needed is BackColor, not transparency. It is true that a lot of Windows native controls do not support transparency. However, a vast majority of Windows native controls have the BackColor property but unfortunately, the Windows native controls in Xojo are missing the BackColor property.

Ok thanks. I did do enough reading before posting here.
It’s not a necessity for my program to work, I just thought it might look more professional - even if my coding isn’t :slight_smile:

Just a quick test of Windows native controls using BackColor properties, layout according to William Koperwhats’ example project . The controls on the left are over a PictureBox, the Xojo equivalent of Canvas.

Sorry Cho, I don’t understand - what are you getting at?

I think this issue can be resolved by Xojo adding the BackColor property to the Xojo’s Windows native controls. BackColor is available in Windows common control system DLLs where native controls are created from, since 20 years? ago?

Ah right, I think I see what you are getting at.

Looks like you used Visual Basic - I’m using Xojo and intend to stick with it.