While reported 5 years ago, this is still a huge issue for Windows.
In that thread it takes approx. 5 seconde. In my case it is over 10 seconds. I use a splashscreen for this but that is not a very good solution - more a workaround that shouldnt be needed.
This ‘bug’ really needs some love!
Did you profile your code to see where the bottleneck comes from?
Do you have a similar layout like the one described in the OP? If so, if you use the opening events of the controls for initialisation, it is very likely all controls – also the ones not visible – will run their initialisation routines, and if some list boxes and database access to fill them are included I would think it is them causing the long opening.
If your profiling shows that something in that direction is the cause, maybe you could delay initialisation of the controls to when their page is first shown, or put all that work into a background thread that will not delay basic drawing.
You guys seem needing some kind of lazy loading design. Like letting the window show up with some “Loading…” condition and after loaded unlock controls that start disabled until the load process ends.
By any chance does your slow-opening window contain an HTMLViewer control? There’s another thread working through a very similar-sounding issue:
As in the original thread, profiling does not reveal anything.
No, it does not. Mostly a whole bunch of checkbox, label, textfield, buttons, combobox controls in containers. Nothing special.
Removing all events and code behind those controls does not fix it either. It is clearly an issue of ‘drawing’ it the first time. It is exactly the same issue as the original OP
FWW: they are original all API1 but changing them in API2 versions, does not fix it either.
Nope… is not the case either.
As already explained, removing all code and events related to the controls in the container does not make it better. It still takes about 10 seconds before the window with container is shown. When closing the window and reopen it, it is shown instantly. It is just the first time thats very slow.
The delay is with both a slow (12 years old Intel i3)and very fast (Surface laptop i7) uptodate Windows system.
I would like to see some sample to understand the problem better.
tried with the info provided, but so far can’t reproduce. Sample attached. Though drawing the Window the first time does not look nice and is not instantly it is far away from seconds.
manycontrols_thk.zip (12.4 KB)
It is a very large and commercial project which I cannot share (even with Xojo Inc). Due to a contract.
Today I used the ‘solution’ provided by Christian. Adding each container to the page panel dynamically.
This does fix the problem and shows the window in < 1 second but it is a very cumbersome way to solve this.
It seems when you add controls dynamically it is instantaniously. When doing the same within the Xojo GUI, it is slow. That’s very odd to say the least.
Maybe Xojo needs to look at the Windows framework how controls are added.
What I find rather weird is that you seem to say it’s easy to reproduce (add a lot of controls to a window and show it) and many users don’t seem to agree.
Can’t you create a sample yourself (add a lot of controls and see by yourself that this specific sample takes several seconds to show for you) then share that sample here so others can validate/deny they see the same problem?
This would stop this discrepancy between your “unproven” experience and the ones other users are seeing.
I don’t expect people sharing their projects, just some sort of replica of the problem as Thomas did and could not find the reported experience. In Thomas approach I can notice a discrete/ignorable painting slowness probably tied to how Xojo works, I guess lots of timers firing in sequences and Windows don’t use such approach natively.
This doesn’t always work. This year I had an issue under Linux, not seen on the other desktops. I spent quite some time trying to make a smaller example to show the issue. This always failed. In the end I made the issue private, and submitted my entire app, along with instructions on how to set it up enough to show th eproblem. This Xojo did and found the reason within a day. The fix was to revert a change introduced in 2024r1, and it’s been fine ever since.
I’m guessing that the reason is likely that there is a difference between a brand-new, fresh app, and one which has been modified a lot over the years as well as undergoing the API1 to API2 conversion experience.
I tried but no succes making a decent example.
Maybe Bob Keeney can make an example (OP). He has the exact same issue as I have.