Jump to content

peter_flores

Members
  • Posts

    10
  • Joined

  • Last visited

Posts posted by peter_flores

  1. 8 minutes ago, gsussman said:

    While I can't offer a specific solution to your current problem, the issue of integration with Microsoft Office components has been one of those thorns in the side of developers for many years. The problems you are seeing with incompatibilities between versions of Excel are not something that is likely to go away after delivery. Corporate IT departments are continually pushing new patches and versions from Microsoft which will from time to time break your interface.

    As a general rule I do my absolute best to sway the customer away from direct integration between MS Office tools and the operational LV code. It has always lead to heartache and support issues. Every....Single....Time.

    We have pondered this same thing... It is appearing this is tied to a specific Windows 10 Update that we would have no way to control for... What are common, high-value, alternatives to MS Office reporting? Obviously, there are the TDMS, csv, and HTML (you would need a good graphic/web designer for this, yea?)... Our report has a mixture of pictures, printable pages with header/footer, variable number of worksheets (one per experiment in a batch), and raw, CSV-like data. It is hard for me to think of anything that does all of this at all, let alone with the simplicity of Excel...

    Maybe diadem?

  2. Quote
    49 minutes ago, Neil Pate said:

    I did not need to do as you documented, it was sufficient for me to just re-select the broken method call inside the offending RGT VI . If memory serves me correctly it was the "SaveAs" method of the _Workbook object. All I had to do was reselect the method and it then was no longer broken. I think I noticed that the new method had an additional input.

     

    Ahh yes,I did notice this behavior and seems to be explained by this thread: 

    The more and more I dig and test, the more I am thinking this is a corrupt office install on a machine, maybe affecting the registry, and unrelated to these other issues. The behavior was mostly isolated to one machine, though I have seen it on others - but this could be after the faulty machine flipped or corrupted something in the ActiveX? Don't know, I am kind of reaching here...

     

     

  3. @hooovahh Thank you! I have seen that and noted it. We are actively working on testing in LabVIEW 2016. To note, is that we are not using RGT (is it normal to think this TK is not done very well and is to be avoided?). Specifically, I need to copy/paste sheets in excel and did not see this as a supported function in RGT. It seems odd to me this TK is not very full featured and seems to be antiquated - do many people use it? Or is it common to go it alone and do your own ActiveX implementation... And this behavior did occur using LabVIEW 2015 to control Office 2013. I am fairly confident it is not a new issue to Office 2016, but I should know for sure today or tomorrow when I run with LabVIEW 2016... Thanks!

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

     

  5. Hello world!

    I am having a very strange issue controlling MS Excel through ActiveX from LabVIEW. I feel like it is likely not a rare task yet I find little to no helpful documentation from the MS side or NI side :/ I am a CLD and am working this project with a CLA and it has cost us over 40 hours of painstaking troubleshooting so far! I hope you can help. Here it goes...

    I am using the following setup:
    Windows 7 Pro
    LabVIEW 2015 SP1
    Office 2016
     
    I have created a simple LV class to create excel reports which works without an issue on my computer. The problem occurs when I run the code on another PC - Excel crashes ("2016-12-06_1125") and needs to restart, and usually then feeds an error back to LabVIEW("2016-12-06_1152"). This crash is asynchronous to the LabVIEW calls, meaning that a different VI will report the error each time. The problem occurs in Dev Environment and as an EXE.
     
    I have been developing and validating on these two separate systems during the last 3 months of building this project without an issue. The only difference between systems has arisen with the Excel automation. I have now run the project on 5 or 6 machines where 2 exhibit the problem repeatedly. On the rest, I have seen the behavior, but remedy it by updating the ActiveX reference as described below.
     
     
    Other systems:
    Works: Win 7, LabVIEW 2015 SP1, Office 2013, .NET 4.6.1;           Win 10, Office 2016, LabVIEW 2015 SP1, .NET 4.6.2
    Does not work: Win 10 (.NET 4.6.2), LabVIEW 2015 SP1, Office 2016;     Win 10, LabVIEW 2015 SP1, .NET 4.6.1, Office 2016
     
    "Version 1.3"
     
    A strange behavior that must be related, but I have not been able to exactly correlate it with good or bad behavior is shown in the other two screenshots attached. "Version 1.9" shows the .NET library that should be selected. Occasionally, this appears as shown in "Version 1.3", which looks like garbage - it is hard to tell what library that eve is supposed to be and why it would switch on it's own. We have tried setting this as a constant, control, typedef, with no luck in locking it down and keeping the "Version 1.3" behavior at bay.
     
    Related Post?
    In doing a lot of googling and research, I have not seen much info on this. Though this post looks like it is describing a similar behavior, though not exactly the same. 
     
    Thank you in advance for your help! This is holding up delivery of a $50k LabVIEW job that is scheduled to be delivered by Dec 15 and is looking unlikely because of this bug/anomaly, please help! (you know, the last 10% rule, ahhhh!)
     

    2016-12-06_1152.png

    2016-12-06_1125.png

    Version1.3.PNG

    Version1.9.PNG

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.