hooovahh

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.

Check out the last 10 minutes or so of the augmenting the right click presentation named: 2015 NIWeek_08_Augmenting Right-Click Menus in LabVIEW 2015_Stephen Loftus Mercer-Darren Nattinger.mp4 It can be found on the FTP site of NI Week videos: https://lavag.org/topic/19154-ni-week-2015-videos/ It has lots of features, but the most accessible is the ability to write data in one place, and read it in another place, and have those two places linked by a wire that doesn't force data flow. Edit: Oh here's more. https://decibel.ni.com/content/docs/DOC-41918

I've actually never used that ability and wasn't sure what it is used for. Here is the description pulled from the resource files in LabVIEW 2014 for GetDisplayName3. I wonder if the warning comes from the fact that in 2014 there is actually two things to return, Type Name and Instance Name, where the older GetDisplayName2 looks like it only has Name. The GetDisplayName2 is probably deprecated. Still in the future when this ability is used it is probably easiest to just pull the name of the owning library and use that as the Name. Then this ability is more generic and would work on all XNodes.

I had a somewhat similar experience, where I was talking about how I wanted a way to breakup the TDMS file, defrag the parts, then combine them. This would give me the ability to have a progress bar on a defrag, and a cancel. Here is a post detailing some of my work. I eventually did come up with a solution, but the defrag time increased quite a bit. Glad there is a native solution, even if it doesn't allow for a cancel.

Crosspost

Oh well sorry I showed you a powerful tool that is something to be cautious about. The source is quite easy, just look at the template. All that is really needed is to set the number of cluster elements to the right number and it should work as a non-xnode which can be invoked as a merge VI. Just don't forget to set that number of cluster elements everytime the cluster size changes.

Yeah as others have said. The biggest ones for me are: Right click menus API, and a bunch of new right click menus built in TDMS defrag is faster, with an optional progress bar Perform TDMS operations on a file in memory, instead of on disk Delete data from a TDMS file on disk Hyper links in comments on the block diagram I think Quick Italics and underline (am I imagining it?) And the super secret feature, the Asynchronous Wire Faster executing code (I haven't tested) There are others and I forget way more than I remember but still for me this is a decent list when compared to the things I cared about most in 2014.

Sorry to answer an off topic question but I found more information on a comment. I just learned of a way to get an event generated on minimize or maximize. You can then choose to not update the UI if you have lots of power updating it. The event window resize is generated on minimize. You can then use the property node on the VI to get the front panel state. It has the previous state in the event but not new state for some reason.