Minimize the Access Window

[GraeagleBill]

so I enlarged it to the required size

Wanting to follow the same steps as you described, I too changed to acViewPreview but when I opened it via the "Print" button I didn't get anything big enough with drag handles, . Is there some other way other than drag handles so I can resize as you did?

[isladogs]

I just dragged on the border and enlarged it.
Did v7.1 work for you?

[GraeagleBill]

Yes, V7.1 opened the report as it did for you. But, as I said in my last post that there weren't any drag handles to be had on the tiny window shown in #31 that popped up with the acViewPreview having been set in the OpenReport in frmRegistry. So, without drag handles on the borders I don't know how I can enlarge as you did.

[GraeagleBill]

Is this real data?

Yes, thank you, probably best that it be deleted.

[isladogs]

Screenshot now removed. I've left the zip file as I believe it didn't include any data

[GraeagleBill]

Based on a past experience with copy/paste of text box and label controls from one form/report to another AND ending up with a corrupted form/report, I decided that with since all of your efforts and mine that perhaps I'd unwittingly done something similar with the troublesome report. With that thought in mind, I created a new rptDirectory from scratch using the exact properties that you used with 7.1 and adding the new report to the original 7.0 with the hidden Access window and so far the report displays correctly.

The experience here now is that taking the original rptDirectory and applying the exact properties you used in 7.1 still fails on my app with acViewReport giving me only the top bar and acViewPreview giving me more-or-less the same bar but only a quarter of an inch wide, neither having border drag handles.

I'll delete the image below after you've had a chance to see it.

[GraeagleBill]

Based on a past experience with copy/paste of text box and label controls from one form/report to another AND ending up with a corrupted form/report, I decided that with since all of your efforts and mine that perhaps I'd unwittingly done something similar with the troublesome report. With that thought in mind, I created a new rptDirectory from scratch using the exact properties that you used with 7.1 and adding the new report to the original 7.0 with the hidden Access window and so far the report displays correctly.

The experience here now is that taking the original rptDirectory and applying the exact properties you used in 7.1 still fails on my app with acViewReport giving me only the top bar and acViewPreview giving me more-or-less the same bar but only a quarter of an inch wide, neither having border drag handles.

I'll delete the image below after you've had a chance to see it.

[isladogs]

OK I've seen both screenshots.
Not sure why you didn't just use the fixed version of the report that I supplied in v7.1.

Anyway, I believe you are now sorted!

[GraeagleBill]

Not sure why you didn't just use the fixed version of the report that I supplied in v7.1

That was my first inclination. My only reservation stemmed from my plaguing thoughts as to why what worked perfectly in V6.0 gave so much trouble when all I did was to add your hidden Access Window code. That is, what caused the report window to become inoperable............. unless it might be corrupted and just waiting for conditions to change that would send it "into the tank". I do think I'll go with what you produced and change the font size so that things fit better and I can stay with portrait orientation. I will, however, hang onto rptDirectory72 that I created this morning in case another failure flares up.

As usual, you've been most gracious in helping be with these problems, so I thank you most sincerely,
Bill

(PS) I can leave the 2nd screenshot, as there's nothing there to be concerned about and it might be of help to others.

EDIT: LATER THIS EVENING................

I tried to print the report via the "Print" command button and the event code taken from your original sample report, I just added the Ctrl test so I could either print or send to a pdf.

Private Sub cmdPrint_MouseDown(Button As Integer, Shift As Integer, X As Single, Y As Single)
'*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
'  The default is to output the report to a PDF formatted file.  If the Ctrl
'  key is down when the Print command button is selected, the user wants the
'  report printed out hard-copy to the default printer.
'*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
On Error GoTo Err_Handler

If (Shift And acCtrlMask) Then
        DoCmd.PrintOut           'User wants to print on default printer
    Else
        MsgBox "Printing to a PDF"    'User wants the default output to a PDF
End If
    
Exit_Handler:
    Exit Sub

Err_Handler:
    strProc = "cmdPrint_Click"
    If Err <> 2501 Then 'err 2501 - user cancelled printing
        MsgBox "Error " & Err.Number & " in " & strProc & " procedure : " & Err.description
    End If
    Resume Exit_Handler
End Sub

I get the 2585 error when I click on the Print command button.

[isladogs]

Hi
First of all you forgot to remove the first screenshot in post #36.

I think your added code should be on a KeyDown event - NOT a MouseDown event.
You also need to set KeyPreview to Yes

However when I tried that I got error 2501 when opening the report
I've never tried running code like that on a dialog report before and it may not be possible.

Suggest you either:
1. Have two buttons to either do a print out or Print to PDF
OR
2. Use Print Preview where the ribbon will provide the options you want

Personally I'd do the latter but then I rarely use Report View as I see little use in doing so

[GraeagleBill]

Have two buttons to either do a print out or Print to PDF

That's how I'd originally implemented the functionality in V6.0, but when I first saw your "Print" button in your example report I thought that looked a little more user friendly so I switched. I will go back to my original configuration but use the KeyDown in the invoking form to control print options.

EDIT: On 2nd thought, your option #2 makes more sense so I can quit screwing around with this report.

[isladogs]

Excellent. Much easier all round.
AFAIAC, both report view & layout view are fairly pointless. I just use design view & print preview ...except when demonstrating approaches in sample databases like this one!

[GraeagleBill]

User says even better, in that 99% of the time they want a PDF rather than paper. SO I gave them this:

Private Sub cmdPrint_Click()
'*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
'  The default is to output the report to a PDF formatted file that the user
'  can name to their satisfaction.  If the user wants to get hardcopy, the
'  default PDF client can carry out the printing.
'*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
strRptRecSrc = Me.RecordSource     'RecordSource for report changes as we change
strRptFilter = Me.Filter
strRptSort = SortColumn

On Error GoTo Err_Handler

DoCmd.OutputTo acOutputReport, "rptDirectory", acFormatPDF, , True
    
Exit_Handler:
    Exit Sub

Err_Handler:
    strProc = "cmdPrint_Click"
    If Err <> 2501 Then 'err 2501 - user cancelled printing
        MsgBox "Error " & Err.Number & " in " & strProc & " procedure : " & Err.description
    End If
    Resume Exit_Handler
End Sub

[isladogs]

Fine but occasionally they want a printed copy, even if only 1% of the time.
Using Print Preview just makes the process so much simpler.

[GraeagleBill]

I did try that with adding a ShowRibbon in the OnOpen, but when that didn't work I just moved on.