Multiple Records Selected

[Bill]

I have a form that uses continuous mode. When
I double-click the record-selector bar at a particular
record, another form is displayed with additional
details corresponding to the record selected. Not
always, but more often than not, when the detail
form display is closed and the invoking form re-
appears, the record-selector bar is highlighted
for the record selected plus the four (4) records
that precede it. I.e., ALWAYS 5 records have
the record-selector buttons highlighted.

I don't recall ever seeing this, but a user pointed it
out to me and I can re-produce it at will.

Does the invoking form need a RePaint in its code
sheet after the invocation statement for the detail
form?

Puzzled about this one.

Bill

 

[Bill]

I neglected to add that when there's a multiple
record highlighting that as soon as I click on any
one record the multiple record-selector hightlighting
disappears, as one would expect.
Bill

 

[Bill]

A Requery will clear the multiple highlighting, but that
naturally repositions to the beginning of the current
RecordSource, so that's not going to fix the problem.

Neither RePaint or ReFresh inserted after the "detail"
form invocation clear the multiple highlighting either.

Still scratching my head trying to think of what might
be causing the multiple highlighting.

Bill

 

[Dirk Goldgar]

I have a form that uses continuous mode. When
I double-click the record-selector bar at a particular
record, another form is displayed with additional
details corresponding to the record selected. Not
always, but more often than not, when the detail
form display is closed and the invoking form re-
appears, the record-selector bar is highlighted
for the record selected plus the four (4) records
that precede it. I.e., ALWAYS 5 records have
the record-selector buttons highlighted.

I don't recall ever seeing this, but a user pointed it
out to me and I can re-produce it at will.

Does the invoking form need a RePaint in its code
sheet after the invocation statement for the detail
form?

Puzzled about this one.

Me, too. I don't know what's causing it -- it doesn't happen for me in
a simple test form. If you want to post all the code in the form's
Current, Click, DblClick, and Activate events, as well as any code in
the detail form's events that might address this form at all, it may be
possible to figure out what's going on.

I don't think a Repaint would fix it. If you can't stop it from
happening in the first place, you could just reset the form's SelHeight
property to 1 to clear the multiple selection (or set it 0, to have no
records selected) . The question, since we don't know what's causing
the problem, is when to do that.

 

[Bill]

Dirk,
Below are code segments from each of the two forms involved.
I withheld code paths that are not involved in the actions taken
that lead to the mysterious multiple record-selectors highlighting.
No user actions are taken while in the "Detail Form". I.e., the
form is closed by the user immediately upon entry.
Bill


=========(CODE SHEET FOR LIST FORM)=========
Option Compare Database
Dim strTemp As String
Private Sub Form_Open(Cancel As Integer)
DoCmd.Maximize 'Open window
maximized
Me.AllowAdditions = False
Me.AllowDeletions = True
Me.AllowEdits = True
Me.FamilyTitleBar.Caption = IPName & " Families"
End Sub

Private Sub Form_DblClick(Cancel As Integer)
'===================================================================
'User has double-clicked upon the record selector adjacent to either
'a family name or a new "blank" table entry at the bottom of the
'table form.
'===================================================================

Dim frm As String
frm = "Family Details" 'Set the name for
Family details

If IsNull(Me.[FamilyName]) Then
DoCmd.OpenForm frm, , , , acAdd, , "NewEntry" 'Add a new family
Else
DoCmd.OpenForm frm, , , , acFormEdit, , Me.[FamilyID] 'Display
current family details
End If


End Sub


Private Sub Form_Load()
DoCmd.MoveSize 1, 1
End Sub
=========(END OF LIST FORM CODE SHEET)======
=========(CODE SHEET FOR DETAIL FORM)=======
Option Compare Database
Dim strTemp As String
Dim strRegAs As String
Dim strLName As String
Dim strFName As String
Dim CBDone As Boolean

Private Sub Form_Open(Cancel As Integer)
DoCmd.Maximize 'Open window maximized
If Me.OpenArgs = "RegisterDonor" Then
Me.AddFamilyMembers.Visible = False
Else
Me.AddFamilyMembers.Visible = True
End If

CBDone = False 'Open the gate for CB
initialization

End Sub


Private Sub Form_Load()
DoCmd.MoveSize 1, 1

