Continuous Subform Won't Allow Moving To Next Rec?

P

PeteCresswell

Form.DefaultView=Continuous and, indeed, it does show multiple rows.

But only the first row can be selected: the user cannot click into any
other row.

Also, clicking the form's "forward" navigation button has no effect.

I'll swear this thing worked find last week.

Tried SaveAsText and LoadFromText, but no change - so I'm suspecting
that I fat-fingered some prop or other...

But which one?
 
K

Ken Snell \(MVP\)

I don't know of a specific property that would cause this behavior. How is
the form being opened -- manually? by code? by macro? If by code or macro,
show us the code line or the macro arguments. What are the properties that
you have set for the form? What is the form's RecordSource query's SQL
statement?
 
H

hatanaka

Ken Snell (MVP) said:
I don't know of a specific property that would cause this behavior. How is
the form being opened -- manually? by code? by macro? If by code or macro,
show us the code line or the macro arguments. What are the properties that
you have set for the form? What is the form's RecordSource query's SQL
statement?
Click to expand...
 
K

Ken Snell \(MVP\)

The images don't go all the way to the bottom of the properties list, but I
doubt that any of those unseen properties would lead to the problem that
you're seeing.

The subform has a Form_BeforeInsert procedure, which can block you from
doing anything that would move you from the first record to other records if
there is any type of data addition being done; but, with the AllowEdits and
etc. properties being set to No, I cannot imagine a situation where this
event procedure should be run. However, if there is any code in the
subform's form that would try to add a new record when you try to move to a
different record (for example, the Form_Current event procedure), that might
block navigation.

Also, is there any code in the Exit or LostFocus or GotFocus or Enter event
of any control in the subform itself? The behavior that you're seeing
suggests that an error occurring during a code operation, or the action of
code steps themselves, is cancelling the attempt to "leave" a control or a
record.

I do suggest that you move the code in the main form (setting the
RecordSource of the subform) from the Form_Open event to the Form_Load
event. I find inconsistent behavior if I try to use the Open event to
manipulate controls and their properties (including subform objects).

I suggest that you put a breakpoint on the first code step in all the VBA
code in the subform's form (form and control event procedures), and see
which code procedure is "triggered" when you try to navigate to a different
record. That should assist in subsequent debugging to find out what is
blocking the navigation action.
--

Ken Snell
<MS ACCESS MVP>




(PeteCresswell) said:
Per Ken Snell (MVP):
I don't know of a specific property that would cause this behavior. How is
the form being opened -- manually? by code? by macro? If by code or macro,
show us the code line or the macro arguments.
Click to expand...

It's a subform in a form that is being opened by code:
-----------------------------------------------------
Private Sub cmdAccount_Click()
debugStackPush Me.Name & ": cmdAccount_Click"
On Error GoTo cmdAccount_Click_err

' PURPOSE: To allow user to open up the trade functions screen

Dim myUserID As String

DoCmd.Hourglass True
myUserID = CurrentUserGet()

If Not IsTrader(myUserID) Then
DoCmd.Hourglass False
MsgBox "You need to contact the SFIM administrator and get on
the list of people allowed to trade.", vbExclamation, "User '" &
myUserID & "' Not Allowed To Trade."
Else
Me.Visible = False
With DoCmd
.OpenForm "frmSecurity"
.Hourglass False
End With
End If

cmdAccount_Click_xit:
DebugStackPop
On Error Resume Next
Exit Sub

cmdAccount_Click_err:
BugAlert True, ""
Resume cmdAccount_Click_xit
End Sub
----------------------------------------------------

What are the properties that you have set for the form?
Click to expand...

That's my prime suspicion.... that I've fat-fingered something...
but I'm at a loss as to what.

Rather than enumerate them laboriously here, how about a couple
of screen snaps: one of the parent form's props and one of the
subform's props?

Two for each bc I can't fit the whole props list on my
home PC's monitor.

Parent:
http://tinyurl.com/37d9fe
http://tinyurl.com/2wx33l

Subform:
http://tinyurl.com/3bnhgn
http://tinyurl.com/3dy9r8

.RecordSource not populated in the child bc it gets
assigned to the query below in Form_Open().

What is the form's RecordSource query's SQL
statement?
Click to expand...
Dirt simple: just selecting rows from a work table where there's
a hit on a PK called "SecurityID":
-----------------------------------------------
SELECT ttblSecurity_PaymentSchedule.*
FROM ttblSecurity_PaymentSchedule
WHERE
(((ttblSecurity_PaymentSchedule.SecurityID)=[forms]![frmSecurity]![txtSecurityID]))
ORDER BY ttblSecurity_PaymentSchedule.PaymentDate DESC;
Click to expand...
 
