Need second set of eyes

[stanl]

I am working on a script where I have to use runas to query data from a server in another domain, use copyfromrecordset() to populate an excel tab, update links, then open powerpoint and update links to excel and the final step - save the PPT as PDF. I think I did my homework with the parameters and the offending line of code is below and the error message attached.

Code: Winbatch

oPPT.ActivePresentation.ExportAsFixedFormat(cPPT, 2, 1, -1, 1, 1, 0, , , , @False, @False, @False, @False, @False,)
 

[td]

MSFT went over the top with all the ExportAsFixedFormat method variations in various Office programming models. 

But to get to the problem at hand, you have an extra comma at the end of the parameter list in the line in the code frame but I suspect that is not the cause of your problem.   The error doesn't point to an extra parameter and the error source line in your error message doesn't have the extra comma.  So next best thing is a little speculation.

WinBatch uses MSFT's COM Automation prescribed way to pass "optional" (in VBA speak) parameters to a method.  It could be the case that MSFT has an undocumented alternative way to do this that is supported by VBA and the Powerpoint programming model but unknown to the unwashed masses.  If this is the case, you may need to provide values for each of the "optional" parameters to get the method to work.  Or it could be something else entirely...

[td]

Another possibility that doesn't exactly fit the facts is that your version of PowerPoint has a different version of the ExportAsFixedFormat method than the one you're basing the call on. This is just speculation without any confirming facts other than there does seem to be different versions of the method in different Office product versions.

[stanl]

Of course there is no way in Powerpoint to record a macro, and because of the constant changes in the pdf output from the master pptx I don't want it macro enabled. There is an additional parameter which is a pointer and that is why the final , was tried.  I tried filling in all parameters and tried

Code: Winbatch

oPPT.ActivePresentation.ExportAsFixedFormat("%cPPT2%" :: FixedFormatType=2, FixedFormatIntentPrint=2)

 

which was standard in stuff I googled but the error there was 'unknown name'.  Wish I could test this from studio but have to compile the test each time. In the original post parameter 8 (all are optional after the output type) is printall which I set as 1. 

P.S. - to save anyone the trouble  ppxedFormatType and ppxedFormatIntentPrint are also 'unknown' names

EDIT: from TD's last post - version is 2013

[stanl]

.... and now back to the KISS principle:

Code: Winbatch

oPPT.ActivePresentation.Save()
oPPT.ActivePresentation.SaveAS("%cPPT2%",32,0) ; or oPPT.ActivePresentation.SaveAS(cPPT2,32,0)
oPPT.ActivePresentation.Close()
oPPT.Quit()
oPPT = 0
 

works.  I was led astray by threads that .saveas() for pdf was no longer supported. 

[td]

Code: Winbatch

oPPT.ActivePresentation.ExportAsFixedFormat("%cPPT2%" :: FixedFormatType=2, FixedFormatIntentPrint=2)

 

Unless you happen to have a comma include in your act of substitution that line would understandably cause an error. Also looking at the method for PP 13 in the WIL Type Viewer, I don't see a parameter with the name "FixedFormatIntentPrint" so that would explain the "Unknown Name" error.  There is a parameter named "Intent" which likely what you intended to use.

[stanl]

Unless you happen to have a comma include in your act of substitution that line would understandably cause an error.

Having found a solution, I am still curious about this line in your response.  In fact I did muddle through a variety of named parameters, most based on posts with user vba code. But assuming the named parameters were correct, where does the comma come in. I say this because my next step may be a search/replace inside the PPT before saving as PDF.

[td]

To follow the grammar of the WIL language you need a comma between the act of substitution ("%cPPT2%") and the named parameter operator ( :: ).   

Just to make sure it is clear to other readers, your parameter names are not correct for PP13.   The ExportAsFixedFormat method does not have a parameter named FixedFormatIntentPrint.   FixedFormatIntentPrint is almost the name of a value in the PpFixedFomratIntent enumeration.  The actual name in PP13's type library is ppFixedFormatIntentPrint which equals the value 2.   However,  you cannot substitute enumeration names for parameter names.  COM Automation does not work that way.   

Now in VBA you can use enumeration member names in place of parameter values (but not parameter names) but in WIL you cannot use enumeration member names in parameter values for reasons I will not go into here.   However, you can use the WIL Type View to find the actual value for the enumeration member and use that instead.  In other words, use the integer value 2 for the name  FixedFormatIntentPrint.  So you end up with something like

Code: Winbatch

FixedFormatIntentPrint = 2

oPPT.ActivePresentation.ExportAsFixedFormat("%cPPT2%", :: FixedFormatType=2, Intent=FixedFormatIntentPrint)

or simply

Code: Winbatch

oPPT.ActivePresentation.ExportAsFixedFormat("%cPPT2%", :: FixedFormatType=2, Intent=2)

Note that I am not saying that the above will actually work as there may be other considerations.  All I am saying is that they are grammatically and semantically correct in the WIL language.

[stanl]

From the WIL Help file. Although there is a comma, there are two positional and no comma between the 2nd and ::  - where one can get confused.

Code: Winbatch

; 2 positional parameters and 2 named parameters
objapp.InputBox("My Prompt", "My Title" :: Left = 40, Top = 300)

 

EDIT:  I'm not trying to beat a dead horse here. This was a project I rather rushed into and this is a great forum to play out one's mistakes and syntax errors

[td]

It is unfortunate that the COM help file examples from about 17 years ago do not use a comma because the Syntax Analyzer will flag it as an error.    The Syntax Analyzer is correct but the WIL interpreter has a bug that lets it slip through more times than not.  The bug was never corrected because of backward compatibility concerns.   

It is a bit embarrassing that I had forgotten about that issue since I had a hand in perpetuating the bug in the first place.       

[td]

Should add that using a comma between position parameters and the named-parameter-indicated ( :: ) is strongly encouraged as leaving the comma out is not guaranteed to work in future versions...