Sparkette

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?

My understanding is the CDSM's diagrams are also first class citizens in LV. At the very least, they have their own special VI Server classes, both for the structure and for the diagram.

 

My guess would be that this is not possible using XNodes, but I can't say I looked into them deeply enough to provide a sound base for that guess. It's mainly a feel for how the system works.

 

Flarn, if you look through the structure classes and find an External Node class, don't get excited. That's the precursor to XNodes, and they were basically implemented as a flat sequence structure which held the actual code and was then minimized and hidden behind an icon. I don't think they will do what you want.

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.

If you have the email notification enabled, they should be stored in you mail-box as well.

 

Ton

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.

Flarn: I realize I have contributed to the hijacking of your thread, but I figure it's ok because I also contributed to the main topic at hand first. :-)

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?

Is this close enough?

 

https://decibel.ni.com/content/docs/DOC-13859

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.

What's so special about those pics? If you haven't noticed, they resemble many standard LabVIEW control components, just in a special colour scheme. Ever heard of blue screen stamping and such? Would seem quite logical to use specific colours to identify various parts of a control, such as background and foreground area!

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 wonder why this method exists; it looks like an inside joke.

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.

You keep screwing with stuff that is not intended to be screwed with and continually ask for NI's blessing.  Knock yourself out, but don't except much more than the standard "at your own risk" feedback as you continue to annoy them.

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.

Hi flarn,

 

could you add this (and possible other interesting events) to the LabVIEW wiki page dedicated to such events?

http://labviewwiki.org/Private_methods

 

Regards,

 

Ton

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

Put that in a VI and click the Run arrow. The VI will keep running even though it looks like it's stopped. You can even use this to do VI scripting on a running VI! Since this is a private method, do not rely on this working, and don't complain to NI if it breaks something. Like with many other things I've posted, this is done at your own risk, and is posted only for the sake of sharing something cool I found.

priv = private message

Ah yes, I understand why. Thought maybe you discovered an easier way.

priv

priv=true doesn't seem to do anything. Is that what you meant?

I've been playing around with Xnodes a lot, and I was wondering if it was possible to create an Xnode that can actually contain code inside of it. You know, like a loop or case structure. I know the timed structures' side terminal boxes are Xnodes, but the structure itself seems to be a primitive. (Don't know why they made them Xnodes if the whole thing isn't an Xnode.)

Is this at all possible? (I hope I'm posting this in the right section, as Xnodes and VI Scripting are very closely associated.)

By all means "hide" data and functions. But don't lock them away so they need a crowbar to make it do what they want.

NI could learn from this...

I seem to remember NI saying something along the lines of "if you lose the password to your BD we cannot recover it for you". Classic politician/lawyer speak: 100% true, but actually skirts the issue totally 

You mean a Mathematician's Answer? Yes, it's true that they can't recover the password, but they certainly can recover the block diagram, which is what you want. If they couldn't do that, neither could I.

I just noticed the following piece of bad advice given by the VI Analyzer:

Test Description: Checks whether the block diagram is present. Do not remove a block diagram from a VI because you cannot recover it. You can password protect a VI if you do not want users to view the block diagram.

Did you invoke the Inline method?

I can't seem to find that method; where is it? And what does it do exactly?