Author
Topic: Need second set of eyes (Read 1744 times)

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.

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...

Logged

"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight." - Dr. Tom Cade

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.

Logged

"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight." - Dr. Tom Cade

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

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

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.

Logged

"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight." - Dr. Tom Cade

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.

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

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.

Logged

"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight." - Dr. Tom Cade