Wrong "Record ID"?

[Bill]

I have a situation that is more of a nuisance than
a problem per se'.

I have an application wherein a record is selected
via a "right-click" in the "Record Selector" area of
a form. The right-click menu invokes a function in
the code sheet of the form that in turn issues a
DoCmd.OpenReport passing the RecordID
(Me.WorkID) of the record corresponding to
the "Record Selector".

The report previews the particulars of what is
contained in that record.

Now, not always but more often than not, if I then
right-click on another record I get the same report
again. When I then close the preview and re-select
the same record with the right-click, I get the
correct report content.

Symptomatically, it appears that the RecordID does
not always get updated to the current record as fast
as the report is executed by the right-click function,
which doesn't make sense to me, but again, that's
the symptomatic behavior.

Any ideas?

Bill Stanton

 

[Marshall Barton]

I have a situation that is more of a nuisance than
a problem per se'.

I have an application wherein a record is selected
via a "right-click" in the "Record Selector" area of
a form. The right-click menu invokes a function in
the code sheet of the form that in turn issues a
DoCmd.OpenReport passing the RecordID
(Me.WorkID) of the record corresponding to
the "Record Selector".

The report previews the particulars of what is
contained in that record.

Now, not always but more often than not, if I then
right-click on another record I get the same report
again. When I then close the preview and re-select
the same record with the right-click, I get the
correct report content.

Symptomatically, it appears that the RecordID does
not always get updated to the current record as fast
as the report is executed by the right-click function,
which doesn't make sense to me, but again, that's
the symptomatic behavior.

That would be the expected(?) behavior if the report's
preview was not closed before you selected a different
record.

It is possible to check if the report is already open and to
then change its Filter property instead of trying to open ab
alredy open report.

 

[Bill]

I "X" out of the report and there's no way to predict
if another selection is forthcoming, so perhaps I need
to test to see if it's closed and wait until it does? That
sounds like a great way to loop in wait forever?

Since I suspect there's a timing issue here, It doesn't
seem that changing the filter will do the job if the report
is in the process of closing? Unless changing the filter
effectively cancels the close? If that's the case, then
I'd simply change the filter if I find the report open.

What's the method to test for report open? Something
like Me.Reports(reportname) = true?

Bill

 

[Marshall Barton]

You can use CurrentProject.AllReports!myreport.IsLoaded to
check if a report is open.

If you do exit out of the report before selecting a
different record, then I guess you could have a timing issue
even if I've never seen it. For this scenario, opening the
report in dialog mode might(?) change the timing.

The alternative I was thinking of is to check if the report
is already open and, if not, opening it. If it is open,
just set the report's Filter property. (Note: this concept
is based on the fact that setting an open report's Filter or
OrderBy property (re)initates the report's Open event.)
This would probably be more efficient, but the UI might be
more confusing if you can not see the form behind the
report.

 

[Bill]

I'll play with this some more with some added code to
check "IsLoaded" and see if I can't narrow down the
sequence of user operations whereby I can re-produce
the problem at will.

I'll not likely get to this until later today.

Thanks Marsh,
Bill

You can use CurrentProject.AllReports!myreport.IsLoaded to
check if a report is open.

If you do exit out of the report before selecting a
different record, then I guess you could have a timing issue
even if I've never seen it. For this scenario, opening the
report in dialog mode might(?) change the timing.

The alternative I was thinking of is to check if the report
is already open and, if not, opening it. If it is open,
just set the report's Filter property. (Note: this concept
is based on the fact that setting an open report's Filter or
OrderBy property (re)initates the report's Open event.)
This would probably be more efficient, but the UI might be
more confusing if you can not see the form behind the
report.
--
Marsh
MVP [MS Access]

I "X" out of the report and there's no way to predict
if another selection is forthcoming, so perhaps I need
to test to see if it's closed and wait until it does? That
sounds like a great way to loop in wait forever?

Since I suspect there's a timing issue here, It doesn't
seem that changing the filter will do the job if the report
is in the process of closing? Unless changing the filter
effectively cancels the close? If that's the case, then
I'd simply change the filter if I find the report open.

