How can I determine the "mode" of a Report? (1 Viewer)

[sja13]

Hi again guys....

I use VBA to execute a standard Report, and am controlling various pop-up forms which the User uses to initiate the reports.

The Reports are always initially opened in "Print Preview" mode.

When the User closes the Print Preview, I make the Form which initiated the report reappear by making it visible. This is done in the Report_Close VBA.

However, if the User just wants to change the View of the Report, say from Print Preview to Report View, the initiating Form re-appears, because the Close sequence is invoked during the "Change View" sequence.

On Opening, we get
OPEN
LOAD
ACTIVATE
GOTFOCUS

On Close, we get
UNLOAD
LOSTFOCUS
DEACTIVATE
CLOSE

None of these seem to have parameters indication the "mode" the print is being viewed in.

When changing from Print Preview to Report View, Access seems to go through a Close and Open sequence.

Is there a way I can detect that the Close routine isn't a "final" close, but a transition to another viewing mode?

Any, help, hints, or pointers will be gratefully received....

 

[bob fitz]

Perhaps you could declare a global variable in a general module who's value you could set and interrogate as required

 

[sja13]

Hi Bob - The problem is that I may know what state the Report was opened in, but I don't know which state it's going TO when the Close is issued. Is it a final Close, or just a step on the way to a another state (i.e. still open, just a different view)?

 

[isladogs]

It may be better to modify the code used when the report is closed to the 'parent' form.

Suggest you post the code in the Report Close event

 

[sja13]

Colin....

Not sure what you meant about modifying the code.
The actual code follows

Private Sub Report_Close()
  If Trim(gstrRepInvoker) <> "" Then
    Forms(gstrRepInvoker).Visible = True
    gstrRepInvoker = ""
  End If
End Sub

The variable "gstrRepInvoker" is a global string variable which contains the name of the Form whose Command Button invoked the print. On invoking the print, the Form was set to "invisible", so the above code returns us to that Form.
What was unexpected is that when a Report is visible, if the User decides to change the Report's view from "Print preview" to "Report View" (in order to see the whole report including summary details on the last page), the Report Close is executed. OK, that may not be so surprising, as the report is effectively being closed and reopened, but I'm trying to determine if this is a "Close and Exit" or a "Close and Reopen".

 

[Minty]

Could you check in the hidden / visible form if the report object is still open when it reactivates?

 

[sja13]

Minty....

Not sure what you mean about checking if the Object (Report?) is still open when it reactivates.

I've inserted simple MsgBoxes into the Report's VBA which give the sequence reported earlier. i.e.

On Opening, we get
OPEN
LOAD
ACTIVATE
GOTFOCUS

then on manually (i.e. not via VBA) changing the report view from Print Preview to Report View we get
UNLOAD
LOSTFOCUS
DEACTIVATE
CLOSE
OPEN
LOAD
ACTIVATE
GOTFOCUS

So the report is actually closed and reopened.

What I think I need to get a handle on is what settings does Access use to know that on the completion of the Close, it then needs to reopen the Report (in a different mode).

 

[Minty]

Okay - My Monday logic head says hide the calling form if it's visible, in the report open event then.

 

[sja13]

Not as easy as it sounds, 'cos sometimes the Form is opened from various bits of functionality, but I'll give it a go tomorrow (off to hospital now)....

 

[The_Doc_Man]

I don't know if this helps, but these threads at least seem similar. The solution is not to make X visible or invisible, but to make it not the top thing on the "visible stack" by bring the report to the front.

https://access-programmers.co.uk/forums/showthread.php?t=221287

The next thread does it via a Windows call for an application to be brought to the front.

https://access-programmers.co.uk/forums/showthread.php?t=132129

I include it because in theory, at least, even an Access child window has a whnd property that would be usable to feed to the User32 API that contains "Bring Window to Front" support routines.

 

[static]

Dim WithEvents rpt As Report

'open the report and get its events, hide this form
Private Sub Command0_Click()
    DoCmd.OpenReport "report1", acViewPreview
    Set rpt = Reports!report1
    'ensure close event is enabled
    'the report needs to have a module
    rpt.OnClose = "[event procedure]"
    Me.Visible = False
End Sub

Private Sub Form_Timer()
On Error Resume Next
    TimerInterval = 0
    
    Set rpt = Reports!report1
    If Err.Number Then
        Me.Visible = True 'report is closed
    Else
        Select Case rpt.CurrentView
        Case 0:
            Debug.Print ("Design view")
            'prevent user from editing this report
            DoCmd.Close acReport, rpt.Name
            Me.Visible = True
        Case 5: Debug.Print ("Print Preview")
        Case 6: Debug.Print ("Report view")
        Case 7: Debug.Print ("Layout view")
        End Select
    End If
End Sub

Private Sub rpt_Close()
    'check the report's status when close event is complete
    TimerInterval = 100
End Sub

 

[isladogs]

Having read your later replies, ignore my previous comment, which wasn't at all clear.

Could you bypass the issue completely by just disabling report view?

 

[The_Doc_Man]

I have "poked around" to see if there is a place where the mode of opening the report was stored anywhere. There is no obvious slot in the Report object, so Me.xxxx isn't going to help (or at least, so far I see no help.) This makes me wonder how access "knows" that a report is open in a preview mode, report view mode, or "normal mode" (which means it gets printed automagically), because that is going to affect which events fire. Different events fire in report-only-on-screen modes than fire for report-is-going-to-the-printer mode. (On Format vs. On Print). It HAS to know - but where.

So far, the object browser is not as helpful as it usually is for other such questions.