Computer hangs after switching report to Print Preview

[Petrol]

Hello everybody, Happy New Year.
My new year will be happier if I can figure out why my database hangs ...

I have a report which opens in Report view, but with Screen-only buttons on it to Print, Print Preview or Close. The Print Preview button calls an on-click event procedure as follows:

Private Sub cmdPreviewButton_Click()
Dim strReportName As String
strReportName = Me.Name
DoCmd.OpenReport strReportName, acViewPreview
End Sub
 

It all works fine.

But sometimes, instead of calling the report from the Switchboard, I need to call it in VBA with some OpenArgs from the on-click event of another form. When I do, it opens in Report view OK, but when I press the PrintPreview button it switches to print preview and then hangs. By "hangs", I mean that I can scroll up and down the report by mouse or keys, but nothing else I try in the Access window will work. I can't close the report, I can't switch to another tab in Access, I can't go to the navigation pane, I can't go to the code. But I can switch to another window (i.e. another application) and back, and then it's all alive again.

Stepping through the code, when I click the PrintPreview button it executes the OnClose routine, then the OnOpen and OnLoad and gets to the End Sub in line 5 of the above code, then goes nowhere.

Another clue: If I put a MsgBox between lines 4 and 5, the message is displayed ... and the system doesn't hang. Everything works fine. But I don't want a MsgBox there. So I tried replacing it with a DoEvents, but that was no good - it still hangs.

Another clue: If in the calling VBA I call it in PrintPreview directly, that works OK also.

Anyone got any ideas?

[NeoPa]

That seems a bit of a weird approach. Either you want to open it again from scratch, or you want to convert it to PrintPreview with existing settings.

If you want the former then you should get it to close itself first, before going on to open it again as per your requirements. This may work from within the code of the object itself or you may need to set a timer somewhere to trigger it once the current Report object has closed.

If you want the latter then you need to switch the mode rather than opening it again from scratch.

[Petrol]

Well it's definitely the latter that I want, but how do I switch mode?
I did find Report.CurrentView, but that's read-only (despite the note on docs.microsoft.com that it's read-write :( ). And a google search hasn't turned up any way to switch views without re-opening the report - only the other way round.

[NeoPa]

Ooops!

It seems I leapt before I looked there. I had assumed that would be an obvious facility to be provided within Access but when I look ... No such capability :-( At least none that I could find either.

In that case I would simply ask if your design is quite what you are looking for? Why have menu capability on a Report? Why not have a Form object that allows the operator to decide what it is that they want and separately, a Report object that displays the data you want reported.

I must admit I always struggled to see why it made sense to provide interactive capability on Reports. The only effect I would anticipate is to allow less experienced developers to get themselves deeper into the mess before realising what they're doing doesn't make sense. Sure it can save having to consider the design too carefully. For me though, that's never a good aim.

Sorry I misled you earlier. That was careless of me.

[Petrol]

Well it seems an eminently sensible thing to want to do. Often the user will just want to look at the report on screen, and Report view is by far the most convenient way to do so - Print Preview opens in page-at-a-time view and has to be clicked to make it readable, and then the PgDn key (or even Ctl+PgDn) won't go to the next page, you have to muck around with tiny pagination buttons at the bottom of the screen ... Report view is much easier to get along with, especially if the information occupies more than one page and you don't need a printout.

But occasionally the user does need a printout, to take to a meeting or something. So it's nice to be able to flip across to Print Preview to see how it will look. Why shouldn't it be possible? In fact, the fact that an expert like you "had assumed that would be an obvious facility to be provided within Access" is reason enough to expect it would be OK.

And Microsoft definitely understands the need in principle to have interactive reports - see, for example, https://support.office.com/en-us/art...f-5cf324c2c3bd.

But we're getting away from the point. As I said in the OP, the Print Preview button works beautifully if the report is invoked from the main switchboard. Why does it hang the computer when called through VBA, and how can I get around it?

[NeoPa]

Let me start by saying that, without the ability to switch modes being provided I don't see anything that I can help you with.

Now that's clear, let me clarify what I was actually saying, as you seem to have misinterpreted my earlier comment :
I see the idea of switching between live modes (anything that isn't a development mode.) as an obvious ability that's needed. If ever there are multiple modes that a user would use then the ability to switch between them seems an obvious requirement.

Does that mean I have, or would, ever suggest that a report should have an interactive mode? No. I neither said it nor implied it. To infer otherwise is simply wrong.

A view that enables you to navigate it more easily? Sure. If you like that I see no reason why you shouldn't have it. Having Command Buttons and/or other interactive Controls on a report? No. Never been a fan. It simply confuses people. From my PoV it's quite illogical.

I'm sorry I was unable to help, but my comments were neither illogical nor inconsistent. You may perfectly well choose to disagree with them, but please don't try to make it sound like I said anything other than what I actually said.