Form and subform

A

a

I have a form (master form) and sub form

What I want

I want to put a button in a master form to change the view of the subform

from data sheet view to single form view
 
R

roger

I've been trying this. and I can't do it either. I even found the righyt
property
Forms!myform.mysubform.Form.CurrentView
but you can't set it at runtime.

You'd have to: turn echo off, close the mainform, open the subform in Design
view, change what views are allowed, then reopen the mainform, find your
record, and turn echo back on.

or

you could use a tab control and put a single record subform on one tab, and
a datasheet subform on tab 2.

Hmm?
 
M

Marshall Barton

Using two subforms is a good idea. And a tab control can
make the option obvious to users.

Using a option or command button to make one subform
invisible and the other visible is essentially the same
thing, but it provides a little more UI design flexibility.

OTOH, changing anything via design view is a really bad idea
for a host of serious reasons.
 
R

roger

OTOH, changing anything via design view is a really bad idea
for a host of serious reasons.

really? like what? (I'm actually asking, not being a dick)



Marshall Barton said:
Using two subforms is a good idea. And a tab control can
make the option obvious to users.

Using a option or command button to make one subform
invisible and the other visible is essentially the same
thing, but it provides a little more UI design flexibility.

OTOH, changing anything via design view is a really bad idea
for a host of serious reasons.
--
Marsh
MVP [MS Access]

I've been trying this. and I can't do it either. I even found the righyt
property
Forms!myform.mysubform.Form.CurrentView
but you can't set it at runtime.

You'd have to: turn echo off, close the mainform, open the subform in Design
view, change what views are allowed, then reopen the mainform, find your
record, and turn echo back on.

or

you could use a tab control and put a single record subform on one tab, and
a datasheet subform on tab 2.
 
M

Marshall Barton

roger said:
really? like what? (I'm actually asking, not being a dick)


Design change are the least efficient way to control
form/report behavior and the performance penalty can be
irritating.

There is a much greater chance of corruption when a heavy
duty object (i.e. table, form, report or module) is
modified. When that is done at run time, there are none of
the safety checks that a developer imposes when making
design time changes (e.g. frequent backups, ability to
notice strange behavior, ability to quickly recover without
data loss, etc).

Those heavy duty objects also take a lot of space so design
changes will bloat the file. Frequent design changes can
bloat the file very quicky.

Dealing with bloat means frequent compacting, which in turn
is an extremely heavy duty operation that can modify every
byte in the file and, if anything goes wrong, destroy the
file.

Because of all the potential problems, you need to create
and enforce robust, frequent backup procedures and the
ability to reliably restore or reinstall the file quickly.

Even if all that is ignored, the mdb file can not be
converted to an mde file because design changes can not be
made to an mde.

Then there are all the security issues accociated with the
design-change code behaving like a virus.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top