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.
Yes, thank you, probably best that it be deleted.Is this real data?
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.
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.
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!
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.Not sure why you didn't just use the fixed version of the report that I supplied in v7.1
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.
I get the 2585 error when I click on the Print command button.Code: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
Last edited by GraeagleBill; 05-05-2021 at 11:56 PM.
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
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.Have two buttons to either do a print out or Print to PDF
EDIT: On 2nd thought, your option #2 makes more sense so I can quit screwing around with this report.
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!
User says even better, in that 99% of the time they want a PDF rather than paper. SO I gave them this:
Code: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
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.
I did try that with adding a ShowRibbon in the OnOpen, but when that didn't work I just moved on.