How to best coordinate Form_B with Form_A

[ThomasAJ]

Form_A has many controls AND a Tab Control. One of the tab's pages (Page_5)
is full and I cannot make the tab larger.

I want to have a new form (Form_B) that contains the Page_5 controls plus
more.

Form_B contents should change when I scroll thru Form_A.
Form_B should also update records when data changed on Form_B.
Form_B must not be navigatable. In other words only Form_A can navigate.

So how do I change the data in Form_B and how do I update records.

Sure I can code:
Forms("Form_B")(ControlName) = "abc" in Form_A for every control,
but is it possible to just feed in say the 'ProductCode' and let Form_B fill
the controls automatically. And update records also.

 

[Rick Brandt]

Form_A has many controls AND a Tab Control. One of the tab's pages
(Page_5) is full and I cannot make the tab larger.

I want to have a new form (Form_B) that contains the Page_5 controls
plus more.

Form_B contents should change when I scroll thru Form_A.
Form_B should also update records when data changed on Form_B.
Form_B must not be navigatable. In other words only Form_A can
navigate.

So how do I change the data in Form_B and how do I update records.

Sure I can code:
Forms("Form_B")(ControlName) = "abc" in Form_A for every control,
but is it possible to just feed in say the 'ProductCode' and let
Form_B fill the controls automatically. And update records also.

Is there a reason you don't just add another TabPage?

If you're thinking of a form/subform that are both editing the same record then
there will be problems with that. To Access they will have the same conflicts
as if two separate users were editing the record at the same time.

That would also suggest that you have a single table with LOTS of fields
indicating a serious design flaw.

 

[Linq Adams via AccessMonster.com]

Rick is absolutely correct about the problems you'll encounter with trying to
do this with a subform, and I have to question why you don't simply add
another tabbed page also.

As to

"That would also suggest that you have a single table with LOTS of fields
indicating a serious design flaw."

In reviewing the thread, I don't see anything to suggest that the form is, in
fact, based on a single table, but if it is there pretty much has to be major
normalization problems. While ther are always exceptions to any rule, most
experienced developers believe that a table with more than 25-35 fields
points towards non-normalization.

 

[ThomasAJ]

With due respect folks lets not waste time going down blind alleys. Let's not
make me redesign the world (aka the database in question) and all that would
imply, nor jump to conclusions.

1. Cannot add another tab.
2. Page5 controls would no longer exist in Form_A

So any ideas about co-ordinating two forms?

 

[ThomasAJ]

Where does subform come into play?

 

[Rick Brandt]

With due respect folks lets not waste time going down blind alleys.
Let's not make me redesign the world (aka the database in question)
and all that would imply, nor jump to conclusions.

1. Cannot add another tab.
2. Page5 controls would no longer exist in Form_A

So any ideas about co-ordinating two forms?

Forms and subforms are automatically "coordinated" by use of the MasterLink and
ChildLink properties of the subform control. They wouldn't be much use
otherwise. If the tables used in each form have a relationship defined then
Access will usually populate these properties automatically. If not then you
need to enter the related fields into them.