PagePanel panels 1 and 2 invisible but enabled and set to "visible"

Good evening folks. I have an app that I’ve been building over the past few months, on my own and briefly with someone to clean up the UI side. I currently have…let’s go with a strange combination of things going on in the app itself, but it all works, even if it’s not very pretty.

I’ve been having one specific issue with my Linux builds though - my main UI has three tabs in a tab panel, with the first tab having a bunch of containerControls on individual pages of a PagePanel. My problem is that on Linux (but not Windows or Mac), pages 1 and 2 don’t show any content - all other pages work as normal, and I can even click on a (now) invisible button on page 2 that opens a separate window. I’ve tried, I believe, every combination of manual arrangements, visible/enabled, ordering (all forward, all back, just relevant to front, etc. etc. etc.), different items on pages 1 and 2 (same as before - invisible but can be interacted with it seems); separate buttons that would manually move to the pages under test and enable/set visible the canvases in question (bypassing the normal step control button).

As I said, I do have some other stuff going on behind the scenes, including build Target detection changing the contents of pages 1 and 2 a bit; but, even with that code completely commented out, pages 1 and 2 do not show up. Also, I have all of my UI built with custom “scaleable” superclasses (basically, to deal with different monitor resolutions/sizes/DPI settings, I had to create a set of superclasses for all original UI elements that A, add themselves to a list of scaleable items at, B, also at, write their starting positions and sizes to individual properties [so they’ll stay in the same relative position and proportion as designed in Xojo IDE at “any” scale], and C, have a scale() method that takes the current window size vs. original window size, and figures out the new correct position and size to fit [so Left, Width, Top and Height, as well as textsize for labels/etc.]); I’ve tested changing back to normal superclasses again with no change in page 1/2 behavior.

I’ve tried to recreate the issue with a quick small app with a pagepanel, step buttons and unique elements on each page, but did not see the same issue. I’ve also tried my main app in Xojo IDE versions 2015r2.2, 2015r3.1, 2015r4 and 2015r4.1, again with no change.

I did see while searching for a solution, but don’t think that’s exactly relevant (and/or I’ve already tested basically the same solution from different angles and found it to not work here).

Any insight into what could be going on here would be greatly appreciated - I’ve spent several dedicated hours, and quite a few haphazard, over the last week or two trying to figure this out, and really do think I’ve checked, at least, all the stupid things that I specifically could have broken to cause this…

Page panels inside tab panels (and vice versa) can cause problems like this. You may want to come up with an alternative to this… Like adding containers dynamically at runtime and managing their visibility manually.

Is there any specific combination I should avoid, or any specific way they interact that I can test for/avoid? This was such an improvement over our previous setup (the UI guy literally had every containerControl stacked in that tab, and was controlling the visibility manually - the IDE was close to unusable) that going back would be painful - aside from this issue, it’s working great. Adding the containers dynamically would be a step to the side from that previous one - would require another redo of a fair bit of code, but if it’s the only real fix I’ll have to look into it…

Any particular reason it only breaks on Linux, and why it’s only pages 1 and 2? And, so I’m not just spamming the forum with questions on it - any documentation on this, and any other weird interactions between different controls that I should be aware of?

I do appreciate the response, Greg - this at least points towards a dumb issue on my end not being the cause, which is a bit of a relief…

You don’t have to stack them up. ContainerControls can be created at runtime and added to the panel with EmbedWithin.

Yes, that I understood - the setup before was having them stacked and making one visible at a time, which made the IDE crawl. I’ll have to look into the dynamic creation to start testing with it. Thank you for clarifying though X)