Leaderboard

HEY!!! I have a perfect example for everyone of stuff to not go poking around in! The "Get LV Class Default Value.vi" ... if you pop it open with your favorite password cracker, you'll find a Call Library Node. You pass into that Call Library Node a path and an app instance refnum and out comes the LV class. And now you're thinking, "HEY! Aristos Queue didn't put that app instance refnum on the conpane of the VI! He's hiding functionality from me! I can use this to get the value of a class in another application instance!" And so you wire up a different application instance. And you run your VI. Now, sometimes you crash right away. Other times, you don't crash until you try to close the project. Other times you just get a crash on exiting of LabVIEW. In any case, you've thrown off the reference count for LV class data because -- ha -- it is an ILLEGAL OPERATION TO PUT CLASS DATA FROM A CLASS INTO THE WRONG APPLICATION INSTANCE. You have to marshall the data from one app instance into the other app instance, because the *class itself* might not exist in the other instance, or might exist with a different definition (i.e., in one app instance you loaded c:\x.lvclass and in the other you loaded d:\x.lvlclass). And, hey, if you want to go indexing off the end of a pointer into undefined memory, this is a great way to do it. I swear, by all the nodes and wires in Heaven, none of this stuff has any business being on any block diagram except for the one that it is on and that we password protected. It is either useless to you or subject to change in a future version of LV because we're still refining it and have no intention of supporting the current version (unless it passes testing and we decide to make it official, but we might not have time to do that in a given release, so it may take a while, so just because it has been there and private for a few releases doesn't mean it will be there forever).

Your curiosity will have to be satisfied with "a certain way we can configure the UI to make controls generic".

Thats the sort of performance we could do with in this case! However I don't think these will run. These give us the ability to run unbuffered to the hard disk on Windows. On RT I tried this option earlier and it threw the fantastic generic file IO error (and in Windows you can now do this in the native API now) I checked with a few people on the file size set. With this we will request a file of that size to be reserved by the OS, but we still can't guarantee that the OS wont fragment the file still.

I believe using Set File Size from the File IO palette should ensure this (though the documentation does not shout it out as it does for the equivalent TDMS function)

