Multiple Records Selected

[Bill]

Dirk,
I noticed that I didn't answer an earlier question you
had about running a timer, to which the answer is no.

Well, I put begin/end debug statements in every sub
that runs when the "Details Form" runs. The "Sel"
values do not show being changed until the Close
event fires. AND, they are changed when the Close
sub BEGINS.

Anyway, with what I discovered with the Debug
insertions, I was led to think about what the code
might NOT be doing that could account for the
multi-RSH behavior. If you look at the SetImagePath
code below, notice that if what the code has determined
to be the fully qualified name and path of the "ImagePath"
is already set in the property sheet for the control, that the
code doesn't bother to set it again, which would seem
redundant and obviously why I coded it that way. However,
if I comment out the statement,

If Me.PicturePath.Picture = ImagePath Then Exit Sub

the seemingly now famous multi-RSH behavior ceases.

I looked at the property sheet for the image control in the
"Details Form" but don't see anything suspicious. The
"Picture" property contains the name and path of the
default image as originally coded.

I can't help but wonder if because the "Details Form" and
all of its controls were originally created with a screen
resolution of 800 x 600 that there's some elements of the
form's properties that don't adjust correctly if the form is
subsequently displayed at 1024 x 768.

I will proceed to create a simple continuous form with no
code in it but the Form_DoubleClick event as you suggested
earlier.

It's these goofy kinds of anomalies that keep me awake at
night. I hope this caper didn't do that to you too.

Bill




======(Sub SetImagePath=============================
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
================================================

 

[Dirk Goldgar]

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.

Am I right in thinking that PicturePath is an unbound image control?

How certain are you that the significant factor is whether the record
being double-clicked has an image file or not? I'm wondering if the
distinction is really whether a new image has to be loaded or not. Your
code only sets Me.PicturePath.Picture if it isn't currently equal to the
ImagePath for the new record. So if the form's current record is one
with its own picture, and then you double-click on a record that has no
picture (so the default image has to be loaded into the control), I'd
expect -- if this conjecture is correct -- that you'd get the same
behavior as if you had double-clicked a record with a different picture
of its own. This behavior might be different from what you'd see if you
were currently on a record that was showing the default picture, and now
you double-clicked on another record that has no picture of its own --
the default picture doesn't have to be changed, so no new image is
loaded.

If you follow what I'm saying in that last paragraph (and I don't know
how clear it is), could you check that out? Do you get one behavior
when the picture actually changes, and another when the picture doesn't
change?

 

[Dirk Goldgar]

Dirk,
I noticed that I didn't answer an earlier question you
had about running a timer, to which the answer is no.

Well, I put begin/end debug statements in every sub
that runs when the "Details Form" runs. The "Sel"
values do not show being changed until the Close
event fires. AND, they are changed when the Close
sub BEGINS.

Anyway, with what I discovered with the Debug
insertions, I was led to think about what the code
might NOT be doing that could account for the
multi-RSH behavior. If you look at the SetImagePath
code below, notice that if what the code has determined
to be the fully qualified name and path of the "ImagePath"
is already set in the property sheet for the control, that the
code doesn't bother to set it again, which would seem
redundant and obviously why I coded it that way. However,
if I comment out the statement,

If Me.PicturePath.Picture = ImagePath Then Exit Sub

the seemingly now famous multi-RSH behavior ceases.

Hah! I had just been wondering if that might be the case. You posted
this minutes before I posted my question about it.

I can't help but wonder if because the "Details Form" and
all of its controls were originally created with a screen
resolution of 800 x 600 that there's some elements of the
form's properties that don't adjust correctly if the form is
subsequently displayed at 1024 x 768.

I don't see why that should be the case, but who knows? The really odd
thing is that the eccentric behavior seems to be happening when you
*don't* load a new image into the image control, and not when you *do*
load an image. That's right, isn't it? It's so unexpected that I feel
the need to confirm it. I could understand something odd happening when
you load a new image into the control, but I don't see why something odd
would happen when you don't.

Where on the form is this image control? What section is it in? Is it
a standard Access image control?

It's these goofy kinds of anomalies that keep me awake at
night. I hope this caper didn't do that to you too.

Not yet, but it's getting there.

 

[Bill]

