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!)
I’ve discovered what appears to me to be a quirk in the behavior of dataflow in LabVIEW. This discovery occurred while working on an application that contains a main while loop and housekeeping code that runs after the main while loop. I’m enforcing the order of execution in the VI by wiring the error cluster through the main while loop and over to the housekeeping code.
Attached is a zip file containing a VI that reduces the application to its key components. The VI contains two while loops connected by an error cluster. The cluster passes through a subvi and sequence structure in the first loop, then passes through the second while loop and finally enters another subvi. A screenshot of the VI block diagram is also attached.
When the VI execution property “Allow debugging” is selected, the VI operates as expected - the second loop will not start until the first loop stops. The quirk occurs when “Allow debugging” is de-selected. In this case, both loops begin running as soon as the VI starts!
For some reason, the two subvis and the sequence structure are required to make this phenomenon occur. This phenomenon also occurs when the sequence structure is replaced with a conditional disable structure.
This behavior occurs in at least the following two environments:
1) LabVIEW 2014 32-bit on Windows 8.1 running within Parallels Desktop 11 for Mac
2) LabVIEW 2015 SP1 32-bit on Windows 10
I suspect that the cause of this behavior is that the LabVIEW compiler is trying to optimize the VI performance by noticing that the second loop and second subvi are not dependent on any data generated in the first while loop. If this is the case, it’s great that the compiler is trying to improve VI performance; however, what’s not so great is i) this demo VI shows that the error cluster does not always enforce order of execution, and ii) a change in the "Allow debugging" setting can change the behavior of a VI without any indication to the developer.
This apparent quirk raises two questions:
- Are there other situations where the dataflow paradigm does not behave as expected?
- Are there any tools available to find out about changes that LabVIEW implements behind the scenes that could cause this or other unexpected behaviors?
A short video demonstrating this issue is available here: http://www.screencast.com/t/D3mCCqFyz
Any thoughts on this issue would be much appreciated.
Data Flow Test.zip_remove_me
By Tomi Maila
When I originally selected the name for my blog ExpressionFlow back many years ago, what I had in mind was functional dataflow programming and the ability to pass any subdiagrams (expressions) around as first class citizens of the language. Functional programming languages (haskell, clojure, lisp) have a lot in common with dataflow world. In principle, calling a function in a functional language is identical to calling a node in a visual language. Passing data between functions happens in an immutable way in functional languages, similar to the concept of data flowing between nodes in a flow-based programming languages. Monads determine execution order of functions with side effects, the same way as flow diagrams determine the execution order of nodes in LabVIEW.
Functional programming is often seen as an alternative to object oriented programming. One can solve similar problems of dynamic dispatching either by passing functions around or passing objects with methods around. There are of course multi-paradigm languages supporting both objects and functions like Clojure and Scala. So what would LabVIEW look like if it supported concepts of functional programming paradigm? I posted an article on this on ExpressionFlow and I am intending to study the concept on ExpressionFlow in my future posts.
Would you use functional LabVIEW if such a language existed?
My post on how a functional programming could appear in a visual dataflow language:
Synchronous Functional Dataflow Programming & Closures of Named Functions
p.s. See Joel's quick intro to functional programming if you are unfamiliar with the concept of functional programming.
By Tomi Maila
I am happy to announce that I am back in blogging on ExpressionFlow. I'm trying to cover more theoretical topics around visual programming and discuss new fresh approaches. I'd like to invite everyone to follow the blog and @expressionflow twitter account.
Please let me know the kind of topics you'd like me to discuss. There's lots of cool topics on my mind already but I would love to hear from you, what would be something interesting for you all.
Thanks, and happy Thanksgiving for everyone!
I have a multicolumn listbox where I would like a "right-click" to set the value of the MC listbox to the row that was right-clicked, then a shortcut menu will appear. Depending on the value of the MC listbox (i.e. row clicked) I determine what right-click menu options are available. To do this, I use the mouse down event, and if it's a right click, I set the MC listbox value to the row clicked. Then, the shortcut menu activation event is fired, and in there I use the current value of the MC listbox to enable/disable menu items. My question is this, can I always expect the mouse down event to occur first (it seems it does), or do I need to manage the order in which the events fire. I guess I could also handle all this logic in the mouse down case, inside my case structure, when checking which button was pressed. What I want to make sure I avoid is the shortcut menu activation firing first and having the wrong row selected in the MC listbox which may disable/enable the wrong menu items.
After discussing w/ co-workers, I think the answer is yes, because the mouse-down is the event, the shortcut menu activation is the system response to that event. Please let me know if this is wrong.