views:

22

answers:

1

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:

  1. 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.
  2. 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?
A: 

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).

David-W-Fenton
I agree that setting the Modal (or any) property in the report code is less than desirable. To be honest, I didn't put it there I'm just trying to maintain previous behavior. I believe Modal was used in place of acDialog, because we didn't want the report to be in PopUp mode. Regardless, I resisted acDialog because it's behaving differently than the Modal property - it still allows me to switch the focus to the calling form. I had forgotten that it really should be the same, so it seems I should be looking for something else wrong with the report that is causing acDialog to not behave modally.
Jelly
Popup and Modal are two completely different propoerties, and opening a form or report with acDialog does NOT result in the form/report being in Popup mode. Basically, so far as I can tell, acDialog causes the Modal and Popup properties to be ignored.
David-W-Fenton
I just tested a report opened from a command button with acDialog, and it didn't matter what the Modal/Popup properties were set to, I could not set focus back to the calling form until the report preview was closed.
David-W-Fenton
Note that opening a form or report with acHidden (whether or not with acDialog) cause the modality to be ignored. This can be useful in some situations, as modality is restored when you make it visible again. But that doesn't help if you've gone to the next line of code in your calling context, so you have to use it appropriately. I have mostly used the interaction betwee acDialog and acHidden when I need to call a form with acDialog from a form that was itself opened with acDialog. It won't work unless you set the first form's Visible to False.
David-W-Fenton