hooovahh

So I made a few improvements, first I found that there were relinking issues from trying to load resources normally in the user.lib. The updated one should load from normal locations like the downloads folder (which is where most people are going to try this out from) It looks like you might just not know the right way to make UI's with the event structure. Generally you move the control into the case that is handling it, so that its value is read when you enter. Buttons being latch when released causes them to bounce back, so they are only true for that first time, then go back to false. This means when you enter the event structure it will always have a value of true and you don't need to check it. Polling the timeout case with 0ms isn't necessary. The code does nothing until you press a button or interact with the UI so remove it. I added a case for panel close, so to stop you close the window instead of hitting a button. Prompting for the number of numerics, strings, and paths, had a while loop with 0ms wait which is bad for CPU usage. I replaced it with an event structure. I removed several backwards wires. I added Update While Typing to the string control, so that value changes are registered if you click on the save right after making a change. After a load it picks the first resource to display. Functionally I think it is the same as what you had. Now lets talk about this fix MD5 business you have going on. You prompt to ask how many Numerics, Strings, and Paths are on your connector pane, but you never use this data to calculate your salt. But even if you did you need to be aware that this includes going into other controls. If you have a single cluster with two numerics in it on the connector pane, and a scalar numerc also on the connector pane then you have 3. So this needs to include things like numerics and strings in error controls. A more robust method is to calculate the salt by reversing the equation and guessing what the salt is. I've done this in the past by assuming something like, there will be no more than 20 numerics, strings, or path controls on the connector pane. This could be increased of course. But with a known good VI you have the MD5 output, and the data going into the MD5 you just are missing the salt. An equation with just one missing variable. So if you keep guessing the salt, making the assumption that there will be no more than 20, then it doesn't take too long to go through each possible combination finding the one that makes the equation MD5 = Data + Salt. If you want you can remove the limit of 20 setting it to 255, but it would take a decent amount of time to go through all 255*255*255 possible combinations, where 20*20*20 is more realistic. You also aren't fixing some issues when VIs are part of a library, I believe there are other checksums that need to be updated but don't remember what they were exactly. Oh and was the XNode necessary? Could you just perform the search on the string name "LIBN" instead of taking LIBN then looking up the type as a number? And I know this won't work for all versions of LabVIEW. You know how Ned lets you save in multiple binary modes? That's because older LabVIEW versions used the older binary methods, which might have different named blocks, so BDHX I think is some times BDHA or BDHB. And 2015 is really new, most people aren't going to have it, an older version might have been a better choice. Low-Level VI Manipulation Hooovahh Edit.zip

With NI Week this fell off my radar sorry. I never had a need for N floating windows. But if I did I would handle it by having a single actor be the "Dialog Actor" or whatever, which would spawn new VIs asynchronously. It would then keep track of all asynchronously running dialogs with an array of references. Closing a window would send an event down to the Dialog Actor which would do whatever it is that it needed. If the Dialog Actor got a message to close a particular window, or save or load control values it would be the one responsible for that. I've also handled similar tasks by using a listbox of windows, which would insert them one at a time into a subpanel. This handled the N instances of something in a single window. The benefits of this type of design is the only thing that is asynchronous (and more difficult to debug) is the actual UI, not the actor it self handling all the messages. Probing and opening that actor was easy because it was on the block diagram of my main running VI and I could hold CTRL and double click to open the BD.

Great suggestion, topic split. Next time suggest that sooner, 2 1/2 pages of that 3 page discussion was on this one feature.

Thread split with discussions on Channel Wires moved to here.

I believe this is exactly what it is. Thanks for the link to the encryption compendium, I'll check it out. The corporate world I live in does not consider Linux a viable option for anything. I will be sticking with Windows.

But in NI's defense they did use visual queues to help show that it isn't just a normal wire, going into and out of structures don't use tunnels. This for me was enough to know they were special, but probably not enough for new developers.

So at an NI Week presentation this year, NI talked about how their new cRIOs with RT linux can have some kind of seed key encryption on them for some level of protection. What this basically means is you have a public key, that can be used to encrypt data, then you can send that data, and using a private key, decrypt the data into the original payload. I thought that was a neat idea and something that I haven't personally needed but got curious to see if a toolkit existed that uses this technology. Especially if the payload can really just be a stream of bytes, which can represent any data type. I believe the RT Linux systems are using GnuPG, and I found a Windows install, and command line documentation. Has anyone done this before? Anyone done it in LabVIEW?

There was never a LabVIEW 2008, not sure what version this worked in but I'm sure it is not a supported feature of LabVIEW. The right answer is to make a new application. Editing an EXE is not supported, and by doing so you might be causing unpredictable changes to the software. If you get nothing else out of this, I hope this is a lesson for you to implement a source code control system so you can easily roll back and forward to releases. You could then get the source which was used for your last EXE, make a branch, make changes, then make a new EXE. But one thing that just occurred to me, does your EXEs have their block diagrams and front panels removed? If they don't then I suspect you can get tricky and extract the VIs from it, make changes, then build with that source.

