I am trying to print preview my report (using a button on my form, see code below). When I go to do it initially, it pops up as a super small image, and I cannot right click it (so I cannot print or export it).
However, after simply entering Design View (but not changing anything), then opening the form to print the report again, it works as intended (i.e. pops up at a normal size and I can now right click the report).
Private Sub Report_Click()
DoCmd.OpenReport "Query1", acViewPreview, , Me.Query1SF.Form.Filter
End Sub
Any idea why this may be happening? What could be happening that simply going into Design View, then back to Form View, is changing how the report opens?
Related
I just found something strange with MS-Access 2016. I have a database with 2 forms: one hidden, one for a menu. The autoexec will open the hidden form and that one will open the menu form.
I unchecked some options, under Current Database e.g. [Display Navigation Pane] and [Allow Full Menus].
I have an exit button/command on the menu form. On Click, it calls DoCmd.Quit. But before exiting, I am getting an MS-Access window asking for the parameter that is normally when the form open, not when it is closing.
After doing a lot of testing and I mean a lot, I realised that the problem is related to the fact that I am disabling the [Display Navigation Pane]. If I keep the navigation pane, but instead I unchecked all Object Type, then everything works correctly.
So, my question is why disabling the navigation pane can create something like that and is there a way to fix it?
Yes, my solution works, but I don’t like it since users can open and close the navigation pane using the shutter bar; nothing shows but it is still distracting and users can call for support.
The problem is not related to the fact that the first form is hidden, but because it is open. If I add a DoCmd.Close acForm, “F_Parameter” before my DoCmd.Quit then it works.
It is easy to reproduce the problem:
Create a new database
Create two forms:
F_Parameter
F_Menu
Create a Macro named Autoexec:
OpenForm
Form Name: F_Parameter
Window Mode: Hidden
In form F_Parameter create an event On Load
Private Sub Form_Load()
DoCmd.OpenForm “F_Menu”
End Sub
In form F_Menu create a Button named Btn_Exit with an event On Click
Private Sub Btn_Exit_Click()
DoCmd.Quit
End Sub
In form F_Menu create an event On Load
Private Sub Form_Load()
MsgBox “Hello”
End Sub
go File, Options, Current Database and
uncheck Display Navigation Pane and
uncheck Allow Full Menus
Save, exit and open the database:
You will get a “Hello” because the F_Menu form open, now click on the exit and you will get another “Hello”. This second one should not be there because the form should be closing not opening.
I was able to reproduce the issue described. I don't think it has anything to do with the Navigation Pane.
This is happening because while the DoCmd.Quit event is occurring, the hidden F_Parameter form is becoming "unhidden" in order for Access to close it. This causes the F_Parameter Form.Load event to run, which is essentially opening F_Menu, thus causing the Form.Load event on F_Menu to run.
I was able to solve this by first explicitly closing F_Parameter, then quitting:
DoCmd.Close ObjectType:=acForm, ObjectName:="F_Parameter", Save:=acSaveNo
DoCmd.Quit
I have a report Open in Print Preview mode. I have accomplished this using a button with the code:
DoCmd.OpenReport "rptNameHere", acViewPreview, "", "", acNormal
When I print using Ctrl+P, the report prints as expected. When I go to File>Print however, it sends the contents of a table to the printer. The table it prints is currently selected in the Navigation Pane, and the program is for some reason ignoring the currently open window. This happens for each different report that I open in this same manner.
Is there anyway to fix this behavior? This database will be distributed in .accde format with the Navigation Pane hidden. That particular table will always be selected by default because it is the top object in the pane.
I'm guessing the answer is one of three options: 1) When I Open a report using my On-Click event, some sort of code to also select it in the Navigation Pane; 2) An option or code somewhere that will force the program to print the open window and not the selected table; 3) A way to remove the Print entry from the File menu so the only option is for users to print with Ctrl+P.
Edit: Using Access 2016, which may make a difference. I've also confirmed this happends regardless of what is currently selected in the Navigation Pane, that item is what is sent to the printer.
Edit 2: I think this has to do with my Forms/Reports that have the "Pop Up" set to Yes. For any of those, the problem occurs. Whenever "Pop Up" is set to No, it does not.
I have a split form as my main interface in an Access 2010 application. As normal, users are able to resize the datasheet portion, reorder columns, etc.
However, I don't want them to save such changes when leaving the form. Each time the form is opened the default format should be loaded.
I've taken care of all but one closing method. To avoid them closing using the default close button I've set Border Style = None. Instead I have a Close Form button that uses DoCmd.CLOSE acForm, "Main_form", acSaveNo
But if the user clicks the close button for the Access application, it pops the 'Do you want to save changes to the design of form` dialog like always.
I looked into disabling the application's Close button, but messing with Windows API is beyond my skill (and there should be a way to accomplish this without going to extreme measures).
I found a way to do this. A combination of database options, form format options, and vba can do it.
Go to the 'Current Database' options screen in the main Access
options and uncheck 'Enable design changes in Datasheet view'. This will prevent all datasheet view design changes in the database, so you will have to go into design mode for any table changes. Users can still reorder and resize columns within a form, but Access no longer considers that a valid design change and will not prompt to save it no matter how you close the form
Set the form format property 'Save Splitter Bar Position' = No. The form will now clear any change to the bar location when the form is closed. Access got really weird on me about this setting, however. Once I had ever set the option to no, I could no longer use design view or layout view to set a new default bar position; it always reverted to the location where it was when I first tried this setting. Even resetting the option to Yes, saving the design change, and fully exiting the database did not fix this.
So I added an On Load event to reset the split form size when the form opens: Me.SplitFormSize = 9000. The numbers involved are surprisingly high; in the form properties list this is set in inches. Mine was 6.5", which apparently translates to 9000.
With these three changes (along with the steps I detailed in the question) Access no longer prompts to save design changes when the form is closed, even if the user is closing the Access application entirely. The form also snaps the split form bar back to where it should be on load.
Since the API is beyond my skill too, here is a left-field workaround.
Duplicate Main_Form and rename it "Main_Form_Template". Create an Autoexec module or edit an existing one and add:
DoCmd.DeleteObject acForm, "Main_Form"
DoCmd.CopyObject , "Main_Form", acForm, "Main_Form_Template"
That should reinstate the standard template for the user each time they open the database even if they were to save the form when closing Access.
Turn your close button off on the form.
On the form's property sheet, format tab, about 2/3 of way down. Set Close Button = No
This forces the user to close it via the button you created.
I'm creating forms with VBA/Access to access my database.
In a form, I have a *lst_sinistres* listbox that displays the results of my SQL query and when I doubleclick on one of the results it opens me another form with thanks to this code
Private Sub lst_sinistres_DblClick(Cancel As Integer)
DoCmd.OpenForm "F_SINISTRE_MRH", acNormal, , , , , Me.lst_sinistres.Value
End Sub
I wanted to change my form, and add tabs to make it more ergonomic. So I placed my *lst_sinistres* listbox inside a tab.
The problem is that when I doubleclick on one of the results in this listbox (now placed in the tab), the form *F_SINISTRE_MRH* does not open.
Does someone have an idea of where the problem might come?
Thank you
A quirk of VBA control events is that event code can become detached from the control object. Things that cause this tend to be re-naming controls and copy/pasting similar code between controls. To move your listbox onto a tab control you needed to cut and paste it temporarily. That broke the link between the written code and the object name. When the code and object are properly linked, [Event Procedure] shows up in the property sheet (as suggested by #4dmonster).
If you are in the VBA editor, choosing Debug->Compile will search through all the code and re-link event code with like-named controls. This step is worth a try before re-writing because you may end up with orphan blocks of
Private Sub OldControlName_DblClick(Cancel As Integer)
MsgBox "Why don't I work anymore?"
End Sub
that are treated as Form-level subroutines that just happen to never be called.
pT
In Access 2007, I have a form set up to allow previewing and exporting options for the project's reports.
DoCmd.OutputTo seems to behave strangely when dealing with reports that have the Modal property set to true. Modal is currently set to True in the Open event for all of the reports that I'm working with.
If I do
DoCmd.OpenReport szReportName, acViewPreview
DoCmd.Close acReport, szReportName
Then, focus and control is returned to the executing form normally.
If I export directly instead and use
DoCmd.OutputTo acOutputReport, szReportName
Then, the report is exported correctly, but control never returns to the executing form. It's completely disabled. The same code works just fine, if I use Modal = False when opening the report instead. I experimented a little with the report's event hooks to try and figure out what the difference is and OnUnload is never hit after OutputTo is called.
I know I could work around this by only making the report modal when I need it to be modal, but it's definitely easiest to do from inside the report's code instead of the module opening it and I really don't think I should be having this problem. I also have no problem exporting the report from preview mode instead of directly from VBA, but apparently the customer does...
So, actual questions:
Is there any good reason for OutputTo to not trigger the Unload event? If this is normal behavior, then fine, but I would at least like to understand the reason for it.
Is there any way to export a modal report and still regain control of the other windows? Or at least, a non-hacky way to re-enable and give focus to the calling form?
Your first code:
DoCmd.OpenReport szReportName, acViewPreview
DoCmd.Close acReport, szReportName
...is going to error out if the report is modal. The reason why is the second line can't be executed until the report opened on the first line is closed. So, as soon as you get to the second line, you get an error, because the report isn't open any longer by that point.
What you need to do is not set the modality in the report's properties sheet, but in the DoCmd.OpenReport command:
DoCmd.OpenReport szReportName, acViewPreview, , , acDialog
The acDialog switch opens it modally, and code will pause until the report is closed, and then continue.
But when you use DoCmd.OutputTo, it will behave normally, because the report is not modal.
In general in Access forms and reports, you don't really need to set the Modal property at all, since you can always open it modally at runtime.
I don't know why you believe you need to set the modal property in the report's OnOpen event at all. There is no code needed there, and I don't think it's a good place to be changing that (and would have expected it to not work in the first place, as you can't really change window mode after the window is already created; maybe the OnOpen executes before the visible window is created?).
But you're doing things backwards from the standpoint of standard Access practices. I don't know why you resist setting the window mode in the calling code, as it means you can use the report in any context without having to have code that worries about the issue inside the report itself. I always think that reports and forms should be as dumb as possible, knowing only about themselves, and let the calling contexts have all the intelligence in them (though with as little poking into the internal contents of the called form/report as necessary).