Hi @utmeccanicoADTLH.
Your last two replies did not really help us to be able to help you any. We need to be able to understand why it was not working for you, when it does work for others. We also do not know how much you know about reading or writing iLogic rules or VBA macros for automating Inventor. Because of this, I was trying to explain to you how the code is supposed to work, and its limitations, and ask you questions about how to find your drawing files, so that they can be printed.
There are no drawings in an assembly, only parts and sub assemblies. Those parts and sub assemblies do not contain any data or information about any drawings. So, from the part's point of view, we can not know if a drawing file even exists for that part, so there is also no way for us to know where to look for that drawing file, or what the name of that drawing file will be. One common practice among some Inventor users is to save their drawing file in exactly the same folder as the part or sub assembly model file, and with the same exact file name, with only the file extension being different. That is what that code example above was counting on. If your files are not saved that way, then that code will not work for you the way it is. And in order for us to be able to edit that code to work for you, we need to know how to find the drawing file from the model file? But only you can tell us that information. If your drawing is always saved in a different folder than your model files, then tell us how to find that folder. If you always name your drawing file differently than the model file, then tell us how you rename your drawing files differently than your model files.
You said that you tried to use the code example above, but nothing happens. Then you said that you tried to modify it, but only got an error saying that the "Set" command is no longer in use. Well, the 'Set' keyword is only used in VBA macros, not in iLogic rules, and that code is for use in an iLogic rule, so the 'Set' keyword will not work in it, and was not used in the original code in the text file attachment. I see it being used in the example code that you posted, down a couple lines into the "PrintDrawing" Sub routine. The DrawingDocument object is being 'passed' to that Sub routine as an input argument from the lines of code that call it to run within the Sub Main area of the code, and then that Sub routine is supposed to be using that DrawingDocument that is sent to it to print it...not find the DrawingDocument again, from the 'active' document.
In order for us to figure out why it is not working for you, and maybe be able to modify the code to make it work for you, you will need to answer some questions.
- Do you save your drawing files (IDW or DWG) in the same exact folder (not a sub folder) as the model file that they are detailing?
- If not, then please explain in as much detail as possible, where you are saving your drawing files, in relation to the model file its views are referencing?
- Do you name your drawing files (IDW or DWG) exactly the same as the model files that they are detailing, just with different file extension?
- If not, then please explain in as much detail as possible, how the model file and the drawing file are named differently?
- Do you just want to print these drawings to your system's default printer, or do you need to print them to a specifically named printer?
- Are you trying to print those drawings directly to PDF files, or just normal printing to paper?
- Do you need to be able to specify any specific printing settings or instructions?
- If so, tell us all about the settings you want to set, and how they should be set.
We can only help you, if you help us, by providing as much feedback information as possible. More information is better than less.
Also, if you see error messages when running codes, then try to capture what is shown on the 'More Info' tab of that error dialog, so you can copy it and paste it here in the forum, so we can better understand the errors. Sometimes those error dialogs even contain clues to the exact line of code where the issue is being caused. That is very valuable information when trying to figure out why an error is happening, and can sometimes help us fix it.
Wesley Crihfield

(Not an Autodesk Employee)