hooovahh

So maybe a strange question, but what's this conversion do for you? The information is already available in that original variant. All this does it convert it into another data type.

Uh...variant to data the primitive that turns a variant into the data type you want, if you know the data type, which it sounds like you do. The OpenG stuff is most convenient if you don't know what you data type is. This is most common on APIs that are made to be more generic and detect multiple data types and act on them differently, or for things like message communication APIs when the payload can be anything. Oh and if you have a cluster and want to turn it into an array of variants you can use the variant to data here too, telling it to convert into an array of variants. Post your actual data types so we can help more. EDIT: Maybe something like this?

After that does it open and run properly? I really should install some other versions of LabVIEW, for stuff like this.

Because I'm an idiot and didn't test my code after back saving, which didn't include the subfolder that LabVIEW didn't know was a dependency. Attached is an updated version including the images in the demo. Ribbon Interface Test With Images.zip

If your VI has no block diagram VIPreVIEW won't help, it is designed to show the block diagram in a web broswer. Your only hope at running the VI is to open it in the exact version of LabVIEW it was compiled for. But even then you can't change the code at all, all you can do is run it, assuming it isn't broken. And if it does open broken you can't edit the code to make it not broken.

FYI something similar happens for Windows registry. If you read Local Machine\Software\National Instruments from LabVIEW 32 bit, in a Windows 64 bit, you will actually be reading from Local Machine\Software\Wow6432Node\National Instruments. A handy feature at time, but usually causes more issues than it solves. I did not know a similar function was made for the file system in regards to System32.

Oh so sorry I missed that, tiny light green wire is hard to see on white background.

I promise I haven't been working on this for over a year. I just got some new information from someone, on ways to get around the licensing limitation using native LabVIEW code. I believe I have a proper modern XNode Editor, that will create an XNode, or open an existing one, then allow you to add new abilities. These abilities are enumerated from LabVIEW, and if new ones are added, the list should show them. This means it is not version dependent, and shouldn't need updating, just to add new abilities. It also has a way to change the version, XNode library icon, and description just like the XNode Manager mentioned before. I haven't fully tested it, but it appears to do what it should. I back saved it to 2012 but I don't have 2012 to test with. New XNode Editor 2012.zip

So this code is not polished at all, but it was something I did as a fun pet project and realize I won't be able to finish it any time soon. It is a ribbon interface done in a way that could be scaled up. Ribbon like UIs have been done in LabVIEW here. But these UI's relied on button controls, to be configured and made a specific way, and if you needed to update tabs, buttons, or groups, it had to be done manually. So I wanted to come up with a way to make a ribbon like UI, but all that was required, was to provide the tabs, groups, and buttons, and the UI would be drawn. The end goal was to make an XControl with value change events when the user presses one of the buttons, but for now this is just a demonstration of what is possible. The idea was the XControl would also be smart enough to only redraw the parts of the image that were changed. Like if I changed the top tab background color it wouldn't have to redraw all the bottom parts of the UI. Here is a video demonstration. Here I show the default settings, then change some of the color and text settings. http://screencast.com/t/daan9D78vqV Some of the challenges that you don't really think about, that the API needs to be able to handle, is the text being of an unknown length, and number of rows. Things like the top tabs needed to be able to expand right, or down as needed, and all other tabs, and images needed to shift to compensate. Same thing when it comes to the button and group text. Here you also have the added complications with the fact that the text might fit in the space already needed, like if the button is wider than the text. Images are scaled using .NET and the GDI resize. This is also where images are combined, since some may have alpha layers, much like the included images do. I knew image scaling might take a while, and wouldn't be the type of thing I would want to redraw as a mouse moved over a button. So for that reason I draw all the button states on startup, and then just combine the appropriate images for when the mouse is over, or down on a group, button, or tab. This means a pretty fast response on the UI but means more memory is needed to hold all the button states in memory. Doing the gradients efficiently for me meant doing them natively in LabVIEW. I found some .NET code that would do it, but much slower than LabVIEW just drawing horizontal lines, and using math to determine the next color of the line. Several times images or parts of images needed to be shifted and translated. Instead of converting a picture back into image data, then performing the move, then converting back, I used the code posted by Norm here. It needed to be updated for a few opcodes but for the most part is fantastic and made the image processing quicker. Other than mashing this into an XControl, I also didn't get around to creating a way to disable or disable and grey out buttons. This would take more image manipulation magic and possibly more images to hold in memory. Since disabled buttons are probably going to be somewhat rare, I thought I might draw these on-the-fly instead of on init like all the other button states. Anyway I hope someone finds something in this helpful, because I doubt I'll be able to do anything with it for a while. Back saved to 2013, and remember this is very unfinished code, be gentle. EDIT: Attachment removed, re-uploaded with example images below.

Oh wow, I wish I was around to see some of that. Looking at what changed in a VI to make it signed would have been interesting for sure. And being able to view LabVIEW code without LabVIEW is something several people have tried to do in one form or another with varying levels of success. I remember seeing one version on LAVA that made some kind of java script of a VI that would let you go to the other states of a case structure. Too bad this has been abandoned for ~15 years. Again if you can post the VI source (with block diagrams) we can try to help update the code, or post images of the block diagram with the code capture tool. EDIT: VIPreVIEW is what I was thinking of https://lavag.org/topic/7132-vipreview-interactive-vi-preview/

