Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Continuos form with unbound field automatically populates the next record!
222 views
Skip to first unread message
PW
Jan 3, 2014, 11:09:43 PM1/3/14
to
Hi,
I have a subform on a form that is a continuous form. The first
control (a combobox) is unbound. When I select something from it,
another record automatically appears under the record and has whatever
I populated the combobox above it with.
This has to be stopped. I can tell the continuous form to not allow
additions but this will not work.
If I bind the control source of the combobox to a field in the
underlying table (the one the value will be written to) I don't have
this problem. But I cannot bind this field to the table.
Any ideas?
-paulw
I have a subform on a form that is a continuous form. The first
control (a combobox) is unbound. When I select something from it,
another record automatically appears under the record and has whatever
I populated the combobox above it with.
This has to be stopped. I can tell the continuous form to not allow
additions but this will not work.
If I bind the control source of the combobox to a field in the
underlying table (the one the value will be written to) I don't have
this problem. But I cannot bind this field to the table.
Any ideas?
-paulw
PW
Jan 4, 2014, 12:01:33 AM1/4/14
to
the control source of the cbo to it and all is well!
-paulw
Patrick Finucane
Jan 4, 2014, 10:38:45 AM1/4/14
to
Access Developer
Jan 4, 2014, 4:16:12 PM1/4/14
to
Unless there has been a recent change of which I am unaware, the following
is the case:
Just to clarify and keep nomenclature straight: Forms do not have Fields.
Records have Fields which may be displayed and manipulated in Form Control
What appears to be multiple Detail Section in the Continuouus Form is
actually only one Form displayed multiple times; if the Controls are bound,
as you note, it will display the content of the Record; if you set the value
of the unbound Control, it will display that same value on each visible copy
of the Form in the Continuous Forms display.
I strongly suspect Microsoft Support will tell you it is "working as
designed".
This has most often showed up when people wanted to highlight certain values
by setting the backcolor of a bound Control, but change the backcolor once
and every visible copy is that same backcolor. In that case, a workaround
is to use Conditional Formatting to show the values in different colors.
But it's the same underlying factor/reason in your case. Unfortunately,
there is no Conditional Value to use as a workaround to your problem. I do
not recall ever seeing a successful workaround other than binding the
Control to a Field. That's the "usual solution", even if it means creating
a "dummy field" in the table, or even a "dummy table containing a dummy
field" to join as a source in a Query.
Perhaps if you would explain what you are trying to accomplish (rather than
how you are trying to implement it) with this unbound Control, someone here
could suggest an alternative approach. Many of us, over the years, have
_had_ to use alternate approaches to get the functionality we needed.
On the other hand, in Access' defense, it has historically been the simplest
and most flexible tool for creating individual, workgroup on LAN, and
client/server applications on LAN/WAN that were
somewhat-less-than-"enterprise" in scope.
Some believe that that, Microsoft, now focused on Access web-apps, are now
calling these features and functions Access "client", has neglected the
large customer base for these types of application, and, in fact, deleted
some features and functions useful in developing them. But others are just
happily continuing to develop "traditional" Access apps with recent
versions, as we see here in the newsgroup, in Microsoft forums, and in
Access-oriented websites such as Utter Access.
--
Larry Linson
Microsoft Office Access MVP
Co-Author, Microsoft Access Small Business Solutions, Wiley 2010
"PW" <emailad...@ifIremember.com> wrote in message
news:k32fc99r4oa7p97fp...@4ax.com...
is the case:
Just to clarify and keep nomenclature straight: Forms do not have Fields.
Records have Fields which may be displayed and manipulated in Form Control
What appears to be multiple Detail Section in the Continuouus Form is
actually only one Form displayed multiple times; if the Controls are bound,
as you note, it will display the content of the Record; if you set the value
of the unbound Control, it will display that same value on each visible copy
of the Form in the Continuous Forms display.
I strongly suspect Microsoft Support will tell you it is "working as
designed".
This has most often showed up when people wanted to highlight certain values
by setting the backcolor of a bound Control, but change the backcolor once
and every visible copy is that same backcolor. In that case, a workaround
is to use Conditional Formatting to show the values in different colors.
But it's the same underlying factor/reason in your case. Unfortunately,
there is no Conditional Value to use as a workaround to your problem. I do
not recall ever seeing a successful workaround other than binding the
Control to a Field. That's the "usual solution", even if it means creating
a "dummy field" in the table, or even a "dummy table containing a dummy
field" to join as a source in a Query.
Perhaps if you would explain what you are trying to accomplish (rather than
how you are trying to implement it) with this unbound Control, someone here
could suggest an alternative approach. Many of us, over the years, have
_had_ to use alternate approaches to get the functionality we needed.
On the other hand, in Access' defense, it has historically been the simplest
and most flexible tool for creating individual, workgroup on LAN, and
client/server applications on LAN/WAN that were
somewhat-less-than-"enterprise" in scope.
Some believe that that, Microsoft, now focused on Access web-apps, are now
calling these features and functions Access "client", has neglected the
large customer base for these types of application, and, in fact, deleted
some features and functions useful in developing them. But others are just
happily continuing to develop "traditional" Access apps with recent
versions, as we see here in the newsgroup, in Microsoft forums, and in
Access-oriented websites such as Utter Access.
--
Larry Linson
Microsoft Office Access MVP
Co-Author, Microsoft Access Small Business Solutions, Wiley 2010
"PW" <emailad...@ifIremember.com> wrote in message
news:k32fc99r4oa7p97fp...@4ax.com...
Joan Wild
Jan 5, 2014, 10:35:05 AM1/5/14
to
PW wrote:
>
> What I just did is to create a "dummy" field in the table and setting
> the control source of the cbo to it and all is well!
You should bind your form to a query, rather than the table. Add your
>
> What I just did is to create a "dummy" field in the table and setting
> the control source of the cbo to it and all is well!
'dummy' column to your query instead.
PW
Jan 6, 2014, 12:53:08 PM1/6/14
to
instead of tables.
Thanks!
-paul
Joan Wild
Jan 7, 2014, 11:00:11 AM1/7/14
to
PW
Jan 7, 2014, 1:43:29 PM1/7/14
to
On Tue, 7 Jan 2014 16:00:11 +0000 (UTC), "Joan Wild"
Something that I will most likely never use for anything. Simply to
satisfy the control source property to get the form to work right.
-paulw
satisfy the control source property to get the form to work right.
-paulw
0 new messages