I had a a Windows application I had written using one of the 2017 versions of Xojo which doesn’t work anymore since release 2018r2 (it is still
functional on 2018r1.1).
It starts with a main window which displays correctly, but then this window is hidden (visible false) and another window is displayed which contains one ContainerControl and various other controls (buttons, lists). When the new window is displayed, the controls that are part of the ContainerControl are visible, but none of the other controls in the new window.
I tried changing their “transparent” property to False (were set to True automatically), but this makes no difference.
I also tried deleting the ContainerControl from the Window in the IDE, but for some strange reason, doing this also deletes all other controls in the window.
Any ideas what changes in 2018r2 may be causing the issue and how to solve it?
To check the source of the issue, I duplicated the entire window to a new one and removed the ContainerControl. Calling this new window without this component works properly.
There is therefore an issue with ContainerControl transparency in Windows since release 2018r2. The container control I’m using has Transparent set to on and HasBackColor to off, so it should be transparent, but apparently isn’t.
I had a similar issue. It turned out to be whether or not the control was “embedded” inside another control, like a rectangle or not. (You can tell because when you move the control in the IDE, the parent control highlights.) I believe the solution was to unembed, or set super = nil. Or maybe it was the other way around and it needed to be embedded properly. Sorry, don’t recall specifically.
J’ai bien lu les notes, mais mis à part une indication sur des optimisations du Draw sous Windows et quelques changements de scrolling avec les ContainerControl, je n’ai pas vu un changement qui pourrait avoir produit le résultat que j’obtiens avec la version 2018r2.
Thanks Steven for the tips. I have the ContainerControl embedded in the Window from within the IDE. Not sure how to solve this, hope we can get some help from the Xojo team.
I’m afraid I uninstalled 2018r2 and reverted back to 2018r1.1 to continue development.
It should basically be quite easy to reproduce:
Create a Containercontrol object
Add some controls to this Containercontrol object
Create a window, add various controls to this window
Add the Containercontrol object to the window
In 2018r1.1 the controls on the Containercontrol appear as well as those in the window. As of 2018r2, the controls in the window seem to be hidden behind the Containercontrol (even if it has the Transparent property set to True, both in the object definition and in the version of it added to the window).
[quote=409835:@Warren Smith]I’m afraid I uninstalled 2018r2 and reverted back to 2018r1.1 to continue development.
It should basically be quite easy to reproduce:
Create a Containercontrol object
Add some controls to this Containercontrol object
Create a window, add various controls to this window
Add the Containercontrol object to the window
In 2018r1.1 the controls on the Containercontrol appear as well as those in the window. As of 2018r2, the controls in the window seem to be hidden behind the Containercontrol (even if it has the Transparent property set to True, both in the object definition and in the version of it added to the window).[/quote]
Well, without a sample proyect, looks like you are doing something wrong. It has no sense talking about transparency because the controls are IN the container, not behind it.
Are you OVERLAPING the container over the controls in the window?
My guess is that Warren overlaps the ContainerControl over the controls already on the window.
Is weird that 2018r1.1 “works” for him and 2018r2. I can reproduce what is said using 2017r3 on Mac and remote debug on Windows VM, but not with 2018r2 (as expected) but 2018r1.1 works the same as 2. I may try to run Xojo 2018r1.1 under windows to see if I can reproduce this.
The Transparent behavior was changed in 2018 to deal with slow drawing and flickering. I think the general advice is not to put ContainerControl over other controls.
WinEditor (a window) which contains controls (BtnAddNewEvent & BtnFilter buttons and 2 text objects)
CommonInterface1, the ContainerControl common to many other windows which is added to this one. It contains some buttons
Event…View objects (3 canvas objects)
Is there any way to specify the z-order or something else in the IDE which I need to do to ensure that the ContainerControl is not masking the other controls in the WinEditor window?
I have been experiencing similar problems in my app. Various Windows 10 users of my app have been reporting container controls missing from windows in the app. Problem is, not all users are reporting the same controls missing. Also, my version of Windows 10 is showing all the controls. So, I can’t readily produce anything to demonstrate what is being reported. Also tough to fix because I can’t reproduce the problem they are clearly demonstrating to me via screen shots.
I use a container control to create a lookup field for my database app. A user will start typing in a text field and a listbox will drop down below the field to allow the user to select an entry based on what they are typing. When the user selects an entry, the listbox disappears. The text field and listbox are in a container control that may or may not overlap controls below the text field. When there is no typing, the listbox is not displayed, but that space is used for other controls.
When I first encountered this problem after using 2018r2, I “fixed” it by dynamically changing the height of the container control. Instead of having a container control with a height of 150 to accommodate a text field of 22 height and a listbox of 125 height below it, I would instead have the container height be 23 and toggle it to 150 whenever I wanted the listbox to show. This works most of the time.
Below are screen shots sent to me by a user who at first could not display the control at all in Windows 10, but did have some success by running the app in Windows 8 compatibility mode.
The first image shows the bottom of the text field missing. At least with part of the control showing, he was able to give it focus and type in it which then displayed the listbox selection control. Again, just running in Windows 10, nothing was showing so he could not get focus at all.
This feature in my app has been working fine for years and not experiencing any problems until 2018r2. I’m not saying the bug is in 2018r2. What I am saying is I’m not understanding how to adjust my code to make it work for 2018r2.
There’s always a logical explanation of these problems, it’s a lot easier to find these problems when I have access to the original apps (or a demo app), I download your Brian app and tried a few things.
Some users have this issue?
You have a canvas/container sitting under the controls that has its bottom locking button enabled set so as you resize the window vertically the bottom edge will expand/contract vertically. If a user has a smaller monitor (I assume that’s the case, unless there’s another way to move past your window minimum height, I use a program to force the size smaller) then the canvas/container underneath will get smaller and as that is the parent of those few controls it will limit the view of those controls. To see this in action expand the windows height and you will see the controls below get cut off, its a similar thing in the other direction if some of your users can get the window smaller.
To correct the problem turn off the bottom edge locking (LockBottom) on the canvas/container that is containing those controls when you are not showing the drop down box (you need it on when are showing the drop down so it moves with the expanding window), run your app and try expanding the window down, if you don’t see controls overwritten by an expanding white box then you have fixed the problem.
The reason it had been working for years is because (I assume) previous versions of Xojo didn’t care if controls were outside of their parent container if their parent controls was transparent, it would draw them anyway, that has recently changed with the new xojo windows update which is why you see this issue now.
If you are getting this in other areas of the app then I would check over the edge locking on all your other canvas/containers and ensure that they can’t move when not expected to.
On a side note, you have a little bug where if you type something into that person box to show the drop down then move onto another tab (i.e. notes) and back again then the drop down is still shown but behind some controls.
[quote]@ To correct the problem turn off the bottom edge locking (LockBottom) on the canvas/container that is containing those controls when you are not showing the drop down box (you need it on when are showing the drop down so it moves with the expanding window), run your app and try expanding the window down, if you don’t see controls overwritten by an expanding white box then you have fixed the problem.
[/quote]
Thanks so much for this explanation. I knew things had changed with transparency for Windows, but I had not considered the effect of how an expanding window would pull controls out of their safe locations if the locking was incorrectly set. It seems so obvious now that you’ve pointed it out.
Also thanks for the heads up on the other bug when swapping tabs.
The case above does prove that recent changes in 2018r2 have impacted the way windows and controls interact.
I have also noticed a few other strange issues:
I tried to reproduce my problem in a new small app in 2018r2 and I could reproduce the problem. However, when I selected the ContainerControl and then the editor button to send it to the back z-order, the issue was solved.
For some reason, in the app for which I’m reporting the issue, if I select the ContainerControl, the send to back button in the IDE is not available (grayed out).
I also wanted to delete the ContainerControl in my app and recreate it to see if that solved the issue, but for some strange reason, if I select the ContainerControl in the windows’ controls and delete it, it also deletes all the other controls in the window (they’re not located under the ContainerControl in the hierarchy, so no idea why this is happening). Only reason I would suspect is an issue when importing an app written in an older version version of Xojo into 2018r2.
Yes, the ContainerControl does seem to “contain” all my other controls in the Tab Order, but not sure why (I just created the ContainerControl in the window’s controls, without doing anything that would imply any hierarchy of this kind).
Can you explain why this happened and how to “undo” this?
