Ilogic PDF Export
Hi @NRHartness. That is a complicated one to explain how to fix. There are multiple ways to export a drawing with multiple sheets out to a PDF with multiple sheets. I am not sure which way would be best for you, bot both ways would require a lot of changes to your code.
Maybe the option which might require the least changes would be to 'print' (not save) the drawing directly to a PDF file. To do that will require several changes.
- The first major change would be on Line 11.
- Instead of "As PrintSettings", that should be "As DrawingPrintManager" (without the quotes).
- Then set its DrawingPrintManager.Printer property value to the name of a local, software based PDF printer.
- Sometimes you will see one of these in your list of printers when you look into printing from other applications. If so, get its name, and use there here.
- Then set its DrawingPrintManager.PrintRange property to PrintRangeEnum.kPrintAllSheets
- Then, use one of these two methods of that object:
The other major way to export the drawing to a PDF with multiple sheets is to use the TranslatorAddIn route, which is more complicated than a simple SaveAs. (That link leads to a VBA example code, not an iLogic one, so some conversion may be needed.)
Wesley Crihfield
(Not an Autodesk Employee)
Hi @NRHartness. I think it may be easier to just post a whole different iLogic rule example for you to start from, then you can modify this example as needed. This code example uses the TranslatorAddIn route, because even though it may look more involved, it gives you more control, and may be easier to maintain later. This is all in one iLogic rule, but is broken up into 3 separate code routines, to isolate the main tasks of the overall job. The 'Main' routine just makes sure we are working with a drawing, then calls a routine to collect the full path & file name for the PDF, then calls a routine to export the PDF. The 'ExportIDWToPDF' Sub routine is the one doing the SaveAs task, but in a more detailed way, allowing for options/settings. Then the 'UseFileDialog' Function routine is just for showing an Inventor based FileDialog, and allowing the user to specify the location and file name for the PDF file, then returns that String value. Those individual routines can be moved around or copied between other rules, if needed, until you learn how to 'share' entire blocks of code or run rules from other rules later, for more efficiency.
You will find the code in the attached text file. Let me know how it works for you. I will be out for the weekend after this though, so have a great weekend.
Wesley Crihfield
(Not an Autodesk Employee)
Hi @NRHartness. Here is another version of the last code I posted. I edited the previous code to make the requested modifications. It will now ask if you want to save a PDF, right after the document type check, but before it does anything else. Next, it will check to make sure the drawing has been saved. If the drawing has not been saved yet, it will not have any file path or file name yet, so it will not have anything to work with, after eliminating the file browser routine. If the drawing has not been saved yet, it will show a message to the user, letting them know about it, then it will exit the rule. If it passes that test, it will then use the same file path, and file name as the drawing file, but with the ".pdf" file extension for the new PDF file. Then, the same as before, if that PDF file already exists, it will let you know about that also, and let you decide what to do there. If there was no existing PDF, then there is no interruption, and it will attempt to export the drawing to a PDF file. As it does that, if it was successful, it will let you know, and show you the full path and file name of the new PDF file. If an error happened, it will also let you know in a message that includes that full path and file name of the PDF file it was trying to create, so you can look into it.
Wesley Crihfield
(Not an Autodesk Employee)
Hi @NRHartness. It sounds like a timing related issue. Based on what you said in your initial post, you must have this iLogic rule pasted within the Event Triggers dialog, on the 'This Document' tab, under the 'After Save Document' event, and only under that one event, not under any of the other events. Is that true? If not, then please explain that situation in more detail. If it is only under that one event, then it should only be triggering this rule to run after the document has already been saved. If so, then that check within the code should not be sensing that the file has not been saved, or that it has no FullFileName. However, I suspect that since you mentioned 'SaveAs' a few times, there are two different documents involved in this process, and maybe the 'ThisDoc.Documet' phrase at the start of the code may be capturing the one that is still not saved yet. The SaveAs process is handled differently than a regular Save process, and it can be tricky to deal with by code. I know that when we have created a new drawing, the first time we click the regular Save button, it will do a SaveAs, instead of a regular Save, and when that is the case, the document will not have a file path or file name yet until after it gets saved that first time.
Wesley Crihfield
(Not an Autodesk Employee)
I do not know what to say then. I just used the 'New' button to create a new drawing from one of my templates, then created a new internal iLogic rule within it, then pasted the code in it that I posted above, then saved that iLogic rule, without running it. Then I opened the Event Triggers dialog, and put that rule under the 'After Document Save' event on the 'This Document' tab, and clicked OK on that dialog. Then I clicked the regular Save button. The SaveAs dialog showed, as expected, I gave it a file name, and saved it locally. Then the first dialog showed asking me if I wanted to save a PDF, and I said Yes. It then informed me that the PDF had been created, as expected. So, I did not have the problem you are describing, which leads me to believe that there is nothing wrong with the code itself. But maybe I am wrong. I do not understand why it is acting that way for you, and not for me. I do know that when you click the regular save button, it will check to see if the document actually needs to be saved, and it will not actually save it, if it does not believe it needs to be saved. It will only save when you click the regular save button, if the file has not been saved yet, or if certain types of changes have been made to the document that would 'dirty' the document in a way that would require being saved to file. So, you would only see the rule work on a file that has already been saved, if it actually saved again.
Wesley Crihfield
(Not an Autodesk Employee)
Hi @j_span755F8. You will need to be a lot more specific with your requests before anyone can properly answer them.
As for the 'specific folder' request:
There are many different possible ways to set the 'path' to a specific folder. The question remains...how do you 'want' to do it? Is this specific folder you want to specify in a whole other directory, in a different storage area than the model file, or is it simply a sub folder to where the model file is? If it is simply a sub folder, then what is its name? Does this folder possibly need to be created first? The simplest way to specify it would be to use an extra variable, and just type it in as the value of that variable.
As for the different file name:
Again, very vague suggestions, with no specifics. Do you literally want the PDF's file name to start with the text "iLogic Drawing"? What about the drawing's current file name...is that not going to be included? Which iProperty are you talking about there? Which 'data' should be in the file's name...today's date, or the creation date of the drawing, or some other date? What format does the date need to be in? Remember, some of the special characters that may be found in a 'date' may not be valid to use in a file name in your file system.
Also, which code are you currently work with...the one attached to Message 4 above, or the one attached to Message 6 above, or another edited version?
Edit: Below is just one possible variation (out of a great many) to a section of the code (Line 20 - 23) in Message 6 above. This variation is replacing the following block of code:
'specify the full path and file name for the PDF file that is to be created.
'this is using the same path and file name of the IDW, but with ".pdf" file extension
Dim sPDF As String = System.IO.Path.ChangeExtension(oDDoc.FullFileName, ".pdf")
If sPDF = "" Then Return 'or notify user that they did not choose anything, then exit rule...with this modified block of code:
'specify the full path and file name for the PDF file that is to be created.
Dim sPath As String = System.IO.Path.GetDirectoryName(oDDoc.FullDocumentName) & "\PDF"
If Not System.IO.Directory.Exists(sPath) Then System.IO.Directory.CreateDirectory(sPath)
Dim sPropVal As String = oDDoc.PropertySets.Item(3).Item(2).Value 'Part Number of drawing
Dim sDate As String = Today.ToShortDateString
Dim sFileName As String = "iLogic Drawing " & sPropVal & " " & sDate & ".pdf"
Dim sPDF As String = System.IO.Path.Combine(sPath, sFileName)
If sPDF = "" Then Return 'or notify user that they did not choose anything, then exit ruleYou will notice that it now contains more variables. One for 'path', one for file name, one for the iProperty value, one for the 'date', and one for the final full path and file name combined. It first gets the current path of the drawing, then specifies a sub folder named "PDF". Then it makes sure that folder exists. Then it gets the value of this drawing's Part Number iProperty. It does not check if its value was 'empty' though. Then it gets today's date and uses one of man possible ways to convert the Date data type into String data type. Then it concatenates 4 pieces of data into one file name. Then it combines the path and file name. As I said before though, each line can be changed in too many different ways to mention here, and due to lack of specific information, I have no idea if I am specifying the correct folder, or the correct iProperty, or the correct date, or the correct date format, so this 'effort' may have been a waist of time. Code needs to be extremely specific for it to work properly, so those who write code to accomplish specific tasks need to know every possible tiny little detail about the task, in order to make it work.
Wesley Crihfield
(Not an Autodesk Employee)
