add control to a form or register control in runtime

[Martin]

Hi,

can I with Access XP in runtime add new control in a form or a register page
(dynamic)?
I know the command createcontrol, but this command can only add control to a
form in design time (or open form in design mode to do it)

Thanks
Martin

 

[Allen Browne]

That is correct.

You cannot add new controls to forms or reports in a runtime.

 

[Klatuu]

Allen is correct.
If you just want to have a control available only for a certain condition,
then create the control you need as part of your design. Make its Visible
and Tab Stop properties false. In your form's code, you can then make the
control visible and and include it in the tab order.

 

[Martin]

It's a pity.
I want to write a form, that can add new register page and new subform to
this page, when user wants. Count of new pages and subform is not limited.
Is there any other way? Or Access had not this feature?

Thanks
Martin

 

[Marshall Barton]

I want to write a form, that can add new register page and new subform to
this page, when user wants. Count of new pages and subform is not limited.
Is there any other way? Or Access had not this feature?

I am not familiar with the term "register page", but instead
of adding a new subform control, you can open a separate
form. There is even a way to open the same form multiple
times.

OTOH, maybe a single subform control that you can switch
between different form objects will meet your needs.

If you'll explain the user's UI needs instead of your
attempt to design something to meet those needs, maybe
someone will be able to come up some alternative ideas for
you to pursue.

 

[Martin]

Thanks,
see my comments

I am not familiar with the term "register page", but instead
of adding a new subform control, you can open a separate
form. There is even a way to open the same form multiple
times.

yes, I know it, but this feature can not be the solution in my case. I want
to use a form for a table, the first page (register) is for data, when user
click on statisti, this form may create a new page and a subform on it,
which load the statistic form for this Table..., and this form is used for
different Tables.... In design time I can not create static count for pages
and subforms.

I can create in design time so many controls as it is posible, and set it
unvisible, and when it is necessary, I set them visible. But this is no good
design...


Martin

 

[Marshall Barton]

Thanks,
see my comments


yes, I know it, but this feature can not be the solution in my case. I want
to use a form for a table, the first page (register) is for data, when user
click on statisti, this form may create a new page and a subform on it,
which load the statistic form for this Table..., and this form is used for
different Tables.... In design time I can not create static count for pages
and subforms.

I can create in design time so many controls as it is posible, and set it
unvisible, and when it is necessary, I set them visible. But this is no good
design...

Making controls visible/invisible is a far superior approach
to making design changes at run time. From what you've
said, that sounds like it might be the best way for you.

 

[Martin]

why I don't know in design time, how many controls will the user open.
I don't like add for example 100 pages and subforms to to form, allthough
the users oder the current table uses only 2.

With API we can create a window control dynamically in runtime, but I don't
know, how about access control (register control)...

In Visual Basic 6.0 we can also create a control in runtime, althought the
such a control doesn't exist on the form. I hopped, Access can it too.

Martin

 

[Rick Brandt]

why I don't know in design time, how many controls will the user open.
I don't like add for example 100 pages and subforms to to form,
allthough the users oder the current table uses only 2.

With API we can create a window control dynamically in runtime, but I
don't know, how about access control (register control)...

In Visual Basic 6.0 we can also create a control in runtime,
althought the such a control doesn't exist on the form. I hopped,
Access can it too.

This is not a practical solution in Access as Access forms have a *lifetime
limit* on the number of controls that can be added so even if you figured
out how to do it you would quickly hit that wall and have to rebuild the
form.

 

[Marshall Barton]

You may or may not like it, but that's the way it is.

Access is a data centric application development tool, VB
is not. Access controls are not the same as standard
windows, for performance reasons, Access was designed to use
"light weight" controls that are just pictures on the
screen. The only standard control that has a (temporary)
hwnd is the control that has the focus.

I still have no idea what a "register control" is so I don't
feel comfortable addessing that part of your question.
However, if you're so inclined, you can revert to using APIs
to do a lot of non-standard stuff, but you will have to
write additional code to deal with data binding and all
kinds of other things that Access controls take care of
automatically.

