Sparkette

Well what's the price?

As with many of my posts, this is very dangerous, and should under no circumstances be used with anything too important to be affected by crashes, corrupted VI's, and other bad stuff, which will very likely happen as a result. This is only posted as a curiosity about the internal behavior of LabVIEW I found an interesting private property for the GObject class: Basic Object Flags. This provides low-level access to an object's flags, such as (for controls) the mechanical action, disabled/grayed behavior, etc. Some of them cause very strange behavior, which is not surprising for a private property. I can confirm that this is the same as the "flags" value seen in Heap Peek. I wrote a VI (attached here) that lets you change these flags. Just wire a GObject reference to it, and the front panel will pop up and let you interactively change the flags and see the results. Does anyone have any more information on what some of the flags do exactly? Here's what I have so far for controls: 00000008 - Object is disabled (sort of like it forgets it exists)00000010 - Object is not selectable00000020 - Object is not resizable00000080 - Object is grayed00004000 - Object exhibits strange behavior, becoming grayed at random00010000 - Affects mechanical action00020000 - Affects mechanical action00040000 - Affects mechanical action Object Flag Manipulator.vi (For those unfamiliar with private properties/methods, they're additional properties and methods that remain hidden even when scripting is turned on. To enable them, just add "SuperSecretPrivateSpecialStuff=True" to LabVIEW.ini, but be warned, this is internal low-level stuff that NI doesn't support.)

It seems more likely that Fake Exec State would be able to do that. (not sure if it actually can)

I found that one too, but I'm pretty sure everything you can do with that command you can also do with the debug keys. What do you mean by "much needed" by the way?

Why do you say that?

If someone were to figure out the format though (I haven't, in case anyone's wondering), how would they get LabVIEW to actually import it as a PICC image? By examining copied decorations in Heap Peek + Cheat Engine, it seems like the decoration is only showing an image that's hardcoded into LabVIEW. Does LabVIEW contain functionality to show an embedded PICC image just like it does with any other image you paste in, or can it only show that image format if the image is already programmed into LabVIEW? Also, I noticed the Silver controls, added less than two years ago, still make use of the PICC format. Why continue to use this when you can add support for an open format like SVG and use that instead?

Anyway, back on topic: does anyone know how to get LabVIEW to use a PICC image from somewhere other than LabVIEW itself? As in, to include some arbitrary PICC data as an image, rather than just using an image already included with LabVIEW? Barring that, does anyone know of any other vector formats that can be imported into LabVIEW and have certain parts scale differently, like the "shine" on the classic LED? Or that weird two-boxes-connected-with-line thing I found?

I know what external nodes are, but why would that get me excited? And I'll take a look at SimX.xnode when I get a chance; thanks.

Good idea, but I don't.

Thanks for your help, but I managed to get it working. JKI support sent me a link to VIPM 2010, which works fine. Here's the link in case anyone else is having the problem: http://jkisoft.com/updates/vipm-2010.0.2-windows-setup.exe

Wow, this thread sure is getting off-topic. NI doesn't make the law. (That would be silly.) Say I created a game, and I put in the license agreement that you weren't allowed to make mods for it. (For the record, I would never actually do that, as you may have guessed.) Someone made a mod for it anyway. Now if they were selling it, maybe even giving it away for free, I might be able to claim they're violating my copyright. (Without copyright law, software licensing is meaningless.) If they just modified the software on their own computer and played it like that, I wouldn't be affected in any way. I know cars are overused in analogies, but if I buy a car, and the manufacturer of the car says in the manual I'm not allowed to modify their copyrighted design by painting it another color, I can still do so. It's still my car. If the manufacturer goes that route with the copyright, they might be able to prevent me from then selling my car, but otherwise I can modify my car however I want. (as long as it's not violating any laws that would exist anyway.) How is software any different in this respect? It's my computer, and while I may not own the rights to the software, that particular copy is still mine, as it exists only on hardware 100% owned by me. As long as there's no damages, I fail to see how any legal action could be possible. You can't sue someone for pissing you off, even if they said they wouldn't. That's why I'm not releasing my password hack, as if someone uses it in a way that causes harm to NI or someone else, they might have a case.

This isn't my thread.

This isn't the first time the EULA issue has been brought up. As long as I'm not doing what I'm doing to make a profit or anything like that (or to enable anyone else to), I'm pretty sure I'm in the clear. Correct me if I'm wrong, of course.

I think the reason NI password-protected the VI is not to prevent people from learning (seriously, why would they do that?) but rather to prevent misuse of a feature which has not yet had enough testing for a public release. Thankfully in the case of private methods and properties they have provided a "backdoor" of sorts for people interested in experimenting with them at their own risk: the SuperSecretPrivateSpecialStuff INI key. (This is what Antoine Châlons mentioned before.) No idea why they chose to do it for this and not built-in Xnode editing though. Also, must every topic containing a mention of disabling LabVIEW's password "protection" turn into a moral debate?

I noticed my PM space quota is filling up. While it's only 35% now, it's only a matter of time until it's all used up. When that happens, rather than buy a premium account just to get more space, I'd like to archive them on my computer, as I don't want to lose them. Is there any automatic way to do this (similar to Google Takeout) or will I need to copy and paste them all manually?

I think you might be misunderstanding me. You know the various structure node, like the while loop and case structure? They're basically nodes that can contain nodes. What I'm wondering is if it's possible to make new types of structures like those using Xnodes.

I mentioned I know most of them weren't designed as decorations. I do know a lot of them resemble controls, but that doesn't mean it's not interesting. Also E5 and E6 aren't what they look like--if you resize it you see it's two boxes connected with a line.

I'm sure there's some internal process that requires something like that.

I just noticed that VI didn't save properly--they all just appear as blue squares...*facepalm* Not really much of a surprise. At least there's the image.

I'm not annoying them; it's not like I'm calling them or anything like that. I'm just curious if that specifically could cause problems.

I was messing around in Cheat Engine by changing the "image" attribute of copied decorations. This attribute is shown in Heap Peek as "image [iMAGE] 0x######## (kPiccImage)". Anyway, I was trying different values, and I ended up mapping out the entire 0xFFF504XX range of possible images. This took me a while, as I had to increment the value and paste it 256 times. I'm sure there's a better way; in fact, if I do this again I'll probably copy/paste them eight at a time or something. Would anyone from NI know if these modified front panel decorations would be dangerous to use? I would think not, as I just made it show a different image from the list, but it would be foolish to count on it working. Also, I remember hearing that Picc is a proprietary image format, and I thought that the actual image data was stored in the clipboard. But apparently it's just an identifier for a hard-coded image? Anyone know what the valid range for the "image" value is? FFF50400.vi (And yes, I understand most of these weren't made for decorations.)

It's there now. http://labviewwiki.org/VI.Fake_Exec_State I also took the liberty of moving the page you linked above to "Private methods and properties"; when I get around to it, I'd like to add the Control.Genericity property, and I don't think we need a separate page for properties just yet.

Sure I will, I wasn't aware that page existed.