If IsNull(Me.OpenArgs) Then 'Not being invoked subordinate
to table form.
Me.NavigationButtons = False
Else 'Being invoked with parameters.
If Me.OpenArgs = "NewEntry" Then Exit Sub

If Me.OpenArgs = "RegisterDonor" Then
Me.NavigationButtons = False
Me.AddFamilyMembers.Visible = False
Exit Sub
End If

'Move to the record specified in open parameter
If Me.OpenArgs = "NewEntry" Then Exit Sub
Me.RecordsetClone.FindFirst "[FamilyID] = " & Me.OpenArgs
Me.Bookmark = Me.RecordsetClone.Bookmark
FamilyName.SetFocus
Me.AllowAdditions = False
Me.AddNewMember.Visible = True

End If

SetImagePath
End Sub
Private Sub Form_Current()

'These two assignments fail if attempted in the OnLoad section.
If Me.OpenArgs = "RegisterDonor" Then
If CBDone = False Then
Me.FamilyDonOnly = True
Me.FamilyNewsLetter = False
CBDone = True
End If
Exit Sub
End If

'This sets the visible property of the subform to false if a new record, and
true if not a new record
Me.Family_Details_Subform.Visible = Not Me.NewRecord

'This enables the Add command button if it is a new record and disables it
if it is an old button.
Me.AddFamilyMembers.Enabled = Me.NewRecord
'We've changed records. See if we need to update the image as well.
Call SetImagePath
End Sub

Private Sub Form_Close()

If Me.OpenArgs = "RegisterDonor" Then 'We need any new names to
appear upon return.
Forms!DonFamEntry!FamilyNamesOnly.Form.Requery
End If

End Sub

Private Sub ImageID_AfterUpdate()
Call SetImagePath
End Sub

Private Sub SetImagePath()

Dim ImagePath As String
Dim DefaultImage As String
Dim RegisteredImage As String

DefaultImage = IPImages & "\DefaultPic.jpg" 'We'll use the
default if no other specified
RegisteredImage = IPImages & "\" & [ImageID] & ".jpg" 'This won't
exist if ImageID is zero-length string

'See if we have picture other than the default picture.
If Dir(RegisteredImage) = "" Then
ImagePath = DefaultImage
If Len(ImageID) > 0 Then 'The ID is
specified, but there's no corresponding jpg file
MsgBox "There's no JPEG file corresponding to the name: " & ImageID
& " The image name is being reset."
ImageID = Null
End If
Else
ImagePath = RegisteredImage
End If

If Me.PicturePath.Picture = ImagePath Then Exit Sub

Me.PicturePath.Picture = ImagePath
DoEvents

End Sub
Private Sub PicturePath_DblClick(Cancel As Integer)
'Full-screen picture called for. See if there's a "pps" version available?

'Dim ppsViewer As String
Dim strPicturePath As String
Dim RetVal

'See if we have picture other than the default picture.
If Len([ImageID] & "") = 0 Then
strPicturePath = IPImages & "\DefaultPic.jpg"
Else
strPicturePath = IPImages & "\" & [ImageID] & ".jpg"
End If
DoCmd.OpenForm "LargerImage", , , , , , strPicturePath

End Sub
=========(END OF DETAIL CODE SHEET)=========

 

[Dirk Goldgar]

Dirk,
Below are code segments from each of the two forms involved.
I withheld code paths that are not involved in the actions taken
that lead to the mysterious multiple record-selectors highlighting.
No user actions are taken while in the "Detail Form". I.e., the
form is closed by the user immediately upon entry.

[code snipped for brevity]

I don't see anything there that looks to me like it would cause the
behavior, except possibly something that might happen when you requery
Forms!DonFamEntry!FamilyNamesOnly -- and I don't know if that code path
is being taken. So I'm really at a loss.

Can you narrow down the exact circumstances, and hence the code path
taken, that causes the extra records to be selected? If you clear the
selection by setting Me.SelHeight = 0 before you ever open the Family
Details form, are any records selected on return from that form?

 

[Bill]

Dirk,
If I execute Me.SelHeight = 0 just before the "List Form"
invokes the "Details Form" in the "Double-Click" Sub of
the "List Form" code sheet, the record-selector that was
highlighted as the double-click action was taken becomes
un-highlighted. When I then close the "Details Form"
immediately upon entry, the record-selector button adjacent
to the record five (5) records prior to the record that received
the double-click is highlighted, but ONLY that record.

