DoCmd.OutputTo sur le rapport ne décharge pas

Question

Dans Access 2007, j'ai un formulaire mis en place pour permettre la prévisualisation et l'exportation des options pour les rapports du projet. DoCmd.OutputTo semble se comporter étrangement lorsqu'il s'agit de rapports dont la propriété Modal est définie sur true.

Modal est actuellement défini sur True dans l'événement Open pour tous les rapports avec lesquels je travaille.

Si je

DoCmd.OpenReport szReportName, acViewPreview 
DoCmd.Close acReport, szReportName

Ensuite, la concentration et le contrôle est retourné à la forme d'exécuter normalement.

Si exporter directement au lieu et utiliser

DoCmd.OutputTo acOutputReport, szReportName

Ensuite, le rapport est exporté correctement, mais le contrôle ne retourne jamais à la forme d'exécution. C'est complètement désactivé. Le même code fonctionne très bien, si j'utilise Modal = False lors de l'ouverture du rapport à la place. J'ai expérimenté un peu avec les hooks d'événement du rapport pour essayer de comprendre quelle est la différence et OnUnload n'est jamais touché après l'appel de OutputTo.

Je sais que je pourrais travailler autour de ce que de faire le modal rapport quand je besoin d'être modal, mais il est certainement plus facile de le faire à l'intérieur du code du rapport au lieu du module d'ouverture et je vraiment Je ne pense pas que je devrais avoir ce problème. Je n'ai aucun problème d'exporter le rapport du mode de prévisualisation au lieu de directement à partir de VBA, mais apparemment le client ... ne

des questions Alors, réelles:

1. Y at-il une bonne raison de ne pas déclencher CopierVers l'événement Unload? Si c'est un comportement normal, alors bon, mais j'aimerais au moins en comprendre la raison.
2. Existe-t-il un moyen d'exporter un rapport modal et de reprendre le contrôle des autres fenêtres? Ou au moins, une façon non-hacky de réactiver et de se concentrer sur le formulaire d'appel?

Answer 1

Votre premier code:

DoCmd.OpenReport szReportName, acViewPreview 
    DoCmd.Close acReport, szReportName 

... va à l'erreur si le rapport est modal. La raison pour laquelle la deuxième ligne ne peut pas être exécutée jusqu'à ce que le rapport ouvert sur la première ligne soit fermée. Donc, dès que vous arrivez à la deuxième ligne, vous obtenez une erreur, car le rapport n'est plus ouvert à ce moment-là.

Ce que vous devez faire est de définir pas la modalité dans la feuille de propriétés du rapport, mais dans la commande DoCmd.OpenReport:

DoCmd.OpenReport szReportName, acViewPreview, , , acDialog 

Le commutateur acDialog ouvre de façon modale, et le code se met en pause jusqu'à ce que le rapport fermé, puis continuez. Mais quand vous utilisez DoCmd.OutputTo, il se comportera normalement, car le rapport n'est pas modal.

En général, dans les formulaires et les rapports Access, vous n'avez pas besoin de définir la propriété Modal, car vous pouvez toujours l'ouvrir de manière modale lors de l'exécution.

Je ne sais pas pourquoi vous pensez que vous devez définir la propriété modale dans l'événement OnOpen du rapport. Il n'y a pas de code nécessaire ici, et je ne pense pas que ce soit un bon endroit pour le changer (et je m'attendais à ce qu'il ne fonctionne pas en premier, car vous ne pouvez pas vraiment changer le mode fenêtre après que la fenêtre est déjà créée , peut-être que le OnOpen s'exécute avant que la fenêtre visible ne soit créée?). Mais vous faites des choses en arrière du point de vue des pratiques d'accès standard. Je ne sais pas pourquoi vous refusez de définir le mode fenêtre dans le code appelant, car cela signifie que vous pouvez utiliser le rapport dans n'importe quel contexte sans avoir à avoir du code qui s'inquiète du problème dans le rapport lui-même. Je pense toujours que les rapports et les formulaires devraient être aussi stupides que possible, ne se sachant que d'eux-mêmes, et laisser les contextes d'appel avoir toute l'intelligence en eux (mais avec aussi peu de choses dans le contenu interne du formulaire).