OhOh!!!!!!!! I can reproduce the mult-RSH behavior
with a simple continuous form with nothing in it but
a double-click event which then opens another "single"
mode form with nothing in it but a display of one field
in the first record of the RecordSource. NO image
controls at all!!!!

I'm not sure what to try now, having already found some
level of assurance that images were involved only to now
discover that there's more to this caper than "meets the
eye".

Bill

 

[Bill]

Standard image control located in the detail section of
the "Details Form". And yes, it's when I DON'T set
the Picture property that I get the multi-RSH behavior.

However, as you've new seen in my last post that I can
reproduce multi-RSH behavior without any images
involved at all.

I think I'll create a whole new database with the two
new forms and see if I can still produce the multi-RSH
behavior. If so, I'll then bring up a table from the back-end
mdb and see if I can still reproduce the problem. If so,
I'll have a small package that demonstrates the behavior
that I can send to you if you'd like.

Bill

 

[Dirk Goldgar]

OhOh!!!!!!!! I can reproduce the mult-RSH behavior
with a simple continuous form with nothing in it but
a double-click event which then opens another "single"
mode form with nothing in it but a display of one field
in the first record of the RecordSource. NO image
controls at all!!!!

I'm not sure what to try now, having already found some
level of assurance that images were involved only to now
discover that there's more to this caper than "meets the
eye".

Very interesting. I made such a form here, you know, and it does not
display the behavior you describe. How about you put those forms, with
the necessary recordsource table, in a new database and see if they
still act that way. If they do, compact that database, zip it up, and
send it to me at the address you get by removing NO SPAM from the
reply-address of this message.

 

[Dirk Goldgar]

OhOh!!!!!!!! I can reproduce the mult-RSH behavior
with a simple continuous form with nothing in it but
a double-click event which then opens another "single"
mode form with nothing in it but a display of one field
in the first record of the RecordSource. NO image
controls at all!!!!

I'm not sure what to try now, having already found some
level of assurance that images were involved only to now
discover that there's more to this caper than "meets the
eye".

I've now been able to reproduce this behavior, both in the database you
sent me and in my own test database, and both in Access 2002 and in
Access 97. The significant factor, which I hadn't realized before --
and which is why I couldn't reproduce it -- is that the continuous form
must be maximized. When the continuous form is in the restored state,
it doesn't happen, so far as I can determine. But when the continuous
form is maximized, then for some -- but not all -- records, the
selection on the continuous form is changed at some point after the
other form is opened, loaded, resized, and activated.

I added a Click event proc to the single form and used it to tell me
what the continuous form's SelHeight property was at the time I clicked
the form, so I know that the selection on the continuous form is
actually changed before the single form's Unload and Close events. Then
I put a similar check in the single form's Current event, and I found
that when the Current event first fires for the form, as part of its
opening sequence, the SelHeight is still 1, but if I go to another
record on the form, when the Current event fires for that the SelHeight
has been changed. My guess is that this is something that happens in an
independent processor thread, so it's just the timing of that thread
that controls when the selection changes; however, I don't know that
for sure yet.

Anyway, Bill, I'm pretty sure you've found a bona fide bug in Access.

 

[Bill]

Strange situation indeed. I would guess that our good
friends at Microsoft Office wouldn't want to spend much
time on the problem. If so, then I guess it would seem
appropriate at this time to develop a work-around.

Is it a simple matter of capturing the SelTop and SelHeight
values at Open in any subordinate form and restoring them
at Close? If that is the proper course of action to take, what
would be the applicable statements to use?

A good deal of your time and effort has been spent on this
problem and for that I'm grateful to you and also the fact
that we weren't wasting your time on a "wild goose chase"
of my making.

Bill

 

[Dirk Goldgar]

Strange situation indeed. I would guess that our good
friends at Microsoft Office wouldn't want to spend much
time on the problem. If so, then I guess it would seem
appropriate at this time to develop a work-around.

I'm afraid you're probably right, though I'll report it as a bug.

Is it a simple matter of capturing the SelTop and SelHeight
values at Open in any subordinate form and restoring them
at Close? If that is the proper course of action to take, what
would be the applicable statements to use?

That would probably do it, but I hate the idea of adding code to two
different events in every such form. I haven't had time to fiddle much
with other possible workarounds, though. Implementing your idea, but
making it a bit more general, I'm thinking of a public function with a
signature like this:

