Missing / Invisible Controls

After updating our environment from Xojo 2016 r3 to Xojo 2017 r2, one of our users has reported that some controls are not appearing properly on screen. In other words, certain controls are invisible or missing graphic elements. For example, labels and custom canvas controls are completely invisible, picture buttons are missing icons, and listboxes are missing column headings, cells, and gridlines.

We have multiple screenshots from the user showing the issue on different windows, but cannot duplicate on our end. The user is on Windows 7 x64 and we are waiting for more information about his graphics and display configuration. He has done some troubleshooting, such as uninstall/reinstall and reboot. He also did a system restore, which restores a prior version of our software that does not have the problem (built with 2016r3). It returns immediately when he updates to our latest version (built in 2017r2). We have HiDPI support turned off. We are suspecting that this is an issue with all canvas based controls, possibly related to Direct2D changes in Xojo.

Has anyone else ran into this issue with controls not appearing on screen? Are there any other settings we can adjust in the IDE that may help to resolve the problem?

Its a known issue: <https://xojo.com/issue/47764> for Windows 7 in certain edge cases.

Ask the user to install KB2670838 as this is required and sometimes doesn’t get installed by default.

They should also be able to find it (from memory) on the additional installs page of their updater.

I don’t think that is the same issue. I was not able to reproduce the issue in a Windows 7 VM by uninstalling the KB2670838 update.

The Feedback Case #47764 refers to textboxes and generic buttons in the IDE. We have no issues with those controls, but labels and canvases are the ones not showing up. Our user with the issue is running a built app, not using the IDE. I watched parts of your videos and see you mention canvases with DrawInto. We aren’t using the DrawInto, but perhaps something similar is going on. I didn’t see any labels in your video so I’m wondering, did you have any issues with the generic labels showing up in your tests?

I just encountered an issue where multiple items on a window were invisible. I ended up tracking it down to being caused by an older Einhugur PictureButton Plugin that was tie issue causing it. When I removed the PictureBotton Plugin the problem wet away but the PictureButton controls showed as question marks. After downloading and installing the latest PictureButton plugin, everything showed up correctly.

The key takeaway is this is probably a plugin control incompatibility causing items on your window to disappear.

Thanks for the info. We are using the PictureButton plugin, but we already have the latest version 3.6.0 and have updated all of our plugins recently. Unfortunately troubleshooting plugin compatibility would be difficult since this is a production app and the plugins are required for compiling, building, and running the program. I still think something else is going on, since I would suspect a plugin issue like you are describing would pop up across a variety of systems and be more easily reproducible.

I still think it would be advisable to compare plugin folders with a system that is not having the problem with one that is. The changes in 2017R2 to support HiDPI might be breaking something in a plugin like it did in my issue with PictureButton.

The steps I took to troubleshoot involved first exporting the problem window. Importing that window into a new project and opening in 2017R1.1 to see if the issue went away. It dis so I looked at what controls were on the page that came from plugins. I then removed those plugins from 2017R2 and opened the test project. The problem went away so it was then a process of adding removed plugins back one at a time to find the culprit. In my case of course I only removed the 1 plugin so the answer was obvious.

I think we did run into something similar that led us to update all of our plugins a while back. We did initially suspect something like that and asked the user to uninstall and delete the Program Files installation folder to make sure there are no old versions of the Resources or Libs files.

Sorry if it wasn’t clear that the issue is on an end user system and the app is off the shelf, not custom software for a local client. Unfortunately we don’t really have direct access to their system for file comparisons and more advanced troubleshooting. Thanks.

It might be Aero. See here:

https://forum.xojo.com/conversation/post/331729

In 2016r4 when they changed the Graphics on Windows then plugin control (or Declare) that fetches GDI HDC context needs to return the context also with a new API that came in 2016r4.

So if you have anything that pre-dates this, plugin control or Declare that draws into HDC that is not returned then you will get exactly this issue control parts and whole controls not drawing.

With that said since it was mentioned above then PictureButton 3.6 is updated to return the DC so is safe for case like this.
It is not updated for Hi-DPI though. (That is in the works for both Windows and Linux as we speak)

Kem, thanks for the forum link. The issue you described on that thread sounds a lot like this problem. It is a Windows 7 machine and the screenshots show that transparency is turned on. We generally avoid asking users to change those settings to fix a problem in our app, but we’ll use that information for troubleshooting.

Björn, thanks! Your insight helps to put things in context, as we don’t necessarily keep up with all of the Xojo changes that are going on under the hood. I will take another look to double check that our plugins are up to date on all of our developer machines. Do you know if these issues would occur even if the plugin is installed with the IDE but does not actually get used in the project? For example, someone mentioned the Window Splitter plugin in the thread that Kem shared. Could having an outdated Window Splitter plugin on our machine cause problems in apps that do not have the Window Splitter used anywhere in the project? My impression was that the plugin would not be included with the compiled application, so any clarification would be helpful.

[quote=349243:@Aaron Martinez]Kem, thanks for the forum link. The issue you described on that thread sounds a lot like this problem. It is a Windows 7 machine and the screenshots show that transparency is turned on. We generally avoid asking users to change those settings to fix a problem in our app, but we’ll use that information for troubleshooting.

Björn, thanks! Your insight helps to put things in context, as we don’t necessarily keep up with all of the Xojo changes that are going on under the hood. I will take another look to double check that our plugins are up to date on all of our developer machines. Do you know if these issues would occur even if the plugin is installed with the IDE but does not actually get used in the project? For example, someone mentioned the Window Splitter plugin in the thread that Kem shared. Could having an outdated Window Splitter plugin on our machine cause problems in apps that do not have the Window Splitter used anywhere in the project? My impression was that the plugin would not be included with the compiled application, so any clarification would be helpful.[/quote]

