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).
Related
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?
I can't get Access to save a form I have edited using VBA to hide (or unhide) a column. The basic code is below. I open the form (in Datasheet mode because I am changing the ColumnHidden property), make the change, and close and save, but it doesn't save the change. Experimenting, I changed acSaveYes to acSavePrompt, and it doesn't even prompt me to save. Does this have anything to do with being in datasheet mode? Never had this problem making similar edits in design mode. If so, how do I make and save such a change. Thanks for any ideas!
DoCmd.OpenForm "Form1", acFormDS
Forms![Form1].MyColumn.ColumnHidden = True
DoCmd.Close acForm, "Form1", acSaveYes
Changes you make using VBA are seen as temporary by Access, and not saved, even if you explicitly save your object. This behavior is intended (and very useful, as it allows you to hide things on the fly based on whatever you want without you having to worry about reverting changes after the user is done with the form). An exception to this is when the user first lets VBA make changes, then switches to layout view and makes additional changes, and then saves the object. In that case the changes made by VBA are saved.
As far as I know, you cannot change this. Obviously, you can make the change manually and then save it, or check if the column should be visible or not once you open the form based on something you set somewhere.
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
I'm trying to write some code for my database to enable a dropdown box in a parameter prompt for a query, but it's doing nothing instead of it's intended purpose. This:
Dropdown in Access 2007 parameter query
has been the source of my inspiration. Though I seem to be unable to implement even the most basic VBA code:
Private Sub cmdReset_Click()
Me.cboSelectName = Null
End Sub
(Yes this is not all my code! Just one of the subs)
On the relevant form, I have a button called "cmdReset", which has "[Event Procedure]" for the event "On-Click". I also have a dropdown box called "cboSelectName" on said form. Also I have tried closing the database, and making sure to enable macros when it starts.
So essentially this code should make the value in the dropdown box null when I click the reset button. However it does nothing, it simply deselects the dropdown box. Can anyone help me with this one? I'm keen to start implementing some VBA in my database!
As suggested by Remou, the code wasn't even running. I figured out my problem - I had saved the code in a new module, rather than in the VBA code for my form. Once I shifted the code into the form object, the reset button worked. I've also now got some nifty code working with the actual "generate report" command. VBA really has the power to take your database to a whole new level!