Access2000: Synchronizing forms

  • Thread starter Thread starter Arvi Laanemets
  • Start date Start date
A

Arvi Laanemets

Hi

In my project, I have a multi-page unbound form fmMain.
In one of pages, I want a certain item register designed as follows:
The is a subform sfMyReg0 with non-continous form fmMyReg0 as source.
fmMyReg0 will serve as a container:
Record Source = SELECT tblMyReg.* FROM tblMyReg WHERE
((([tblMyReg].[Type])=2));
Record Selectors = No;
Navigation Buttons = No;
There is a hidden textbox txtType (Value = 2) on fmMyReg;
There is also a subform sfMyReg1 with continous form fmMyReg1 as source:
Link Chield Fields = Type;
Link Master Fields = txtType.
(Whenever I add a new record in form fmMyReg1, the value for field
Type will be automatically =2)
fmMyReg1
Record Source = SELECT tblMyReg.* FROM tblMyReg WHERE
((([tblMyReg].[Type])=2));
(Record sources for both forms fmMyReg0 and fmMyReg1 are identical)
Record Selectors = Yes;
Navigation Buttons = Yes;

(As additional info, there will be other subforms on form fmMyReg, whith are
linked to field MyRegID of table tblMyReg - i.e. whenever some record is
activated in forms fmMyReg0 and fmMyReg1, a some specific info bound with
this record is displayed in those subforms)

What I need, is to synchronise both forms fmMyReg0 and fmMyReg1 - i.e.
whenever I navigate to any record in one form, the same record has to be
activated in another one too. And additionally, whenever I add a new record
in form fmMyReg1, the form fmMyReg0 has to cope with this situation too.

Currently I tried in Current event for fmMyReg1 to use
Me.Parent.Form.Bookmark = Me.Bookmark
, and I'll get
"Run-time error '2001':
You cancelled the previous operation."

I have been trying to cope with this a quite a lot of time now, so maybe
someone here can provide some help!
Thanks in advance!

Arvi Laanemets
 
Arvi

Since Access offers it, is there a design/business consideration that's
caused you to decide against using bound forms?

--

Regards

Jeff Boyce
Microsoft Access MVP

Disclaimer: This author may have received products and services mentioned in
this post. Mention and/or description of a product or service herein does
not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.
 
Hi Jeff

Practically I'm using bound forms (fmMyReg0>OtherSubforms). But I also want
there a list of items where I can enter and edit items, and which can also
usead to navigate between items. I can't have it directly as source for
sfMyReg0, because :
1) I can't use a continous form as parent one for linked subforms;
2) Continous form can't be multipage (fmMyReg0 is a multipage form too, like
fmMain is)

So in my application I have:
fmMain (multipage, unbound)
on every page:
a single form (contionous or non-contionous)
or
a multipage non-continous form (a container)
with continous or noncontionous subforms (like in current task).

Usually, when I want to use linked forms, I use a single form as parent one,
with record controls ans navigation combo at top or left side of page, and
add a page control (with linked subforms on pages) at bottom or right side
of parent form. (And usually there is too much info in record to display it
on continous form.) Current register I have problems with, doesn't have much
fields to speak of - only MyRegID and Type. The rest of info is variable
(i.e. the info is valid from some time moment, and until new info is added -
so all this info is stored in separtate transaction tables and is displayed
on linked subforms), or calculated (limited number of various current
values - last entries form aforemeant transaction tables - which aren't
editable). So there aren't any controls to have much use on single parent
form except key field ByRegID (Type is fixed). On continous form those
calculated values are much more informative.


Arvi Laanemets



Jeff Boyce said:
Arvi

Since Access offers it, is there a design/business consideration that's
caused you to decide against using bound forms?

--

Regards

Jeff Boyce
Microsoft Access MVP

Disclaimer: This author may have received products and services mentioned
in
this post. Mention and/or description of a product or service herein does
not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

Arvi Laanemets said:
Hi

In my project, I have a multi-page unbound form fmMain.
In one of pages, I want a certain item register designed as follows:
The is a subform sfMyReg0 with non-continous form fmMyReg0 as source.
fmMyReg0 will serve as a container:
Record Source = SELECT tblMyReg.* FROM tblMyReg WHERE
((([tblMyReg].[Type])=2));
Record Selectors = No;
Navigation Buttons = No;
There is a hidden textbox txtType (Value = 2) on fmMyReg;
There is also a subform sfMyReg1 with continous form fmMyReg1 as
source:
Link Chield Fields = Type;
Link Master Fields = txtType.
(Whenever I add a new record in form fmMyReg1, the value for
field Type will be automatically =2)
fmMyReg1
Record Source = SELECT tblMyReg.* FROM tblMyReg WHERE
((([tblMyReg].[Type])=2));
(Record sources for both forms fmMyReg0 and fmMyReg1 are identical)
Record Selectors = Yes;
Navigation Buttons = Yes;

