Neil Pate

Filipe, I do not see NI getting into the business of suing the end users of LV FPGA. Not that I disagree with your points, I just think it is unlikely NI would go after anybody other than the obvious primary culprit. Now, even having said that, I am still not going to expose my company (or my clients) to this risk and will choose NI officially sanctioned products over questionably legitimate offerings.

Yeah but haven't EULAs been proven to be pretty much worthless?

Could it be something to do with the fact that those two funny looking icons are expandable XNodes at edit time and expect to be redrawn on the diagram?

But they are kinda ByVal as you wire into an indicator to actually display the image. You cannot just make that association once and then assume it will automatically get updated.

Bingo! Thanks James. So Image refs are just plain old normal U64 size refs? I sometimes wish there was a way to see refs as native "pointers" in a probe rather than the special type (i.e. the image). I suppose I could create a custom probe and just display the U64...

More strangeness (probably just me not getting something). Why are all four Image references the same?

Hi gang, Simple question, can I treat a Vision Images ref just like any other U32 ref with all the rules applicable like forking wires etc? It seems to me that there is some kind of special stuff going on with Vision Image refs. Another related question, in my particular use case I have a piece of code generating a user event with an image as the data at some arbitrary fast rate. The act of Generating the user event creates the a copy, right? Some other code wants to process some of these frames (at a slower rate) and then I use IMAQ Copy to make a local copy, is this IMAQ Copy necessary or could I just hold onto the "Image" reference coming in from the user event? In the code below Images is just a local buffer I plan on using. The reason I ask is I am getting some weird behaviour whereby destroying my Images refs as shown in Capture3.jpg kills my acquisition code as well. (I presume because I am forcing all images to be destroyed, but I am surprised this is happening)

I think you are trying to bite off more than you can chew here. DVRs, LVOOP and especially Dynamic dispatch is not really the first thing you want to learn on your LabVIEW journey.

I recently ran a simple vision application with a single camera that ran perfectly smoothly on a desktop CPU but absolutely choked on an Atom tablet. Nothing fancy going on either...

Perhaps not the greatest way to ask for help.

Peter, have you tried accessing the Excel worksheet by index instead of name?

Thanks. I think I am mostly on the same page as everybody here.

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. But as I mentioned, although this worked fine on my PC it was broken on the target PC which had a much older version of Excel, so in a panic I uninstalled Office 365 and installed Office 2010 and everything then worked fine.

I have flip-flopped with this issue for like forever. Say I have a simple dialogue that can be cancelled by the user, is it more sensible to return the cancelled status or the ok status? I have always done it by returning a Cancelled status, I am just curious as to what others think is sensible.

I do not have an answer to your problem but can only share something that happened recently which is probably not related to your issue but I will say anyway. I have an Office 365 subscription and one of the more recent updates broke the report generation toolkit as the ActiveX interface to Excel changed. I was able to manually relink the ActiveX component in the code and everything worked fine on my PC after that, but the executable would then not run on my target machine which had an older version of Excel on it.

As far as I can tell a Matrix is just a typedef to a 2D double, there is nothing at all special about it.

Normally if I have multiple 1D numeric arrays if I want to combine them into a 2D array to display as a table or write to file or whatever I used to Build Array and then transpose the 2D array, however I have discovered that the Build Matrix prim is actually configurable and defaults to assembling by columns. Hooray! This is probably old news to some people, but I share anyway for those that don't know

I would second what smithd wrote. What is your experience with OO in LabVIEW? Certainly trying to refactor an application to OOP is not a good place to start your journey I think.

Ok good. Don't worry about the cluster for now. How did you generate that array, did you do it from code or manually?

Champions access only (things like this make me sad...)

Ok so lets try and make this as simple as possible. Imagine all you have is a single constant value of your International thankyou enum on your block diagram. I get the feeling you would like to display this as a 2D string array with the first column listing all the possibilities of the enum and the second column has "1" in the column of the row that matches the constant value otherwise it has a 0, is this correct? Can you describe in words how you would create this array?

Ignoring the fact that your array is not doing anything at all (you could just wire the Array indicator straight to the Strings[] output) you said you wanted to show the value as well, with 0 or 1.

I have given you my advice. Try implementing it as a 2D string array first. Leave the tree out of it.. Once you have mastered that you can think about getting it working in the tree. As I said way earlier on in this thread I really think you are "mixing methaphors" here. The cluster viewer displays the "values" of items in the tree, not the set of all possible items. If you want that you are going to have to add it yourself and the tree API is not pleasant to work with.

You need to learn to crawl before you can walk... perhaps somebody in this forum will just show you the answer you are looking for (i.e. do your work for you). I am not that guy though, sorry.

Thanks Yagnik. The tree control is not a nice thing to work with, I fear you are trying to do too much at once. I think perhaps you need to start off a bit smaller. If you really really want to include the enum items in the table first try and get it working as a 2D string array. I mean not using any of the code you have been, just by figuring it out yourself. You can achieve what you want with a single enum and a nested for loop. Once you have that working you can figure out how to get that integrated into the cluster viewer code you have.