Function SaveRestoreSelection( _
frm As Access.Form, _ ' form to save or restore SelTop,
SelHeight
SaveIt As Boolean) ' True = save selection, False =
restore selection

In this function, you'd define a static Collection to which, if SaveIt =
True, you'd add a new member containing frm's current SelTop and
SelHeight settings, indexed by frm.hWnd. If SaveIt = False, you'd
retrieve and restore the form's settings from the collection, using
frm.hWnd as the index, and then remove that member from the collection.

Assuming this function, or something like it, could be made to work,
then you could call it directly from the OnLoad and OnClose event
properties of the subordinate form, using expressions like these:

(for OnLoad)
=SaveRestoreSettings([Forms]![ContinuousForm], True)

(for OnClose)
=SaveRestoreSettings([Forms]![ContinuousForm], False)

That would only work if you knew at design time which form was gong to
be opening this subordinate form, of course. If that's not possible,
you can use actual event procedures to capture and store that form's
name, and then call the function appropriately.

I'd rather find a workaround that you need only implement in the calling
form. That way, you would only need to do it when and where it's
necessary. But I don't know if that will be possible.

None of this would be necessary if you opened the subordinate form in
dialog mode -- the phenomenon doesn't happen then, as far as I can see.

A good deal of your time and effort has been spent on this
problem and for that I'm grateful to you and also the fact
that we weren't wasting your time on a "wild goose chase"
of my making.

I'm glad it didn't turn out that way. I have to admit, I was prepared
to blame something in your code, but you're fully exonerated. <g>

 

[Bill]

Does Microsoft pay any added attention when a bug is
reported by a MVP?

Since the bug doesn't seem to manifest in my situation
when the "Details Form" explicitly sets the Picture
property in the forms image control, be it redundant
or otherwise, I'll leave it at that until I perhaps hear
from you again on the subject. I'll leave the thread
"flagged" so that I'll see any news or follow-on
thoughts you have.

Thanks a million,
Bill

Strange situation indeed. I would guess that our good
friends at Microsoft Office wouldn't want to spend much
time on the problem. If so, then I guess it would seem
appropriate at this time to develop a work-around.

I'm afraid you're probably right, though I'll report it as a bug.

Is it a simple matter of capturing the SelTop and SelHeight
values at Open in any subordinate form and restoring them
at Close? If that is the proper course of action to take, what
would be the applicable statements to use?

That would probably do it, but I hate the idea of adding code to two
different events in every such form. I haven't had time to fiddle much
with other possible workarounds, though. Implementing your idea, but
making it a bit more general, I'm thinking of a public function with a
signature like this:

Function SaveRestoreSelection( _
frm As Access.Form, _ ' form to save or restore SelTop,
SelHeight
SaveIt As Boolean) ' True = save selection, False =
restore selection

In this function, you'd define a static Collection to which, if SaveIt =
True, you'd add a new member containing frm's current SelTop and
SelHeight settings, indexed by frm.hWnd. If SaveIt = False, you'd
retrieve and restore the form's settings from the collection, using
frm.hWnd as the index, and then remove that member from the collection.

Assuming this function, or something like it, could be made to work,
then you could call it directly from the OnLoad and OnClose event
properties of the subordinate form, using expressions like these:

(for OnLoad)
=SaveRestoreSettings([Forms]![ContinuousForm], True)

(for OnClose)
=SaveRestoreSettings([Forms]![ContinuousForm], False)

That would only work if you knew at design time which form was gong to
be opening this subordinate form, of course. If that's not possible,
you can use actual event procedures to capture and store that form's
name, and then call the function appropriately.

I'd rather find a workaround that you need only implement in the calling
form. That way, you would only need to do it when and where it's
necessary. But I don't know if that will be possible.

None of this would be necessary if you opened the subordinate form in
dialog mode -- the phenomenon doesn't happen then, as far as I can see.

A good deal of your time and effort has been spent on this
problem and for that I'm grateful to you and also the fact
that we weren't wasting your time on a "wild goose chase"
of my making.

I'm glad it didn't turn out that way. I have to admit, I was prepared
to blame something in your code, but you're fully exonerated. <g>

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

(please reply to the newsgroup)