In experimenting, for any one record that when double-clicked
will reproduce the "multi-highlighting" upon return, the
"multi-highlighting"
will reproduce EVERY time. Yet, NOT ALL records will produce
the "multi-highlighting" when the double-click sequence is taken.

The multiple highlighting is though one held down the shift-key
and clicked on the record-selector button 4 records above the
first. Never four beyond the original position in the list, it's always
four prior in the list.

The Forms!DonFamEntry!FamilyNamesOnly.Requery is not
in the path when the multi-highlighting occurs.

I remain in total mystery as to what might be happening.

Bill

Dirk,
Below are code segments from each of the two forms involved.
I withheld code paths that are not involved in the actions taken
that lead to the mysterious multiple record-selectors highlighting.
No user actions are taken while in the "Detail Form". I.e., the
form is closed by the user immediately upon entry.

[code snipped for brevity]

I don't see anything there that looks to me like it would cause the
behavior, except possibly something that might happen when you requery
Forms!DonFamEntry!FamilyNamesOnly -- and I don't know if that code path
is being taken. So I'm really at a loss.

Can you narrow down the exact circumstances, and hence the code path
taken, that causes the extra records to be selected? If you clear the
selection by setting Me.SelHeight = 0 before you ever open the Family
Details form, are any records selected on return from that form?

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

 

[Bill]

Dirk,
Just "grasping for straws" here, but I was curious as to just how
consistently the RSH (Record-Selectors Highlighting) occur. I have
two continuous forms that are very similar and both have a double-
click event to "bring up" the detail behind the records being displayed.
On both of those forms, there are 20 records displayed. I went through
each of the records in succession twice in each of the two forms. On
each of those four passes, I get the RSH phenomenon in the exact
same positions: "4,5,6,7,,9,,,,13,14,,,,,,,".

I don't think the numbers mean anything, but I was hoping to get some
clue from the consistent behavior.

Hummmm! I just tried an experiment wherein I reset my 19" monitor to
a screen resolution of 800 x 600, which is the resolution I use when I
develope forms for general use. At that resolution, I don't get RSH
occurring at all. Later this evening, if I can make the time, I'll re-design
the form while my settings are at 1024 x 678 and see if that clears up
the problem. I'll post back again after I've done that.

Bill

Dirk,
Below are code segments from each of the two forms involved.
I withheld code paths that are not involved in the actions taken
that lead to the mysterious multiple record-selectors highlighting.
No user actions are taken while in the "Detail Form". I.e., the
form is closed by the user immediately upon entry.

[code snipped for brevity]

I don't see anything there that looks to me like it would cause the
behavior, except possibly something that might happen when you requery
Forms!DonFamEntry!FamilyNamesOnly -- and I don't know if that code path
is being taken. So I'm really at a loss.

Can you narrow down the exact circumstances, and hence the code path
taken, that causes the extra records to be selected? If you clear the
selection by setting Me.SelHeight = 0 before you ever open the Family
Details form, are any records selected on return from that form?

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

 

[Bill]

Dirk,
I made a couple of cosmetic changes to the "List Form" with
resolution settings at 1024 x 768 and saved it, but that didn't
have any affect on RSH. It's late, so I'll try to find time on
Thursday to build a continuous form from scratch at 1024
x 768 but copy the code sheet and try to reproduce the
multi-RSH.
Bill

Dirk,
Below are code segments from each of the two forms involved.
I withheld code paths that are not involved in the actions taken
that lead to the mysterious multiple record-selectors highlighting.
No user actions are taken while in the "Detail Form". I.e., the
form is closed by the user immediately upon entry.

[code snipped for brevity]

I don't see anything there that looks to me like it would cause the
behavior, except possibly something that might happen when you requery
Forms!DonFamEntry!FamilyNamesOnly -- and I don't know if that code path
is being taken. So I'm really at a loss.

Can you narrow down the exact circumstances, and hence the code path
taken, that causes the extra records to be selected? If you clear the
selection by setting Me.SelHeight = 0 before you ever open the Family
Details form, are any records selected on return from that form?

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

 

[Dirk Goldgar]