Issues do not occur if the plugins are installed and not used. Having outdated WindowSplitter installed would not be problem no if it is not used in the project. The plugin is not included in the compile if it is not used. And the problematic obtaining of a HDC without returning it is never done.

Note a declare can also do it. And whats worse is that at least when 2014r4 came then there was no way for a declare to return the HDC correctly. (don’t know if they have added way for it to do so since then), so I would advise also checking declares if you have any declares to do any kind of drawing.

[quote=349273:@Björn Eiríksson]Issues do not occur if the plugins are installed and not used. Having outdated WindowSplitter installed would not be problem no if it is not used in the project. The plugin is not included in the compile if it is not used. And the problematic obtaining of a HDC without returning it is never done.

Note a declare can also do it. And whats worse is that at least when 2014r4 came then there was no way for a declare to return the HDC correctly. (don’t know if they have added way for it to do so since then), so I would advise also checking declares if you have any declares to do any kind of drawing.[/quote]

Thanks for confirming my understanding of the plugin compilation. I am waiting to hear from the user after advising them to try installing an update that was built on a machine with known good plugins.

I don’t think we use declares for drawing in Windows, but I will check our controls to make sure we aren’t overlooking anything in the parent classes. Thanks!

Recently I received the same report from one of my users.

App: built on Xojo 2018r2, Hi-DPI enabled, no third-party plugins
OS: Windows 7 SP1; all Windows Updates applied (according to the user’s report)
DPI: 100%
DirectX: version 11, no issues reported in dxdiag

According to this article, some computers using hybrid graphics (Intel/AMD) are incompatible with this Windows Update:

Actually the user’s computer is Pavilion dv7, which is explicitly listed as incompatible hardware in the article.

I guess this issue is somewhat related to GPU hardware acceleration and graphics driver, so I feel it’s not strange if it cannot be reproduced using VM. (Although it’s still unsure if this Windows Update is related to the issue…)

It seems to be somehow related to the graphics hardware. We also have a couple of customers who don’t see any “graphics” (Listbox, Canvas - and other “graphics controls”) in Xojo built applications, just the native Win32-GDI controls.
Disabling Aero seems to help. If they don’t want to disable Aero in general, then:

  • Right-Click on the app.exe
  • Properties
  • Compatibility: [X] Disable Desktop Composition

You can do the same in your app by using Windows API:

[code]Declare Function DwmIsCompositionEnabled Lib “Dwmapi” (ByRef pfEnabled As UInt32) As Integer
Declare Function DwmEnableComposition Lib “Dwmapi” (uCompositionAction As UInt32) As Integer
const DWM_EC_DISABLECOMPOSITION = 0
const DWM_EC_ENABLECOMPOSITION = 1

Dim iRes As UInt32
if (DwmIsCompositionEnabled(iRes) = 0) then
if (iRes = 1) then
'Aero is enabled
if (DwmEnableComposition(DWM_EC_DISABLECOMPOSITION) = 0) then
'Aero is now disabled for this application instance
end if
end if
end if[/code]
This should not have any effect on Windows 8 or newer. It might still be better to only do that if you know the app.exe is running on Windows7.

This will disable Aero (Desktop Composition) as long as the app.exe is running (or any other app doing that). After closing the app.exe, Aero will be enabled again (if it was before).

Having said that… it doesn’t make the best impression to users working with Xojo built applications on Windows 7…
…just: how can Xojo fix this? We obviously can’t give them a “reproducible example”, since this happens only in some hardware configurations and doesn’t seem to be reproducible in a VM. So their answer most likely will be: “won’t fix” :frowning:

Let’s just hope they can… there must be some “hardware feature” their Framework is trying to use (and then silently fail → graphics don’t show). And that needs to be detected by the Framework, and done in some way that is not explicitly leveraging hardware.
That’s why I’ve added <https://xojo.com/issue/54979>, so that they have a case to work on.

Just in case it’s not obvious: don’t do this for all your Windows 7 users…!
It will switch the entire Desktop/UI appearance and inform the user that it has switched.
But as a workaround you can offer such an option in your app, so that affected users can turn it off easily.

We now also get reports from Windows 8.1 users that have the “Graphics Controls (e.g. Listbox, Canvas)” not showing up.
On Windows 8.1, it seems to happen on Notebooks with “dual Graphic Cards” (e.g. AMD Radeon HD ___ and some Intel-integrated-one).
The ugly workaround for Windows 7 (disabling DwmEnableComposition) can’t be used, because “This function is deprecated as of Windows 8. DWM can no longer be programmatically disabled.”
If you happen to encounter this, too: They might need to assign the Xojo-built app to the “integrated Intel Graphic” (using the Driver/Settings of the “better” Graphic Card) in order to be able to use Xojo built Direct2D applications.
At least <https://xojo.com/issue/54979> is now verified…

Have you managed to confirm from a user that the AMD re-assign thing works Jurg?

No confirmation yet… I’ve just passed along your hint :wink:
But i’ll do once I get Feedback from that Windows 8.1 user.

More important for now is the info that this isn’t just a “Windows 7 / KB2670838” issue, but some more severe flaw in Xojo’s Direct2D implementation…

Just confirmed… it works! Thanks for that hint…!
See ScreenShots in <https://xojo.com/issue/54979>