A lot of folks have asked this kind of question of the years
and the answer is always the same: Precreate the invisible
controls at design time and make them visible as needed at
run time. Are you sure that you might have up to 100 of
them at once? How the heck are you going to fit all that
stuff on the screen at the same time?

Just in case we are communicating at cross purposes, I will
state that you can/should write a procedure that acts like a
mini, one time, design time wizard to create the controls.
If you really need that many copies of a set of controls, it
would be far less tedious than doing it all manually. Don't
forget about the limit of 754 controls while you're planning
all this.

 

[Martin]

I have a friend, he used access 20 and build an universal form for all
application, that means, instead of opening many windows he shows a new
subform on a a new page (which he wrote self, not register control of
access). On this form he creates many subforms and ... (he tells me 100
pieces).

I do like this solution, because the MDI style is lost. But in a module,
such as INVOICEs or Customers, I want to show their "component", such as
statistic, Summary, on another page of register... Certainly not 100 x at
the same time, and not all controls on the same page..

But when Access can not this feature, I must do as it can.

You may or may not like it, but that's the way it is.

Access is a data centric application development tool, VB
is not. Access controls are not the same as standard
windows, for performance reasons, Access was designed to use
"light weight" controls that are just pictures on the.
screen. The only standard control that has a (temporary)
hwnd is the control that has the focus.

I still have no idea what a "register control" is so I don't
feel comfortable addessing that part of your question.
However, if you're so inclined, you can revert to using APIs
to do a lot of non-standard stuff, but you will have to
write additional code to deal with data binding and all
kinds of other things that Access controls take care of
automatically.

A lot of folks have asked this kind of question of the years
and the answer is always the same: Precreate the invisible
controls at design time and make them visible as needed at
run time. Are you sure that you might have up to 100 of
them at once? How the heck are you going to fit all that
stuff on the screen at the same time?

Just in case we are communicating at cross purposes, I will
state that you can/should write a procedure that acts like a
mini, one time, design time wizard to create the controls.
If you really need that many copies of a set of controls, it
would be far less tedious than doing it all manually. Don't
forget about the limit of 754 controls while you're planning
all this.
--
Marsh
MVP [MS Access]

why I don't know in design time, how many controls will the user open.
I don't like add for example 100 pages and subforms to to form, allthough
the users oder the current table uses only 2.

With API we can create a window control dynamically in runtime, but I don't
know, how about access control (register control)...

In Visual Basic 6.0 we can also create a control in runtime, althought the
such a control doesn't exist on the form. I hopped, Access can it too.

no
good

 

[Marshall Barton]

We are definitely having a terminology issue. Your use of
the words "register", "page" and "pieces" are too far out of
context for me to figure out what you mean in terms that I
use. I'm not even sure if "Access 20" is referring to
Access 2.0 or Access 2000.

You would probably be better off looking for a newsgroup in
your native language.
--
Marsh
MVP [MS Access]

I have a friend, he used access 20 and build an universal form for all
application, that means, instead of opening many windows he shows a new
subform on a a new page (which he wrote self, not register control of
access). On this form he creates many subforms and ... (he tells me 100
pieces).

I do like this solution, because the MDI style is lost. But in a module,
such as INVOICEs or Customers, I want to show their "component", such as
statistic, Summary, on another page of register... Certainly not 100 x at
the same time, and not all controls on the same page..

But when Access can not this feature, I must do as it can.

You may or may not like it, but that's the way it is.

Access is a data centric application development tool, VB
is not. Access controls are not the same as standard
windows, for performance reasons, Access was designed to use
"light weight" controls that are just pictures on the.
screen. The only standard control that has a (temporary)
hwnd is the control that has the focus.

I still have no idea what a "register control" is so I don't
feel comfortable addessing that part of your question.
However, if you're so inclined, you can revert to using APIs
to do a lot of non-standard stuff, but you will have to
write additional code to deal with data binding and all
kinds of other things that Access controls take care of
automatically.

A lot of folks have asked this kind of question of the years
and the answer is always the same: Precreate the invisible
controls at design time and make them visible as needed at
run time. Are you sure that you might have up to 100 of
them at once? How the heck are you going to fit all that
stuff on the screen at the same time?

