PDA

View Full Version : programatically added controls do not show up



mg25683
04-06-2020, 03:05 AM
Hi,

I am adding frames to a form in a runtime
There seems to be a bug that makes only the last one appear correctly, while all the others do not appear at the form.
I know THEY ARE THERE, i can loop through them, they have .visible =true, all the properties (position, parent, etc) seem OK, they are just not visible.
The funny thing is that when i put a STOP in a code (or break the execution in any way, e.g. msgbox) all the frames appear correctly.
I tried playing with application.screenupdating, form.repaint but it doesn't seem to help.
Application.wait also doesnt change anything.

Any ideas?

(i cannot paste the code here, it's a big project. And when i tried to reproduce the error in a simpler case, it seems to work correctly - so I am just hoping someone had a similar case)

SamT
04-06-2020, 03:19 AM
Have you tried Form.Repaint after adding the controls?

mg25683
04-06-2020, 03:32 AM
yup:(




I tried playing with application.screenupdating, form.repaint but it doesn't seem to help.

Jan Karel Pieterse
04-06-2020, 07:48 AM
It'd help if you share the relevant bit of code. Have you added the controls to the frame or to the userform? You do know the Top and Left properties of a control in a frame are relative to the frame? So 0,0 is the top-left-hand corner of the frame.

Jan Karel Pieterse
04-06-2020, 07:49 AM
Hmm, reread your question. Given that it does not work in your project but does in a fresh one, have you tried cleaning the VBA project?

mg25683
04-06-2020, 11:11 AM
I add them to another frame.
As I said, all the properties are OK.
As I said - if I break the code right after adding a frame it shows up in the correct place, so this cannot be a matter of position or any stuff like this
As I said - the relevant code contains dozens of procedures and is not an option

mg25683
04-06-2020, 11:17 AM
Hmm, reread your question. Given that it does not work in your project but does in a fresh one, have you tried cleaning the VBA project?

No, it is not a matter of cleaning the code/starting over. As i said - adding controls works fine in a simple project (two fixed frames), but does not in a production case (lots of controls, classes, interfaces, frames within frames, etc) that i cannot paste here

SamT
04-06-2020, 12:21 PM
The funny thing is that when i put a STOP in a code (or break the execution in any way, e.g. msgbox) all the frames appear correctly.
'Do Events' instead of Stop or MsgBox?

As each Frame is completed call

Function RepaintFrame(Fram As Object)
Fram.Repaint
DoEvents()
End Function

I've never run into this issue since I always complete the UserForm in design mode, then Hide/Show - Move Back/Front as needed.

Jan Karel Pieterse
04-06-2020, 02:30 PM
Does it work if you add a fresh userform to the project? I've never had a problem like this before. E.g. my all vba treeview project adds thousands of controls at runtime.

paulked
04-06-2020, 02:34 PM
As Sam says, DoEvents can work. But I have had an instance when I have had to put three together, as in



DoEvents
DoEvents
DoEvents


to make it work. Not ideal but a fix!

snb
04-07-2020, 12:04 AM
I am adding frames to a form in a runtime

That is not a sensible way to do this.
Create controls in design mode;prpperty invisible.
The only thing you have to do in run time is make them visible: frame1.visible=true.

What you are trying to do now is to use too much code to lift a design failure. (designing precedes coding).

Jan Karel Pieterse
04-07-2020, 02:11 AM
I disagree snb. Sometimes a userform with controls added at runtime is to be preferred.

mg25683
04-07-2020, 03:16 AM
That is not a sensible way to do this.
Create controls in design mode;prpperty invisible.
The only thing you have to do in run time is make them visible: frame1.visible=true.

What you are trying to do now is to use too much code to lift a design failure. (designing precedes coding).

sorry VBAX Guru,

mg25683
04-07-2020, 03:22 AM
@samT, @paulked

thanks a lot, doEvents did the job

mg25683
04-07-2020, 03:25 AM
I disagree snb. Sometimes a userform with controls added at runtime is to be preferred.

yup, not only prefered - there are lots of cases this is the only way to do stuff

snb
04-07-2020, 04:11 AM
No arguments ? 'Sometimes' 'a lot of cases' not very convincing. (not at all I'd say).

mg25683
04-07-2020, 04:33 AM
c'mon man, google "Why Add Controls at Runtime?". Its the same for every programming language. The fact that you only worked with simple and static forms does not mean that other cases do not exist.

SamT
04-07-2020, 06:43 AM
Its the same for every programming language.
I didn't even realize that every programming language has a built in UserForms "Factory."