Strange form behavior with AllowAdditions

[Brian]

Why is it that Access changes the behavior of unbound controls just because
AllowAdditions = False?

I have a bound continuous form that is used only for filtering & sorting
data for reporting purposes. The form header has several combo boxes that are
used for the user to select filters, which are then applied to the form (&
the form is consequently requeried) in the AfterUpdate of each of them.

In the KeyPress event of each of those combo boxes, I have this:

ControlDropdown (ASCII)

which in turn reference this public function:

Public Function ControlDropDown(Keystroke As Integer)
If Len(Screen.ActiveControl.Text) = 0 Then
Select Case Keystroke
Case 9, 13, 27 'ignore TAB, ENTER, ESC
Case Else
Screen.ActiveControl.Dropdown
End Select
End If
End Function

This has the net effect of dropping it down on the first keypress.

When I set the form's AllowAdditions property to False (for the sole purpose
of preventing the {AutoNumber} text in the PK field on a blank line at the
bottom of the form), then I get this behavior:

When I enter something in Control#1 & press Tab to navigate to Control#2
(both unbound on the form header), I get a message that I cannot reference
the property of Control #1 when it does not have the focus; that is, it
attempts to take the Tab keypress in Control #1 and apply the ActiveControl
to the wrong object (Control#2)

AllowAdditions also seems to prevent the refresh of the date-related filters
I set on button clicks. For example, a "This Month" button sets the values
of a BeginDate & EndDate control to the first & last days of the current
month, respectively. When I se the form's AllowAdditions (or Recordset to
Snapshot), the content of BeginDate & EndDate do not display until I click in
the box.

If I could find a way to simply load up the form as unbound, I guess I would
not have this problem (no need for AllowAdditions = True).

 

[Alex Dybenko]

Hi,
try to run me.recalc to get your controls updated, here how it helped me:
http://accessblog.net/2006/02/bound-forms-unbound-controls-do-not.html

--
Best regards,
___________
Alex Dybenko (MVP)
http://accessblog.net
http://www.PointLtd.com

 

[Allen Browne]

If the sole purpose here is to suppress the (AutoNumber) text in the new
row, perhaps you could use Conditional Formatting on the text box. Set it
to:
Expression Is ... [ID] Is Null
substituting your field name for ID, and choosing White text.

Cancel the form's BeforeInsert event if you want to block adding new
records.

There are bugs associated with the controls in the form when there are no
records to display and no new record can be added. Details in:
Incorrect display of data
at:
http://allenbrowne.com/bug-06.html

 

[Brian]

Thank you, Allen.

Yes, the entire purpose is to suppress the AutoNumber display. However, this
is a very busy form (necessary to provide the realtime functionality the
users want), it displays a lot of records, and some calculated fields.

I originally used the conditional format with white text, but my current
project is to speed up the refresh of the form as the user applies various
filters. It has to requery the DB on every filter change because of the
potential of other users adding relevant records. Removing the conditional
format was one of my target items for trying to speed up the form's
refresh/requery, but I may find that it had a minor effect anyway.

Disallowing additions itself is no problem because I have navigation
buttons off and allow additions only by a button click.

If the sole purpose here is to suppress the (AutoNumber) text in the new
row, perhaps you could use Conditional Formatting on the text box. Set it
to:
Expression Is ... [ID] Is Null
substituting your field name for ID, and choosing White text.

Cancel the form's BeforeInsert event if you want to block adding new
records.

There are bugs associated with the controls in the form when there are no
records to display and no new record can be added. Details in:
Incorrect display of data
at:
http://allenbrowne.com/bug-06.html

--
Allen Browne - Microsoft MVP. Perth, Western Australia

Reply to group, rather than allenbrowne at mvps dot org.

Why is it that Access changes the behavior of unbound controls just
because
AllowAdditions = False?

I have a bound continuous form that is used only for filtering & sorting
data for reporting purposes. The form header has several combo boxes that
are
used for the user to select filters, which are then applied to the form (&
the form is consequently requeried) in the AfterUpdate of each of them.

In the KeyPress event of each of those combo boxes, I have this:

ControlDropdown (ASCII)

which in turn reference this public function:

Public Function ControlDropDown(Keystroke As Integer)
If Len(Screen.ActiveControl.Text) = 0 Then
Select Case Keystroke
Case 9, 13, 27 'ignore TAB, ENTER, ESC
Case Else
Screen.ActiveControl.Dropdown
End Select
End If
End Function

This has the net effect of dropping it down on the first keypress.

When I set the form's AllowAdditions property to False (for the sole
purpose
of preventing the {AutoNumber} text in the PK field on a blank line at the
bottom of the form), then I get this behavior:

When I enter something in Control#1 & press Tab to navigate to Control#2
(both unbound on the form header), I get a message that I cannot reference
the property of Control #1 when it does not have the focus; that is, it
attempts to take the Tab keypress in Control #1 and apply the
ActiveControl
to the wrong object (Control#2)

AllowAdditions also seems to prevent the refresh of the date-related
filters
I set on button clicks. For example, a "This Month" button sets the
values
of a BeginDate & EndDate control to the first & last days of the current
month, respectively. When I se the form's AllowAdditions (or Recordset to
Snapshot), the content of BeginDate & EndDate do not display until I click
in
the box.

If I could find a way to simply load up the form as unbound, I guess I
would
not have this problem (no need for AllowAdditions = True).