Save changes in toolkit files?

[FJ_Sanchez]

Hello,

 

I have a project that I've modified in 2 different computers apparently with the same development environment (LV2013 SP1 + Database connectivity toolkit among others). When I moved the project from one computer to the other and closed the main VI (without any changes, just open and close) the "save files" dialog showed that some files from Database connectivity toolkit needed to be saved. I have a subvi calling "DB tools select data", if I remove this VI, labVIEW ask a last time to save or don't these files. If I dismiss any changes I can open and close the main VI and LV doesn't ask me to save anything.

 

After this, I place again the "DB tools select data" in the SubVI, and then LV ask again to save some files from this toolkit.

 

Can anyone tell me why is this happening? How can I avoid to modify any toolkit VI?

 

Thank you!

[dannyt]

I see this as a typical thing with LabVIEW Toolkits.  It is common that thought you download and install LabVIEW Toolkit 'whatever' for LabVIEW version 'whichever', it does not mean that ALL the VI's in the said Toolkit have been saved to that specific version of LabVIEW and when you first open or use some VI's from that Toolkit you then need to save those VI when they or the VI using them are closed. This is because the VI's open have been compiled to the new LabVIEW version.

 

Then when you move your code onto a new PC with the same toolkit you need to do it again as the VI from that toolkit on that PC also need to compile for the new version of LabVIEW.

 

You could by habit use the mass compile tool to all newly installed toolkits or each PC or just accept the fact and save the changes, once save this should not occur again.

 

If NI toolkits ever ship with 'separate compile code' enabled this problem would go away, or if NI mass compiled all their toolkits and then you would download a specific version of toolkit for each LabVIEW version.

 

To be honest I just live with it, it does not bother me that much

[Jordan Kuehn]

I've wondered similar things.  I encounter this quite often with the report generation toolkit.  I work from a desktop at the office and a laptop at customer locations.  All the source code is kept in sync, but in either direction it seems to want to save all of the report generation toolkit files.  It never causes a problem and I let it do what it wants, but I've wondered what is going on.  Identical versions are on both machines of both LV and the toolkit.

Edited April 29, 2014 by Jordan Kuehn

[dannyt]

What does it say the reason for wanting to save the changes are, that often gives useful info.

[Jordan Kuehn]

I may reproduce it later today, but I never gave it much more than a quick "why on earth does it need to save all of those?" before hitting save and letting it go.  You make a good point that I could probably answer my own question with a couple clicks.  It seems to always happen when I'm in a hurry and don't have time to investigate.

[hooovahh]

The one I hate is something like "An attribute of this VI has changed".  Well thanks I guess.

 

One thing I've seen is going from and x64 to x86 machines the path to "Program Files (x86) would some times cause VIs to need to be re-saved but this is with the source, not the toolkit.

[Jordan Kuehn]

Here's a couple results.

 

[Darren]

I can speak to the Report Gen Toolkit and Database Toolkit issues specifically. Both of these toolkits are mass compiled in the appropriate LabVIEW version before release (which makes me wonder about Jordan's second screenshot above referencing LV 8.6b7...this may be a bug). Bugs notwithstanding, both of these toolkits happen to make extensive use of ActiveX calls. If there are any differences in the ActiveX components on different machines, then the VIs will prompt you to save changes, even if you didn't actually make any edits to the VIs. This is illustrated by the message in Jordan's first screenshot ("external component modified"). One common cause would be a machine with a different version of Office installed than the one installed on our build machines here at NI, but there are many other causes of ActiveX version number differences as well.

[Jordan Kuehn]

The second screenshot only pertains to one of the conflicting VIs in the list.  Hopefully that helps you narrow down the difference.  The rest of the VIs match the first screenshot.  I'll see if I can get the ActiveX versions from both machines.  They are usually fairly up to date on updates, so I'd be a little surprised if they aren't the same.  This is also for just one project.  I've seen this saving behavior with multiple projects, but can't confirm the second screenshot issues.  I can generate more screenshots for various projects if you think this an actual bug in the toolkit.

[Darren]

Ok, now it's coming back to me (I haven't worked on the Report Gen Toolkit in several years). You mentioned that the version difference only appears with that one VI? I'm starting to remember that there's a weird ActiveX bug with the Print method for Excel that Microsoft never fixed, and we were able to workaround it by installing a non-mass-compiled version of the VI that calls that method (Excel_Print.vi). A recompile on an installed system (which will always happen when the VI is saved in an old version) works around the bug in the Print method.