Just in case we are communicating at cross purposes, I will
state that you can/should write a procedure that acts like a
mini, one time, design time wizard to create the controls.
If you really need that many copies of a set of controls, it
would be far less tedious than doing it all manually. Don't
forget about the limit of 754 controls while you're planning
all this.
--
Marsh
MVP [MS Access]

why I don't know in design time, how many controls will the user open.
I don't like add for example 100 pages and subforms to to form, allthough
the users oder the current table uses only 2.

With API we can create a window control dynamically in runtime, but I don't
know, how about access control (register control)...

In Visual Basic 6.0 we can also create a control in runtime, althought the
such a control doesn't exist on the form. I hopped, Access can it too.


Martin wrote:
I am not familiar with the term "register page", but instead
of adding a new subform control, you can open a separate
form. There is even a way to open the same form multiple
times.

yes, I know it, but this feature can not be the solution in my case. I
want
to use a form for a table, the first page (register) is for data, when
user
click on statisti, this form may create a new page and a subform on it,
which load the statistic form for this Table..., and this form is used
for
different Tables.... In design time I can not create static count for
pages
and subforms.

I can create in design time so many controls as it is posible, and set it
unvisible, and when it is necessary, I set them visible. But this is no
good
design...


Making controls visible/invisible is a far superior approach
to making design changes at run time. From what you've
said, that sounds like it might be the best way for you.

 

[Martin]

Access 2.0
and the register control of my friend is not a true register control, but a
combination of many labels, rectangle and he uses code to show and hide the
controls.

Martin

We are definitely having a terminology issue. Your use of
the words "register", "page" and "pieces" are too far out of
context for me to figure out what you mean in terms that I
use. I'm not even sure if "Access 20" is referring to
Access 2.0 or Access 2000.

You would probably be better off looking for a newsgroup in
your native language.
--
Marsh
MVP [MS Access]

I have a friend, he used access 20 and build an universal form for all
application, that means, instead of opening many windows he shows a new
subform on a a new page (which he wrote self, not register control of
access). On this form he creates many subforms and ... (he tells me 100
pieces).

I do like this solution, because the MDI style is lost. But in a module,
such as INVOICEs or Customers, I want to show their "component", such as
statistic, Summary, on another page of register... Certainly not 100 x at
the same time, and not all controls on the same page..

But when Access can not this feature, I must do as it can.

You may or may not like it, but that's the way it is.

Access is a data centric application development tool, VB
is not. Access controls are not the same as standard
windows, for performance reasons, Access was designed to use
"light weight" controls that are just pictures on the.
screen. The only standard control that has a (temporary)
hwnd is the control that has the focus.

I still have no idea what a "register control" is so I don't
feel comfortable addessing that part of your question.
However, if you're so inclined, you can revert to using APIs
to do a lot of non-standard stuff, but you will have to
write additional code to deal with data binding and all
kinds of other things that Access controls take care of
automatically.

A lot of folks have asked this kind of question of the years
and the answer is always the same: Precreate the invisible
controls at design time and make them visible as needed at
run time. Are you sure that you might have up to 100 of
them at once? How the heck are you going to fit all that
stuff on the screen at the same time?

Just in case we are communicating at cross purposes, I will
state that you can/should write a procedure that acts like a
mini, one time, design time wizard to create the controls.
If you really need that many copies of a set of controls, it
would be far less tedious than doing it all manually. Don't
forget about the limit of 754 controls while you're planning
all this.
--
Marsh
MVP [MS Access]


Martin wrote:
why I don't know in design time, how many controls will the user open.
I don't like add for example 100 pages and subforms to to form, allthough
the users oder the current table uses only 2.

With API we can create a window control dynamically in runtime, but I don't
know, how about access control (register control)...

In Visual Basic 6.0 we can also create a control in runtime, althought the
such a control doesn't exist on the form. I hopped, Access can it too.


Martin wrote:
I am not familiar with the term "register page", but instead
of adding a new subform control, you can open a separate
form. There is even a way to open the same form multiple
times.