(As additional info, there will be other subforms on form fmMyReg, whith
are linked to field MyRegID of table tblMyReg - i.e. whenever some record
is activated in forms fmMyReg0 and fmMyReg1, a some specific info bound
with this record is displayed in those subforms)

What I need, is to synchronise both forms fmMyReg0 and fmMyReg1 - i.e.
whenever I navigate to any record in one form, the same record has to be
activated in another one too. And additionally, whenever I add a new
record in form fmMyReg1, the form fmMyReg0 has to cope with this
situation too.

Currently I tried in Current event for fmMyReg1 to use
Me.Parent.Form.Bookmark = Me.Bookmark
, and I'll get
"Run-time error '2001':
You cancelled the previous operation."

I have been trying to cope with this a quite a lot of time now, so maybe
someone here can provide some help!
Thanks in advance!

Arvi Laanemets
Click to expand...
Click to expand...
 
I'm having a bit of trouble visualising what you mean by "pages" and a
"multipage form"...

I'm having trouble understanding a form that is used to navigate AND
add/edit. That sounds like a blend between a menu/switchboard and a form
bound to a record from a query or table.

I don't see how you have a form "on every page".

More info, please...

--

Regards

Jeff Boyce
Microsoft Access MVP

Disclaimer: This author may have received products and services mentioned in
this post. Mention and/or description of a product or service herein does
not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

Arvi Laanemets said:
Hi Jeff

Practically I'm using bound forms (fmMyReg0>OtherSubforms). But I also
want there a list of items where I can enter and edit items, and which can
also usead to navigate between items. I can't have it directly as source
for sfMyReg0, because :
1) I can't use a continous form as parent one for linked subforms;
2) Continous form can't be multipage (fmMyReg0 is a multipage form too,
like fmMain is)

So in my application I have:
fmMain (multipage, unbound)
on every page:
a single form (contionous or non-contionous)
or
a multipage non-continous form (a container)
with continous or noncontionous subforms (like in current task).

Usually, when I want to use linked forms, I use a single form as parent
one, with record controls ans navigation combo at top or left side of
page, and add a page control (with linked subforms on pages) at bottom or
right side of parent form. (And usually there is too much info in record
to display it on continous form.) Current register I have problems with,
doesn't have much fields to speak of - only MyRegID and Type. The rest of
info is variable (i.e. the info is valid from some time moment, and until
new info is added - so all this info is stored in separtate transaction
tables and is displayed on linked subforms), or calculated (limited number
of various current values - last entries form aforemeant transaction
tables - which aren't editable). So there aren't any controls to have much
use on single parent form except key field ByRegID (Type is fixed). On
continous form those calculated values are much more informative.


Arvi Laanemets



Jeff Boyce said:
Arvi

Since Access offers it, is there a design/business consideration that's
caused you to decide against using bound forms?

--

Regards

Jeff Boyce
Microsoft Access MVP

Disclaimer: This author may have received products and services mentioned
in
this post. Mention and/or description of a product or service herein does
not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

Arvi Laanemets said:
Hi

In my project, I have a multi-page unbound form fmMain.
In one of pages, I want a certain item register designed as follows:
The is a subform sfMyReg0 with non-continous form fmMyReg0 as source.
fmMyReg0 will serve as a container:
Record Source = SELECT tblMyReg.* FROM tblMyReg WHERE
((([tblMyReg].[Type])=2));
Record Selectors = No;
Navigation Buttons = No;
There is a hidden textbox txtType (Value = 2) on fmMyReg;
There is also a subform sfMyReg1 with continous form fmMyReg1 as
source:
Link Chield Fields = Type;
Link Master Fields = txtType.
(Whenever I add a new record in form fmMyReg1, the value for
field Type will be automatically =2)
fmMyReg1
Record Source = SELECT tblMyReg.* FROM tblMyReg WHERE
((([tblMyReg].[Type])=2));
(Record sources for both forms fmMyReg0 and fmMyReg1 are identical)
Record Selectors = Yes;
Navigation Buttons = Yes;

(As additional info, there will be other subforms on form fmMyReg, whith
are linked to field MyRegID of table tblMyReg - i.e. whenever some
record is activated in forms fmMyReg0 and fmMyReg1, a some specific info
bound with this record is displayed in those subforms)

What I need, is to synchronise both forms fmMyReg0 and fmMyReg1 - i.e.
whenever I navigate to any record in one form, the same record has to be
activated in another one too. And additionally, whenever I add a new
record in form fmMyReg1, the form fmMyReg0 has to cope with this
situation too.

Currently I tried in Current event for fmMyReg1 to use
Me.Parent.Form.Bookmark = Me.Bookmark
, and I'll get
"Run-time error '2001':
You cancelled the previous operation."

I have been trying to cope with this a quite a lot of time now, so maybe
someone here can provide some help!
Thanks in advance!

Arvi Laanemets
Click to expand...
Click to expand...
Click to expand...
 
Hi

As English isn´t my native language, and as I never really learned it,
sometimes I have it difficult to express myself clearly enough. :-(


Jeff Boyce said:
I'm having a bit of trouble visualising what you mean by "pages" and a
"multipage form"...
Click to expand...

Multipage form - a form with at least one tab control on it;
Page - a page of tab control;
Pages - a collection of pages of tab control.

I'm having trouble understanding a form that is used to navigate AND
add/edit. That sounds like a blend between a menu/switchboard and a form
bound to a record from a query or table.
Click to expand...

Usually you have some non-contionous parent form bound to a record from a
query/table, and on it:
1) a collection of controls to display/edit record info;
2) means to navigate between records, or to add a new record
(navigation buttons, combo box control, etc.)
3) optionally a tab control;
4) optionally one or many subforms linked with parent form.