Okay lets back up a bit. What is your issue? It sounds like you have some VIs saved in LabVIEW 6.x or so, and you want to open them? It also sounds like the block diagrams of the VIs are missing. This brings up two issues. Versions of LabVIEW can only open specific versions of source. Here is a table. http://www.ni.com/tutorial/8387/en/ Next there is the fact that when a block diagram is removed, the source code is removed. All that remains is the compiled code essentially, and there is no publicly known decompiler for LabVIEW. Even if there was it would go against NI's EULA, and probably would work like crap anyway since so much of LabVIEW's visual information would be lost in a compiled binary. http://digital.ni.com/public.nsf/allkb/FEE732F4B1541B9586256BF0006A78CA What is a LabVIEW Player? Where have you seen this mentioned? Error 34 means Print Dialog Error, explain in detail, every step you take and everything you see. Do you see this when you go to open the VI? What version of LabVIEW? What version of your OS? Can you post the VI? As for the linked page you found. That sounds like it has nothing to do with what you are doing, and you should probably avoid those topics until you fully understand what this Low Level VI editing is for. It is not a bad topic to discuss, but it is one that the general public doesn't need to know about, and will likely break something or cause NI headaches in the process. It is extremely experimental and not condoned by NI.

The way this is coded these two processes happen in parallel. If you are on a single core you may get inconsistent results. Also with UI's being updated asynchronously, if one finished, before the other (which we expect) then your timing won't be consistent because your computer will be off updating the UI and may take away cycle counts from the other process. Basically the timing information from that VI can't be trusted, but the fact that the numbers are so small means it probably doesn't matter anyway. Also can't that bottom for loop be removed all together? AND and OR work on arrays as well as scalars.

Saved for 2013. It looks like this uses some OpenG stuff so be sure and have that installed too. ClusterViewer 2013.zip

Reading the whole file and modifying it in memory is probably the only decent solution. That being said there are a few DLLs that can be used to modify ID3 information. Here's a few sites of which I haven't personally tried. http://id3v2.sourceforge.net/ http://id3lib.sourceforge.net/ http://tomorrow.uspeoples.org/2013/02/powershell-id3-tag-editing-via-taglib.html

I've been using the Simple Sexy timing probes for years now and they are very similar. https://decibel.ni.com/content/blogs/EvanP/2010/10/04/simple-sexy-labview-timing-probes They also have the ability to pause an execution if time is greater than some value.

What are the tablets running? In a Windows environment you could synchronize all their clocks (to the ms) then when your program runs, send over TCP the time stamp of the event. Then when your host system gets a buzzer, let it wait say 100ms for any other contestants to buzz in with an earlier time stamp.

Neat, thanks. I think there are a few operations that could be simplified but lots of neat nuggets in there.

Heres a good start. I don't really have the time to do all of it. Provide a path to the Main VI, then run this. I will find all callers of that function, then in each VI look at each subVI. If the subVI called is the error one, then it opens a reference to the terminal, gets the source of the wire, opens a reference to a constant wired to it, then gets its value. I think I forgot to close all opened references, and this has an output letting you know if something other than a constant (or nothing) was wired to the error code (0) input. Find All Error Code (0) Constants.vi

Software is not data, gotcha. BWAHAHA

What would you consider ad hoc reuse? Someone comes up my desk asking "Hey how would I perform a partial search for a 1D array?" If I show that user code that does this, and the user redevelops that code based on what I told them, is that reuse? What if I send them that VI in an email? Is that reuse? What if I point them to a forum link online showing someone who posted code on how to do it? Let all agree a formal process of release is better, and does take more time and effort. But isn't some of these thing in between considered reuse at some level? It isn't easy to track, and so usually when I say something like "This project is 50% reuse" I'll usually say this project is at least 50% giving the reasoning why some reuse can't be tracked.

So...instead of asking a question you made an article, which is usually used for showing people how to do a thing. And instead of showing someone how to do that thing you asked the question? Then in the forums where you would ask the question you just link to that article? Why didn't you just ask the question here? I've edited your post so the question is in the forums where it belongs. As for your question what have you tried? Have you searched this topic, I remember finding several semi-working solutions involving hidden path controls.

Not sure if you're aware of this, but 2015 is supposed to cache bookmarks in a much smarter way to improve these issues. I can't say for sure, since I didn't use it much before 2015 so I'm not aware of many slowness issues.

Looks pretty good to me. The only improvements I could suggest (which I tried and have no real effect) is to disable debugging and automatic error handling, replace compound arithmetic with the native AND and OR. And I would assume LabVIEW could look up stream and find that the boolean array output isn't used and might optimize that away. But adding an indicator (outside the for loop with the other indicators) didn't change the result of the test. So in this situation LabVIEW does its job better than we can. Or rather the compiler can use things it knows and create code that performs better than we could create. And honestly this is one of the staples of LabVIEW programming. "Don't worry about it the compiler will take care of it." This statement is both something I've relied on, and something I've hated at times. The compiler isn't perfect, but I obviously trust it enough to rely on it daily.

Yeah some of us are dumb enough to actually host our first crapware. To be fair I think that is probably my second crapware attempt since my first attempt is gone forever. Once I discovered LAVA I realized that would be a better home for cleaned up code so I haven't put anything new on there other than the tray launcher which has EXEs and installers that I don't think LAVA would like.

Eh, it depends on how it is measured for sure. Back then there wasn't the code complexities that was added in 2012 or so, so coming with reuse metrics could be up for interpretation. I've used the code complexity for a reuse measurement metric in the past, and then broke it down into things like OpenG reuse, MGI reuse, vi.lib reuse (is that cheating?), and other reuse. Then there is reuse that can't really be measured like copying an existing library, or whole project from some old code (data mining), where here reuse is between 0% and 100% but code can't really detect the exact amount. Edit: I should probably force myself to get some free time and release my reuse metric, unless VISTA is going open source