On this LabVIEW Wiki page, the following text can be found: I aim to show that this is not true. While most programs will remove the code if the image is altered, it's relatively simple to use a free tool called TweakPNG to put any VI into any PNG image. First, download TweakPNG. Now, create a VI Snippet of whatever you want. I'll be using this as an example: Run TweakPNG, and you'll see the following: Next, open your VI Snippet in TweakPNG. Select the item that's selected in that screenshot ("niVI") and then go to Edit->Export Chunk. Save the file wherever you want; you'll need it later. Next, open whatever image you want to put the VI into in TweakPNG. I'll be using this image: You'll see the following: Once again, click the item I selected ("IEND"), but now go to Edit->Import Chunk. Remember the file you saved earlier? Select that. You'll see this: Finally, go to File->Save in TweakPNG (or File->Save As if you don't want to overwrite the original image) and you'll now have a VI Snippet with a custom image. Don't believe me? Here, save this image and drag it into LabVIEW: I'm not encouraging anyone to make anything malicious as mentioned in the wiki article, but this does have legitimate uses. For instance, you may want to add some extra text to a VI Snippet explaining something, but don't want it to appear when it's dragged into LabVIEW. Or you may want to scale the image down a bit so it will fit somewhere on a web page. I'm sure there are many other uses.

You are correct, the capitalization instructs editors to remove the chunk upon graphical editing. By using non-compliant tools (like Microsft Paintbrush or TweakPNG) you can bypass this. So it's not a prevention of malicious snippets, but a precaution. NI could add info to the 'niVI' chunk that contains info about the containing file (like the complete or hashed IDAT chunk). The code capture tool does exactly that. It even inserts the tool name, and optionally some copyright info. Ton

I saw this at the Maryland Science Center in Baltimore and I just had to take a picture of it. I only thought to post it just now.

Some years ago i started out the task to create a VI editor that would let me edit the documentation of a VI without actually opening it (other than for reading the flat binary data of course). This was a spare-time project but ended up being a sort of in-depth view into the fundamentals of the VI structure. Today i use the resulting class framework for mass documenting VIs whenever i can (included in my editor is a fix for the long lost CTRL-B bold text combo that NI seems to have forgotten to implement). The editor is pretty basic but are able to edit/change the VI Icon, History, some window properties, Set/Remove Load-and-go, add/remove VIs from libraries/llb/classes, shuffle around with some security stuff, show VI call hiearchy, create boolean 4-picture controls from gif/png/jpgs, extract VIs from old/new style labview exe's and a bunch of other stuff that are pretty handy when developing lots of LV code Of course, it's all done through LabVIEW itself I never thought of releasing the code because it probably violates every law out there, but if you spend a little time with a hex editor (or LV itself) its pretty basic figuring out how VIs are build. Hint: once you figure out the structure of the VIs, you can use the OpenG function "ZLIB Inflate" to restore the packed sections to their normal size..

Some times I wish there were a more open file format for LabVIEW. I'm not looking to write my own IDE, but to be able to open the vi and determine what kind of objects are in it, or what labels there are without having to open it in a development environment would be nice. Lets say I want to do some documentation generation on a folder of VIs. Right now I can read the icon, and VI description without needing to start LabVIEW by analyzing the bytes in a hex editor. But what if I want to get the connector pane information? Like what terminals labels are and their data types? Or what if I use Requirements Gateway and I want to find all labels on the block diagram that start with "Covers: ". Looking at the VI file structure I have not been able to find free labels or text. Here are the things I have been able to pull out of the VI file structure by analyzing the hex bytes: Main/Internal VI version, LVSR Main/Internal version, flag bits, if a VI is protected, the Window Title, the Help Path, the Help Tag, the VI Description, a 24-bit image of the icon, and a 1-bit image of the icon. I think I can also determine if a VI is re-entrant, and the Revision History if I spent some time. I thought about releasing my findings on how to pull out this information from a hex dump of a VI in the hopes someone will be able to get more information, and possibly pull out free label text. If anyone is interested I can try to put some time into cleaning it up a bit and releasing it. I mostly stopped trying to figure out the VI file structure because most of what I want to do can be done with LabVIEW Scripting. I just think that it could be done faster by reading the VI file.

Let me comment on some of these things Full disclosure: I'm currently maintaining LuaVIEW and I'm the lone LabPython programmer, who did this in the first place to find out how the script node could be used by someone outside of NI. And once I had that, I realized that wrapping those functions into VIs would allow real dynamic access to the Python engine. At about the same time my collegue started to develop LuaVIEW for a rather large customer project. We had quite some fun arguing over if Lua or Python was the better language. While that view is a personal taste it is clear that Lua is a very much self contained and extremely compact scripting environment that is much easier to embed in other systems like LabVIEW. In fact Python, at that time at least, had no real intentions to actively support embedding of its engine into other environments. The API was there and it could be done, but the Python developer community was in general unresponsive to any suggestions of improvements in that part. Unlike LabPython LuaVIEW does NOT have a script node interface but only a VI interface that not only allows but in fact requires to pass a script at runtime. While LuaVIEW doesn't do that out of the box currently it would be not a to complicated project to develop that. But I'm not convinced about the need for that. Aside that LuaVIEW is free for non commercial use, the initial purchase costs are usually the smallest parts of a projects cost. Any decent software programmer will incur the license costs of a commercial LuaVIEW license in two days of programming an alternative solution. Two days is very little time for such a thing as a scripting engine.

QUOTE(Michael_Aivaliotis @ Feb 24 2007, 12:20 PM) Hmmm, my guess is that customfile.lava is not a valid LabVIEW file (that's what the error message says). If you have a non-LabVIEW file that you want your exe stub to handle, you need to pass it as a user-defined command-line argument, according to LabVIEW conventions (pass it after the double hyphen "--"). QUOTE("LabVIEW Help") Application:Command Line Arguments Property Returns an array of user-defined command-line arguments passed when LabVIEW launched. User-defined arguments start after two hyphens (--) surrounded by spaces in the command line. The first string in the array is the name of the executable launched. This property does not return the name of the VI launched or the LLB that contains the VI. If a user-defined command-line argument contains double quotation marks ("), this property returns the argument without the quotation marks. If you use this property in a stand-alone application, you can pass all arguments as user-defined arguments so you do not need to enter the two hyphens before user-defined arguments in the command line. This property is similar to the Pass all command line arguments to application option on the Advanced page of the Application Properties dialog box. Example