The Load and Save resources is a relatively well known function, and was recently discussed in a thread where a user was looking for a way to detect if a block diagram existed, when looking at the VI contents within an EXE. https://lavag.org/topic/19068-does-vi-have-block-diagram-at-runtime/#entry114822 In that case the detection method was to look for the BDHb, BDHx, BDHc, or BDHP blocks. My method in that VI was to parse the binary file itself pulling out the block. I posted that code, or similar code in a thread, with you some time last year. The Ned window and XML is a little less known, for several reasons. I discovered it myself by going through the list of keyboard shortcuts. I read up about the heap peak window (CTRL+SHIFT+D, CTRL+SHIFT+H), then I saw there was a window command (CTRL+SHIFT+D, CTRL+SHIFT+W). I figured this meant Debug, and Window and Debug and Heap Peak, so I went through the whole keyboard looking for new shortcuts, low and behold D, N was the ned window. As you can imagine saving in XML is an incomplete function. It might work for simple VIs, but I'm guessing not all VI types are supported. Things like VIs in libraries, ability VIs, and other things might not be supported. When I talk to other LabVIEW guru's and I want to blow their mind with features that they didn't know existed in LabVIEW, talking about VI password protection, and saving in XML are the topics I usually go to. Now that more people know about these things I need to continue to research other topics. That being said you did teach me something new today, and that is the ability to set and get Ned settings using VI Server, that is some very cool stuff and could come in handy.

Did you mean to post the code as a .vlibp? Do you realize this removes the BD and makes the code only executable in that version of LabVIEW and no other? At the moment this means only those with LabVIEW 2014 can run this VI. On top of that the community might be curious about the implementation, and fixing any limitations or bugs but can't without the source. VIs seem to be lacking documentation. Which also makes me not sure what the difference is between the new and "Old" versions. Do you intend on supporting tabbing into the element of an array control? I also saw a strange bug where if you skip tabbing into a tab control, it sometimes won't let me tab out of it. A VI is attached which shows this issue. Still it is a very neat feature, and hope it can be improved so others can use it. Tab Out of Tab Bug.vi

@ShaunR I disagree. But if my options are to make an awesome XNode, that is built on unreleased technology, or make a decent but not perfect polymorphic VI but is supported, I will go with the polymorphic VI most of the time. Uh...aren't you NI? Where would you like us to report known issues for this feature? I think the real answer is, we do like we always have, and NI doesn't officially support unreleased features outside of NI. I have lots of private functions that when they don't work I don't call up NI, because I know I won't get support. But I know a few at R&D will troll these (and NI) forums and help us out, telling us a general feeling of "This is mostly stable and lacks documentation" or "This will crash LabVIEW, do not use it." If you are one of those with inside information, we'd greatly appreciate any details you can give about stability, or instability of unofficial features.

That's not true, it's more like you have a nail, and we both have hammers, but my hammer can hit more than just the one nail that your hammer is limited to. Polymorphic VIs have a subset of feature that an XNode can. Of course they could be seen as overly complicated method of doing the same thing. Also can we agree that the polymorphic VI editor is a major pain to work with. Of course having a difficult feature of LabVIEW shouldn't mean to throw that feature away, it might be to suggest improvements, or make alternate editors. I'm just trying to make a point that there are several features of LabVIEW that have subset features of this one unreleased technology. I think the thing about XNodes that has me coming back, is that given enough effort they can meet so many needs. Where things like XControls usually fall short of some edge case, unless the uses are very limited, at which point all that extra effort feel wasted. If I wanted to make a competitor to a polymorphic VI using XNodes I could and it would probably work better than the native polymorphic VIs, supporting more features too.

I've always done this with the command line version of VLC. Here is the example command for converting a WAV to an MP3 I bet there is a way to reverse this.

I've never used LabVIEW for Linux but I assumed it was the same, which is why it also doesn't have public downloads available.

I agree and would like to take it a step further. What can an polymorphic VI do that an XNode can't? What can an Express VI do that an XNode can't? What can a Generic VI, or VIM do that an XNode can't? If XNodes were a released feature, I wouldn't mind seeing polymorphic VIs, Express VIs, Generics, and VIMs just go away. XNodes aren't perfect, but if they were released I'd see little reason to invest in these other technologies. I hear the complaint that XNodes are too difficult, and a VIM is easy. Well sure but with scripting we could make XNodes. So if you wanted to make a VI that accepts specific types in terminals, or has rules about the types of data it accepts, you could write a wizard that generates the XNode that does that. As for Generics still being in 2015. I believe NI actually used generics in a product of some kind once successfully, and probably doesn't want to break compatibility this quickly. I mean if VIMs have been sitting in LabVIEW for 10 years and hasn't really been used (that I know of) it just shows NI is apprehensive with deprecating and removing functions.

Okay maybe this could be useful if the generation code was stable and works without a license, but I'm still not satisfied with that first step. If you have code that can generate XNodes, and their abilities, you could invoke it from the project and replicate some of the functionality NI has, but man does that sound like a lot of work. Besides I also heard that the primary type plugins in the PPF were a bit less stable. I never heard specifics, but I was told adding new right click items to existing items (like VI types, virtual folder types, etc) should have no problem.

