Print/Save to PDF based on Form Object instead of Form Name

mjvoce

New member
Local time
Today, 09:45
Joined
Feb 21, 2016
Messages
7
Is there an equivalent to DoCmd.OutputTo or DoCmd.PrintOut where i pass the form object instead of passing the form name?

I have a form where multiple instances may be opened and so I cannot use the form name as a reference. But the only methods I'm aware of to print a form or save as a pdf require the form name. DoCmd.PrintOut may work but it seems like you need to use DoCmd.SelectObject prior to using it and .SelectObject requires an object name. I attempted to just setfocus to the current instance of the form and then use DoCmd.PrintOut but it didn't work.

I'm open to any solutions regardless of complexity. It would be preferable if the form printed/saved without discounting the form specific print properties as well. For example, I have subforms that are condensed in form view but expand when printed to show all line items.
 
Last edited:
printOut doesnt WANT form object. The argument is name.

you could make a routine to pass the object and let IT use the name:
Code:
sub PrintMyObj(pobj as object)
vFilename = "c:\folder\" & typename(pobj) & ".pdf"
docmd.OutputTo acOutputForm ,pobj.name,acFormatPDF,vFilename
sub end sub
 
It still creates the same problem. Every instance of the form will have the same name and so it will only print/save the first instance of the form in the forms collection, which will most likely be the first instance opened.

So, if I'm trying to print the last instance I just opened it will print the wrong one.

I did find a solution to printing using DoCmd.RunCommand acCmdPrint as it prints whatever object has focus.

The problems are it launches a dialog box and the user still has to confirm the print, which may not be a problem at all. I have a feeling I could use this to save a pdf as well, I'm just not sure yet, at least not without making the user select the pdf option from the printer dialog.
 
If I was designing a system to print data from Access I would always use a report, not a form. Then, rather than deal with forms at all in the printing process, I would pass the ID fields that identify the data I want to print to the report, and let the report take it from there. Then any consumer, including multiple instances of the same form, could leverage that report.
hth
 
If I was designing a system to print data from Access I would always use a report, not a form. Then, rather than deal with forms at all in the printing process, I would pass the ID fields that identify the data I want to print to the report, and let the report take it from there. Then any consumer, including multiple instances of the same form, could leverage that report.
hth

That is a really great idea and incredibly simple. Thank you very much. Here I was trying to rewrite the DoCmd.OutputTo source code when I could basically just use a dummy report/form for all the printing and exporting. It will also simplify managing how it looks in form view vs print view.
 

Users who are viewing this thread

Back
Top Bottom