Userform Load Time

hatman

Well-known Member
Joined
Apr 8, 2005
Messages
2,664
I have a userform with 18 Frame Controls and 3 CommandButtons that have been placed at design-time. In each of two of these Frame Controls I have placed a ListBox control (the controls for the other 16 frames get created at runtime). These 2 listboxes get populated in teh initialize event of teh userform. Pretty simple so far. So on my machine, the form loads in well under 100 ms. On the big-screen monitors on the manufacturing floor, this form takes over 1 second to load. Long enough for people to wonder if they really pressed the button or not. At first, I thought the time was being spent in the intialize event. After optimizing the code with almost no gain, I commented out the entire event. This led me to start commenting out all code that manipulated the userform controls. What I was left with was the conclusion that creating the new object and displaying it was taking all of the time... over 1 second. I started removing controls from the userform, and eventually found I could load the form on the big screen display in well under 100 ms if I loaded it without and controls on it.

Here's where it gets bizarre. As part of it's normal operation, every time the user selects a new member of one of teh (2) list boxes, all of the controls in the other 16 frame controls get deleted, and then 16 new controls get built as either ComboBoxes or TextBoxes, depending upon the configuration data that is retrieved from an external Access Database. This event takes well under 50ms to execute.

I am left with the conclusion that I should be building ALL of the controls on the userform at runtime. Does this seem right? Can anyone explain why this would be the case?
 

Excel Facts

When they said...
When they said you are going to "Excel at life", they meant you "will be doing Excel your whole life".
Did you try moving the creation of run-time controls to the Userform_Activate event?
The user will have the UF to look at while the controls are being added, they won't wonder if they pushed the button.
 
Upvote 0
The thing is that the creation of the runtime controls takes virtually no time at all. It's the design-time controls that are sucking up the processor time. I am in the process of rebuilding the userform so all design-time controls that have no events associated with them will instead be run-time controls (18 of 22). based on the behaviour I have seen so far (delete and build 16 run-time controsl takes 50ms, load 22 design-time controls takes over 1000ms) this should run so fast that the user won;t have to wonder what happened.
 
Upvote 0
Just to clarify my actual questions: 1) does it seem right that runtime objects can be created orders or magnitude fatser than design-time objects? 2) if so why? 3) Am I missing something? Before I burn a few hundred lines of code building at runtime what I already have configured at design-time, is there something else I should be looking at? Right now the plan is to burn that code and do as much at runtime as possible, because what I have learned so far seems to suggest this course... but it doesn't seem to make logical sense.
 
Upvote 0
I agree that it doesn't make sense.
But, apparently, making sense is not a necessary condition for it to happen.
The only concern I would have is file bloat.

I had a routine that created (and destroyed) userforms at run time. The file size got bigger and bigger, as if the delete userform hadn't freed up all the memory it should have. Controls might not have this effect, but that's the only potential operational downside I see.
 
Upvote 0
I agree that it doesn't make sense.
But, apparently, making sense is not a necessary condition for it to happen.
The only concern I would have is file bloat.

I had a routine that created (and destroyed) userforms at run time. The file size got bigger and bigger, as if the delete userform hadn't freed up all the memory it should have. Controls might not have this effect, but that's the only potential operational downside I see.

I'll keep an eye on that. I have seen certain types of file corruption associated with VB Userform objects built at design time that cause wierd file bloat... but never seen runtime objects result in same.
 
Upvote 0
Just for the record, and I can't explain why, stripping my form down to 3 command buttons and one listbox that has change event code associated wit hit, and creating all other controls at runtime in the initialize event, sped up teh form load by almost 2 orders of magnitude... I don;t pretend to understand WHY, but I'm running with it until it causes soem other problems.
 
Upvote 0

Forum statistics

Threads
1,224,505
Messages
6,179,153
Members
452,891
Latest member
JUSTOUTOFMYREACH

We've detected that you are using an adblocker.

We have a great community of people providing Excel help here, but the hosting costs are enormous. You can help keep this site running by allowing ads on MrExcel.com.
Allow Ads at MrExcel

Which adblocker are you using?

Disable AdBlock

Follow these easy steps to disable AdBlock

1)Click on the icon in the browser’s toolbar.
2)Click on the icon in the browser’s toolbar.
2)Click on the "Pause on this site" option.
Go back

Disable AdBlock Plus

Follow these easy steps to disable AdBlock Plus

1)Click on the icon in the browser’s toolbar.
2)Click on the toggle to disable it for "mrexcel.com".
Go back

Disable uBlock Origin

Follow these easy steps to disable uBlock Origin

1)Click on the icon in the browser’s toolbar.
2)Click on the "Power" button.
3)Click on the "Refresh" button.
Go back

Disable uBlock

Follow these easy steps to disable uBlock

1)Click on the icon in the browser’s toolbar.
2)Click on the "Power" button.
3)Click on the "Refresh" button.
Go back
Back
Top