Dirk,
If I execute Me.SelHeight = 0 just before the "List Form"
invokes the "Details Form" in the "Double-Click" Sub of
the "List Form" code sheet, the record-selector that was
highlighted as the double-click action was taken becomes
un-highlighted. When I then close the "Details Form"
immediately upon entry, the record-selector button adjacent
to the record five (5) records prior to the record that received
the double-click is highlighted, but ONLY that record.

Interesting, and very odd.

In experimenting, for any one record that when double-clicked
will reproduce the "multi-highlighting" upon return, the
"multi-highlighting"
will reproduce EVERY time. Yet, NOT ALL records will produce
the "multi-highlighting" when the double-click sequence is taken.

Curiouser and curiouser.

I remain in total mystery as to what might be happening.

Me, too, so far.

 

[Dirk Goldgar]

Dirk,
Just "grasping for straws" here, but I was curious as to just how
consistently the RSH (Record-Selectors Highlighting) occur. I have
two continuous forms that are very similar and both have a double-
click event to "bring up" the detail behind the records being
displayed.
On both of those forms, there are 20 records displayed. I went through
each of the records in succession twice in each of the two forms. On
each of those four passes, I get the RSH phenomenon in the exact
same positions: "4,5,6,7,,9,,,,13,14,,,,,,,".

You mean, all three continuous forms display the same behavior? And the
behavior seems to be positional, so that it happens for records that are
fourth, fifth, sixth, and seventh, and ninth on the form, but not for
eighth or tenth? How very bizarre!

If you double-click to open the detail form, does the original form's
selection get changed (a) before the detail form appears, (b) after the
detail form appears but before it's closed, or (c) only after the detail
form is closed? In the Open event and the Close event of the detail
form, put the lines of code like the following:

' *** FOR DEBUGGING ***
With Forms!YourListFormName '*** Change to your form's name
Debug.Print .Name, "OPEN", .SelTop, .SelHeight
'*** Use "CLOSE" instead of "OPEN" for Close event
End With

Substitute the name of your list form for "YourListFormName" in the
above, and use "CLOSE" instead of "OPEN" for the form's Close event.
What appears in the Immediate Window when you double-click the original
form to open the detail form, then close it again, may give us a clue.
And then, after the details form is closed, open the Immediate Window
and (after noting what it says), enter the statement:

Debug.Print Screen.ActiveForm.SelTop, Screen.ActiveForm.SelHeight

That may help us see when in the course of events it happens, and also
demonstrate whether the properties are really being changed or if it's
just a display phenomenon.

I don't think the numbers mean anything, but I was hoping to get some
clue from the consistent behavior.

That makes sense. I still can't reproduce this here. Do those three
forms have anything else in common? Do they call common, user-written
functions?

Hummmm! I just tried an experiment wherein I reset my 19" monitor to
a screen resolution of 800 x 600, which is the resolution I use when I
develope forms for general use. At that resolution, I don't get RSH
occurring at all. Later this evening, if I can make the time, I'll
re-design the form while my settings are at 1024 x 678 and see if
that clears up
the problem. I'll post back again after I've done that.

If the screen resolution affects the behavior, that suggests the
possibility of a display driver bug, but I don't quite see how the
display driver could affect the SelHeight and SelTop properties.

Did you mention what versions of Access and of Windows are involved? Do
you and the client who reported this have similar configurations?

 

[Bill]

Dirk,
I'll pursue your suggestions later today, as my agenda for
today is beginning to load up.

The application in question is an Access 2000 application
running on XP-SP2.

The client experiencing the multi-RSH is configured almost
exactly like my machine, we even have the same 19" monitors.
Even as bazar as it might seem, maybe I ought to look into the
possibility of a driver issue.

I have another machine here with a 17" Dell monitor where I'll
install the application and see if it behaves the same way there.
I can probably do that within the hour.

Bill

 

[Bill]

Dirk,
The application in question behaves exactly the same way
on another machine that has a 17" flat-screen with settings
at 1024 x 768.

As soon as I can break free, I'll insert the debug statements
into the applicable code sheets and report my findings.

Bill

 

[Bill]