What's the method to test for report open? Something
like Me.Reports(reportname) = true?

"Marshall Barton" wrote

 

[Bill]

Marsh,
I can't "nail it down" to a point of re-producing at will.

The normal end user process is to create the report.
Then, while the report is in preview, he/she presses
the "Print Screen" to capture the report as a picture
and switch to a image editor to manipulate and save
the results. It's after that that the report is "X'd".

A couple of time, my driving form's code sheet reported
that the report was "loaded" when the report path was
again taken.

I can't imagine how task switching would confuse Access?

Thanks,
Bill

I'll play with this some more with some added code to
check "IsLoaded" and see if I can't narrow down the
sequence of user operations whereby I can re-produce
the problem at will.

I'll not likely get to this until later today.

Thanks Marsh,
Bill

You can use CurrentProject.AllReports!myreport.IsLoaded to
check if a report is open.

If you do exit out of the report before selecting a
different record, then I guess you could have a timing issue
even if I've never seen it. For this scenario, opening the
report in dialog mode might(?) change the timing.

The alternative I was thinking of is to check if the report
is already open and, if not, opening it. If it is open,
just set the report's Filter property. (Note: this concept
is based on the fact that setting an open report's Filter or
OrderBy property (re)initates the report's Open event.)
This would probably be more efficient, but the UI might be
more confusing if you can not see the form behind the
report.
--
Marsh
MVP [MS Access]

I "X" out of the report and there's no way to predict
if another selection is forthcoming, so perhaps I need
to test to see if it's closed and wait until it does? That
sounds like a great way to loop in wait forever?

Since I suspect there's a timing issue here, It doesn't
seem that changing the filter will do the job if the report
is in the process of closing? Unless changing the filter
effectively cancels the close? If that's the case, then
I'd simply change the filter if I find the report open.

What's the method to test for report open? Something
like Me.Reports(reportname) = true?

Bill wrote:

I have a situation that is more of a nuisance than
a problem per se'.

I have an application wherein a record is selected
via a "right-click" in the "Record Selector" area of
a form. The right-click menu invokes a function in
the code sheet of the form that in turn issues a
DoCmd.OpenReport passing the RecordID
(Me.WorkID) of the record corresponding to
the "Record Selector".

The report previews the particulars of what is
contained in that record.

Now, not always but more often than not, if I then
right-click on another record I get the same report
again. When I then close the preview and re-select
the same record with the right-click, I get the
correct report content.

Symptomatically, it appears that the RecordID does
not always get updated to the current record as fast
as the report is executed by the right-click function,
which doesn't make sense to me, but again, that's
the symptomatic behavior.

That would be the expected(?) behavior if the report's
preview was not closed before you selected a different
record.

It is possible to check if the report is already open and to
then change its Filter property instead of trying to open ab
alredy open report.

 

[Marshall Barton]

I can't "nail it down" to a point of re-producing at will.

The normal end user process is to create the report.
Then, while the report is in preview, he/she presses
the "Print Screen" to capture the report as a picture
and switch to a image editor to manipulate and save
the results. It's after that that the report is "X'd".

A couple of time, my driving form's code sheet reported
that the report was "loaded" when the report path was
again taken.

I can't imagine how task switching would confuse Access?

Whoa, that scenario is so far beyond anything I've ever
tried that I don't have a clue about the interactions
between all those Windows processes. The only way I know of
for Access to give Windows more time for other processes is
to use one or more strategically placed DoEvents statements.

There has got to be a better way than using print screen.
You might want to dig around around in www.lebans.com for
some of Stephen's report conversion utilities.

 

[Bill]

Marsh,

I can see where Windows might be busy servicing a
page fault when bouncing back to Access causing a
bit of a delay, but with only two tasks open and 2GB
of RAM, I can't imagine there's a page swap issue?

Anyway, I searched around on Stephen's site, but
I couldn't find a utility to convert a report to jpeg or
even bit map. (Stephen does have a utility to convert
a relationship screen to bit map, but that's the only
thing I see that's even close.)

Thanks for your thoughts on the issue.

Bill