K

Ken Snell \(MVP\)

One other note.

Your code for opening the main form is using default values for most of the
method's arguments. These default argument values will override the
Properties that you've set in the main form's Properties window -- such as
AllowDeletions and AllowAdditions. Using your code, these properties will be
set to Yes for the form when it's opened.

To stop this from happening, use acFormEdit as the explicit sixth argument
for the OpenForm method:

Else
Me.Visible = False
With DoCmd
.OpenForm "frmSecurity", , , , , acFormEdit
.Hourglass False
End With
End If

--

Ken Snell
<MS ACCESS MVP>



Ken Snell (MVP) said:
The images don't go all the way to the bottom of the properties list, but
I doubt that any of those unseen properties would lead to the problem that
you're seeing.

The subform has a Form_BeforeInsert procedure, which can block you from
doing anything that would move you from the first record to other records
if there is any type of data addition being done; but, with the AllowEdits
and etc. properties being set to No, I cannot imagine a situation where
this event procedure should be run. However, if there is any code in the
subform's form that would try to add a new record when you try to move to
a different record (for example, the Form_Current event procedure), that
might block navigation.

Also, is there any code in the Exit or LostFocus or GotFocus or Enter
event of any control in the subform itself? The behavior that you're
seeing suggests that an error occurring during a code operation, or the
action of code steps themselves, is cancelling the attempt to "leave" a
control or a record.

I do suggest that you move the code in the main form (setting the
RecordSource of the subform) from the Form_Open event to the Form_Load
event. I find inconsistent behavior if I try to use the Open event to
manipulate controls and their properties (including subform objects).

I suggest that you put a breakpoint on the first code step in all the VBA
code in the subform's form (form and control event procedures), and see
which code procedure is "triggered" when you try to navigate to a
different record. That should assist in subsequent debugging to find out
what is blocking the navigation action.
--

Ken Snell
<MS ACCESS MVP>




(PeteCresswell) said:
Per Ken Snell (MVP):
I don't know of a specific property that would cause this behavior. How
is
the form being opened -- manually? by code? by macro? If by code or
macro,
show us the code line or the macro arguments.
Click to expand...

It's a subform in a form that is being opened by code:
-----------------------------------------------------
Private Sub cmdAccount_Click()
debugStackPush Me.Name & ": cmdAccount_Click"
On Error GoTo cmdAccount_Click_err

' PURPOSE: To allow user to open up the trade functions screen

Dim myUserID As String

DoCmd.Hourglass True
myUserID = CurrentUserGet()

If Not IsTrader(myUserID) Then
DoCmd.Hourglass False
MsgBox "You need to contact the SFIM administrator and get on
the list of people allowed to trade.", vbExclamation, "User '" &
myUserID & "' Not Allowed To Trade."
Else
Me.Visible = False
With DoCmd
.OpenForm "frmSecurity"
.Hourglass False
End With
End If

cmdAccount_Click_xit:
DebugStackPop
On Error Resume Next
Exit Sub

cmdAccount_Click_err:
BugAlert True, ""
Resume cmdAccount_Click_xit
End Sub
----------------------------------------------------

What are the properties that you have set for the form?
Click to expand...

That's my prime suspicion.... that I've fat-fingered something...
but I'm at a loss as to what.

Rather than enumerate them laboriously here, how about a couple
of screen snaps: one of the parent form's props and one of the
subform's props?

Two for each bc I can't fit the whole props list on my
home PC's monitor.

Parent:
http://tinyurl.com/37d9fe
http://tinyurl.com/2wx33l

Subform:
http://tinyurl.com/3bnhgn
http://tinyurl.com/3dy9r8

.RecordSource not populated in the child bc it gets
assigned to the query below in Form_Open().

What is the form's RecordSource query's SQL
statement?
Click to expand...
Dirt simple: just selecting rows from a work table where there's
a hit on a PK called "SecurityID":
-----------------------------------------------
SELECT ttblSecurity_PaymentSchedule.*
FROM ttblSecurity_PaymentSchedule
WHERE
(((ttblSecurity_PaymentSchedule.SecurityID)=[forms]![frmSecurity]![txtSecurityID]))
ORDER BY ttblSecurity_PaymentSchedule.PaymentDate DESC;
Click to expand...
Click to expand...
 
P

(PeteCresswell)

Per Ken Snell (MVP):
Your code...
Click to expand...

Thanks Ken.

I'll work your list of suggestions.

If I'm still striking out, I'll take some time and create a
sample .MDB that re-creates the problem.

If doing that doesn't smoke it out (often does, in my
experience...) I'll zip up the sample and post it for download
for the masochistically-inclined.
 
Top