What I want, is a non-continous parent form bound to a record from a
query/table, and on it:
1) a couple of hidden controls;
2) no navigation buttons (optionally there may be a combo box control
to select a record) - so the user doesn't confuse navigation buttons on
parent form and on subforms placed on tab control pages;
3) a tab control;
3) a contionous subform bound to same query/table, as parent form, and
synhronized with it, (!!! but not linked with it !!!) - on 1st page of tab
control;
3) optionally one or many subforms linked with parent form - every one
on own page of tab control.
The form on 1st page of tab conrol is an ordinary form - you can select a
record, edit or delete it, add a new record, etc. At same time it works like
combo control for parent form - whenever you activate a record on it, the
same record must be activated on parent form (and vice versa, when there
exists a combo navigatin control on parent form).


Arvi Laanemets
 
Hi

There vere a couple of numeration errors in last posting, s this is
corrected version of it!

As English isn´t my native language, and as I never really learned it,
sometimes I have it difficult to express myself clearly enough. :-(


Jeff Boyce said:
I'm having a bit of trouble visualising what you mean by "pages" and a
"multipage form"...
Click to expand...

Multipage form - a form with at least one tab control on it;
Page - a page of tab control;
Pages - a collection of pages of tab control.

I'm having trouble understanding a form that is used to navigate AND
add/edit. That sounds like a blend between a menu/switchboard and a form
bound to a record from a query or table.
Click to expand...

Usually you have some non-contionous parent form bound to a record from a
query/table, and on it:
1) a collection of controls to display/edit record info;
2) means to navigate between records, or to add a new record
(navigation buttons, combo box control, etc.)
3) optionally a tab control;
4) optionally one or many subforms linked with parent form.

What I want, is a non-continous parent form bound to a record from a
query/table, and on it:
1) a couple of hidden controls;
2) no navigation buttons (optionally there may be a combo box control
to select a record) - so the user doesn't confuse navigation buttons on
parent form and on subforms placed on tab control pages;
3) a tab control;
4) a contionous subform bound to same query/table, as parent form, and
synhronized with it, (!!! but not linked with it !!!) - on 1st page of tab
control;
5) optionally one or many subforms linked with parent form - every one
on own page of tab control.
The form on 1st page of tab conrol is an ordinary form - you can select a
record, edit or delete it, add a new record, etc. At same time it works like
combo control for parent form - whenever you activate a record on it, the
same record must be activated on parent form (and vice versa, when there
exists a combo navigatin control on parent form).


Arvi Laanemets
 
I'll offer another approach ...

You've been describing "how", as in how you are trying to accomplish
something. What that is is not yet clear, and I'm finding myself getting
confused by the "how".

If you'll post a description of "what", as in what business need/issue you
are trying to solve, folks here may be able to offer alternative
approaches...

Good luck!

--

Regards

Jeff Boyce
Microsoft Access MVP

Disclaimer: This author may have received products and services mentioned in
this post. Mention and/or description of a product or service herein does
not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.
 
Back
Top