[Jordan Kuehn]

A recompile on an installed system (which will always happen when the VI is saved in an old version) works around the bug in the Print method.

 

Does this suggest that if I take a project from one environment to another that I should expect to see that VI want to be recompiled?  Does that VI always need to be recompiled to 'work'?  Does this 'bug' (due to Microsoft) cause all the other VIs to need recompiling as well or is this more related to ActiveX mismatching in the big picture?

[Darren]

If you take the project from one environment to another, then you might expect to see many (or all) of the VIs that make ActiveX calls to want to be recompiled. The ActiveX component version mismatch issue is independent of the Excel_Print issue workaround. That's why any ActiveX-based toolkit (like the Database Toolkit) will demonstrate these issues.

[Jordan Kuehn]

Ok, I can understand that.  Explain the Print VI issue a bit more then. (Sorry to derail the thread if this doesn't pertain to the main topic)

[Darren]

Explain the Print VI issue a bit more then.

 

Ok, it's been several years now, but here's what I remember. There's some bug with the PrintOut method of the _Worksheet class, which is called by Excel_Print.vi in the Report Gen API:

 

 

Let's say I save a VI with this method on its diagram in LabVIEW 2012. Then I give you the VI. If you're also running LabVIEW 2012, the VI will not be recompiled because we're using the same LabVIEW version. But if the ActiveX components for this Excel library are a different version (mostly likely because we're running different Office versions), then the method will be broken on your system. If you were running LabVIEW 2013, though, the VI would be recompiled because of the LV version difference, and the method would not be broken.

 

Through our investigations, we found that this method was the *only* one in the entire Report Gen Toolkit API that exhibited this behavior...every single other property/method that we call in our VIs would detect the ActiveX component version difference just fine and force a recompile of the VI, even if the LabVIEW versions were the same. To my recollection, we found that there was a bug in the implementation of the PrintOut method itself that was causing us to not see the version difference on VI load. So, the best workaround we could come up with on our end was to force a recompile of the Excel_Print.vi on every installed system by installing a version saved in an older LabVIEW. We figured requiring a save of the VI was less of a burden on users that requiring an edit of the diagram (deselecting and reselecting the method).

[Mellroth]

So, the best workaround we could come up with on our end was to force a recompile of the Excel_Print.vi on every installed system by installing a version saved in an older LabVIEW. We figured requiring a save of the VI was less of a burden on users that requiring an edit of the diagram (deselecting and reselecting the method).

 

But, wouldn't this mean that the workaround only works if LabVIEW is installed after the ActiveX components?

If I make an update to the ActiveX component after LabVIEW has recompiled the VI, I would still have to fix this manually?

 

What if you add another ActiveX property/method to the BD that is actually not called, would this force the VI to detect the change in the external component correctly? 

 

/J

[Darren]

But, wouldn't this mean that the workaround only works if LabVIEW is installed after the ActiveX components?

Speaking to Report Gen specifically, if you install the toolkit without having Office installed, and try to open/save/mass compile the toolkit VIs, they would all be broken, since the ActiveX components wouldn't be on the system. So having the PrintOut method act funny would be the least of your worries.

 

If I make an update to the ActiveX component after LabVIEW has recompiled the VI, I would still have to fix this manually?

If you have saved the Excel_Print.vi, then upgrade your Office version, I suppose there is a chance that this VI would break again. I am not aware of anybody running into this issue, but it is theoretically possible.

 

What if you add another ActiveX property/method to the BD that is actually not called, would this force the VI to detect the change in the external component correctly? 

That is a workaround we didn't think to try, I suppose it might work. We would have to find a property/method that is guaranteed to be different (i.e. requiring a recompile) between the different supported Office versions.

[FJ_Sanchez]

Thank you to everyone, much clearer now

Edited April 30, 2014 by FJ_Sanchez

[peter_flores]

Not sure if this is kosher, sorry if it is not...

I wanted to share with you my new post that I believe may be related to this issue, can you take a look? It has some similarities, and I have noted the same exact behavior discussed here happening on the Save As function call for Excel 2016 in LabVIEW 2015 SP1, BUT I am seeing a much bigger, uglier behavior mucking up my LabVIEW/ActiveX/MS Excel integration. 

 

Thanks!