Same VI, two different outcomes on two different computers

[CatDoe]

Thank you! That answers my question. Thank you for the VI! It looks like I am on the correct track with the VI's I am now using!

[DavidBoyd]

CatDoe,

To possibly provide insight to your original problem (and certainly to confirm @RTSLVU 's bias about using the Report Generation Toolkit to hit the ever-moving target that is Microsoft Word/Excel automation):

The SaveAs method of the _Workbook class mutates between the Office365 and non-O365 releases of Excel.  The O365 version of the ActiveX Invoke node gains an extra parameter, "WorkIdentity".  (Info on its usage is virtually nonexistent on MS developer sites I've browsed.)

For myself, I created a substitute version of Excel_Save_Workbook.vi, which wraps both versions of the invoke node in frames of a type specialization structure.  One of those frames will always be broken due to bad linkage, and the other will be selected.  Unfortunately, this doesn't solve your runtime problem - it just means that at development time, the version which matches Excel on the development machine will be selected and the VI won't load broken.  Any executable you build at that point is compatible with the same flavor of Excel, but not the other.

Any fix to support both runtime target environments is likely some gooey mess of attempting to call-by-reference both flavors and taking the first that doesn't throw an error.  If that even can be done, of which I'm not so certain.

Dave

[CatDoe]

Thank you for that insight!

I switched over to a text file format and will let my colleagues write scripts to match their particular distribution needs. That is the best compromise we could come up with to prevent compatibility headaches.