yes, I know it, but this feature can not be the solution in my case. I
want
to use a form for a table, the first page (register) is for data, when
user
click on statisti, this form may create a new page and a subform on it,
which load the statistic form for this Table..., and this form is used
for
different Tables.... In design time I can not create static count for
pages
and subforms.

I can create in design time so many controls as it is posible, and

set
it

unvisible, and when it is necessary, I set them visible. But this

is
no

good
design...


Making controls visible/invisible is a far superior approach
to making design changes at run time. From what you've
said, that sounds like it might be the best way for you.

 

[Marshall Barton]

I guess "register control" is your own term for some UI
feature you are trying to implement, but since I don't what
feature you are trying to provide to your users, the term is
meaningless to me.

In any case, it sounds like your friend's approach is pretty
much what I have been suggesting to you. Using code to show
and hide existing controls is the standard way to do this
kind of thing and certainly the approach that I use.

At this point, I don't even know if that's the answer to
your question or if you are asking a different question.
--
Marsh
MVP [MS Access]

Access 2.0
and the register control of my friend is not a true register control, but a
combination of many labels, rectangle and he uses code to show and hide the
controls.

We are definitely having a terminology issue. Your use of
the words "register", "page" and "pieces" are too far out of
context for me to figure out what you mean in terms that I
use. I'm not even sure if "Access 20" is referring to
Access 2.0 or Access 2000.

You would probably be better off looking for a newsgroup in
your native language.

I have a friend, he used access 20 and build an universal form for all
application, that means, instead of opening many windows he shows a new
subform on a a new page (which he wrote self, not register control of
access). On this form he creates many subforms and ... (he tells me 100
pieces).

I do like this solution, because the MDI style is lost. But in a module,
such as INVOICEs or Customers, I want to show their "component", such as
statistic, Summary, on another page of register... Certainly not 100 x at
the same time, and not all controls on the same page..

But when Access can not this feature, I must do as it can.


You may or may not like it, but that's the way it is.

Access is a data centric application development tool, VB
is not. Access controls are not the same as standard
windows, for performance reasons, Access was designed to use
"light weight" controls that are just pictures on the.
screen. The only standard control that has a (temporary)
hwnd is the control that has the focus.

I still have no idea what a "register control" is so I don't
feel comfortable addessing that part of your question.
However, if you're so inclined, you can revert to using APIs
to do a lot of non-standard stuff, but you will have to
write additional code to deal with data binding and all
kinds of other things that Access controls take care of
automatically.

A lot of folks have asked this kind of question of the years
and the answer is always the same: Precreate the invisible
controls at design time and make them visible as needed at
run time. Are you sure that you might have up to 100 of
them at once? How the heck are you going to fit all that
stuff on the screen at the same time?

Just in case we are communicating at cross purposes, I will
state that you can/should write a procedure that acts like a
mini, one time, design time wizard to create the controls.
If you really need that many copies of a set of controls, it
would be far less tedious than doing it all manually. Don't
forget about the limit of 754 controls while you're planning
all this.
--
Marsh
MVP [MS Access]


Martin wrote:
why I don't know in design time, how many controls will the user open.
I don't like add for example 100 pages and subforms to to form, allthough
the users oder the current table uses only 2.

With API we can create a window control dynamically in runtime, but I
don't
know, how about access control (register control)...

In Visual Basic 6.0 we can also create a control in runtime, althought
the
such a control doesn't exist on the form. I hopped, Access can it too.


Martin wrote:
I am not familiar with the term "register page", but instead
of adding a new subform control, you can open a separate
form. There is even a way to open the same form multiple
times.

yes, I know it, but this feature can not be the solution in my case. I
want
to use a form for a table, the first page (register) is for data, when
user
click on statisti, this form may create a new page and a subform on
it,
which load the statistic form for this Table..., and this form is used
for
different Tables.... In design time I can not create static count for
pages
and subforms.

I can create in design time so many controls as it is posible, and set
it
unvisible, and when it is necessary, I set them visible. But this is
no
good
design...


Making controls visible/invisible is a far superior approach
to making design changes at run time. From what you've
said, that sounds like it might be the best way for you.