Curiosity got the best of me. Immediate Window
follows:
Immediate Window:======================================
Families OPEN 11 1
Families CLOSE 11 1
Debug.Print Screen.ActiveForm.SelTop, Screen.ActiveForm.SelHeight
11 1
'No RSH with double-click on record-selector #11
Families OPEN 10 1
Families CLOSE 6 5
Debug.Print Screen.ActiveForm.SelTop, Screen.ActiveForm.SelHeight
6 5
'RSH appears with double-click on record-selector #10
========================================================

Bill

 

[Bill]

Dirk,
It would appear that the "corruption" of select positions
occurs while in the detail form. One thing I should mention
is that the detail form does have a sub-form that includes
a record-selector bar. I experimented with double-clicking
of several of the records in the "List Form" to see if the
ensuing "Detail Form" had any records displaying in its
sub-form. There was no discernable pattern there. Some
of the records selected in the "List Form" resulted in
"sub-records" displayed in the "Detail Form's" sub-form
and some didn't. I could not see any correlation between
those that did and those that didn't as compared to whether
there was a multi-RSH or not.

Maybe the "Detail Form" simply needs to have code added
that preserves whatever is found in the SelTop & SelHeight?
I.e., capture at open and restore at close?

If you think that is the way to go, what would those statements
be?

Bill

 

[Dirk Goldgar]

Curiosity got the best of me. Immediate Window
follows:
Immediate Window:======================================
Families OPEN 11 1
Families CLOSE 11 1
Debug.Print Screen.ActiveForm.SelTop, Screen.ActiveForm.SelHeight
11 1
'No RSH with double-click on record-selector #11
Families OPEN 10 1
Families CLOSE 6 5
Debug.Print Screen.ActiveForm.SelTop, Screen.ActiveForm.SelHeight
6 5
'RSH appears with double-click on record-selector #10
========================================================

Wow. That's convincing. And we can see that it's not just a display
artifact -- form properties are being altered.

If you create a simple continuous form with no code in it but the
Form_DblClick event, and use that event to do nothing but open another
simple form (*not* the Family Details form), does the problem show
itself?

I can't help thinking there's something happening in your code
somewhere, but I don't see where in the code in Family Details this
could be happening. You don't have a timer event running in any form,
do you?

I can think of some things to do, more or less tedious:

1. Set a breakpoint in the Open event of form Family Details. Step
through all the code on the form, checking at entry and exit to each
procedure what is the value of Forms!Family.SelTop, to see when it
changes. When you've identified what procedure changes it, you let the
form finish and close, then set a breakpoint on that procedure and do it
again, stepping through that procedure line by line to see when the
value of Forms!Family.SelTop changes. That *ought* to enable you to
identify exactly what is making it happen, if it's being caused by code
on that form.

2. The only thing that I can see in the code on your form that is at all
unusual is your loading an image into Me.PicturePath. Maybe you could
try commenting that out and see if the problem still occurs.

 

[Bill]

Something I could do quickly was to take SetImagePath
out of the code path in the "Details Form". The problem
didn't go away but it did change the behavior. Namely,
if you look at the SetImagePath code, you see that when
families have a picture on file its fully qualified path is
inserted into the image control. Otherwise, the path of
a "default" picture is used instead, which is what is used
by the image control if it is NOT changed by code. With
the SetImagePath removed from the code path, ALL
records double-clicked in the "List Form" will produce
the multi-RSH.

The new discovery made during this experiment is that
the previuosly reported records that when double-clicked
DID NOT cause multi-RSH are those records that had
image files and those that didn't have jpg image files
available for display in the "Details Form" resulted in
multi-RSH when the "Details Form" closed.

If that doesn't help you to detect the cause, I'll continue
with your other "code stepping" suggestions later today.

Bill

 

[Bill]

Dirk,
I know your day is drawing close to an end.
What did you think of my 11:51AM post.
Do you still suggest that I go through the
"code stepping" approach?
Bill

 

[Dirk Goldgar]

Dirk,
I know your day is drawing close to an end.
What did you think of my 11:51AM post.
Do you still suggest that I go through the
"code stepping" approach?

It looks like something in the image processing is implicated, but I
haven't had time to digest it. I may be able to get back to this
tonight. In the mean time, you might want to step through the code in
that small section of the routine to try to pin down what specific line
causes the selection to change.

 

[Bill]

Okay, I'll get to it as soon as possible and post
back when I find the point.