Just twice? So your LabVIEW stability went up? Just kidding.

I have yet to look into the code yet. And jkodosky doesn't so much get asked to release things, he's more like the one telling people to release things...well probably sometimes with legal involved. I honestly don't know the inner workings of NI that much, but what I'm trying to say is, he has a lot of pull. http://www.ni.com/company/our-vision/leadership/kodosky.htm That being said when asked about VIMs in the past someone at NI mentioned that is is an old experiment (10+ years), following up the statement stating that the technology "sometimes works". That comment might be dated and who knows things might have changed. Or Jeff just felt like having some fun.

The thing that worries me about those device is the software that you are forced to use. I'm worried it would be crap making the scope worthless too. I've had some success with the myDAQ being used with the pre-written scope code it comes with. It's also a DMM, and function generator, but costs more than what you linked to (even at the student price) and probably doesn't have as good of specs since the scope function is just a mSeries DAQ device. If you do ever buy one of those cheap USB scopes, I'd be very curious what you think of the software it comes with. The reviews on that one look mixed for sure.

Yes I'm aware of the Project Provider Framework, and actually requested official unofficial access to unofficial documentation (or is it unofficial-official-unofficial?). I hope I get time to try to make a few things I have thought about. 2015 and right click sparked new interest in it for me in PPF. But at the end of the day the project provider just gives you a means for running content aware right click menus in the project explorer. Regardless of where the VIs are ran from, there are plenty of functions that simply return an error of not having a valid XNode license, when you run it on a machine that doesn't have a valid XNode license. Yes there are illegitimate ways of creating XNodes, but if we can demonstrate to NI that the functionality can be exposed in a clever, and more legal means, then maybe that might help convince NI that XNodes can be released. That being said I talked to a couple people at NI R&D about XNodes being released, and the unofficial word is they tried making a push to release it. But due to the odd licensing scheme used, making XNodes official might never happen. It sounded like the type of license that is currently being used, cannot be activate through an NI server, without being connected to an NI network. Which makes me believe that even NI employees can't edit XNodes unless they are connected to the NI domain. That last part no one stated directly.

Pretty neat, here's one of the scopes that are popular with the hobbyists. http://www.amazon.com/Rigol-DS1054Z/dp/B00N222I6C I don't own one (yet) but one reason why it is so popular is because someone reverse engineered the licensing scheme for their line of scopes, and by entering the right code into the scope you can convince the firmware it is actually a 1104Z instead, which is a scope with twice the memory, twice the speed, RS232, SPI, I2C decoding and a bunch of other features. Your $400 scope is now as capable as the $1,000 scope. Here is one of the most Canadian hack videos I've seen describing the steps involved, but note the site he references no longer exists but I assume others do. EDIT: Oh interesting tear down that I haven't watched all the way through yet. http://hackaday.com/2014/10/22/how-to-reverse-engineer-featuring-the-rigol-ds1054z/

I was referring to the fact that Channel Wires can be pass into subVIs, and diagrams where your XNode implementation cannot. The idea is you can then follow the data of the Channel Wire and find all those involved in generating or consuming the data. Would a 3D environment help? I'm not sure, what benefit does that give me? It certainly adds another layer of complications, but organizational-wise I think it would be too much to work with. Processors naturally have parallel operations with multi core work, FPGA even more so. So having a 2D environment with parallel operations seems like a good design. I guess if processors had another layer, maybe if each core of a processor was made up of N cores, then a 3D environment could be used and development might help write code for processors of processors. But since the coupling between cores is not that big of a deal, and the compiler takes care of the FPGA side, even here I don't think it would be very useful. Besides we only have 2D screens, lets wait to make LabVIEW 3D until we have holographic monitors.

I don't use Macs but it might be related to this. https://lavag.org/topic/15619-ctrlshift-shortcuts-sometimes-not-working-in-labview/

This is kinda fun, it does a few things you don't see in XNodes very often. That being said not being able to pass wireless data into our out of subVIs, or even structures is pretty limiting. Thanks for sharing.

It's feedback like that, that I'm guessing NI is looking for. But if you were to ask R&D I think their answer would be something along the lines of how LabVIEW has some weaknesses when data flow isn't followed. If I have queues being opened by name, it can be difficult to know where messages are being enqueued and dequeued. With a Channel Wire you have the ability to trace back where the data came from. Visually debugging can be easier. It can probably confuse the hell out of new developers but honestly NI had catered to new developers in other ways, and I'd rather not hold back a language in favor simply because it is a concept that beginners struggle with. It is a balance for sure. While this technology fascinates me, the implementation is also interesting. All done in G code, creating the VIs as they are needed, and keeping a cache of the ones already made. Sure XNodes would have done this for you too, but if XNodes can be avoided, and still get the same (or similar) functionality I understand the design choice. It opens the way for other developers to make other cool right click scripting tools.