Sparkette

Actually I figured out something that works. Even if the alpha checkerboard appears in the icon editor, if it's in an enclosed area, it appears as white. It would still be nice to have it cover things in lower layers though. The alpha checkerboard can actually be useful though, as each square on the checkerboard is one (scaled) pixel in size.

What exactly do you mean by "[you] came up with a syntax"? Is it just something normal that anyone can do, or are you referring to LabVIEW's source code? I just haven't heard the term 'syntax' used in the context of dataflow programming.

flarn2006,

 

Can you use this tool to debug LabVIEW2012 and make it better?  then you can re-brand it as LabVIEW2013

I don't know what you're getting at. Are you joking? No offense if you're not.

D'oh! Sorry for the triple post, but I remember now that that's why I wanted to place the contents of the VI rather than embedding it as a subVI. (I knew there was a reason.) That way the adaptive terminals would work correctly, and I could program my code template VI as I would if I was writing a generic VI, but it wouldn't be as dangerous. Anyone know how to do this?

And yes, I am aware this thread has gone off topic somewhat.

This is why LAVA exists. Love it!

Strange, I thought it existed because of intense heat and pressure underground or something like that.

As long as you are the owner of the bike. 

That's what he said.

Also, remember I mentioned VI Explorer at the beginning of this thread? I got an email back from him and he said he's working on making it work with LV 2012, so we'll probably have a solution soon that doesn't require modifying the EXE.

The stock Icon Editor actually uses and stores icons as 24-bit color -- yet the icon preview on FP/BD, and also instances on a BD -- are rendered with a palette that very nearly resembles (or, is exactly) the 216-color web-safe palette, plus 10 each for a spectrum of R, G, B and greyscale to make 256 colors.

 

In other news, 8-bit and minimalism (e.g., "Metro") is one branch of latest design trends -- we could turn the conversation positive and just call it ahead of its time 

What does Metro have to do with this? I know it's a joke, but I don't see the connection.

That's actually a good idea, and I'm surprised I hadn't thought of it. I'll give it a try and post if anything goes wrong (which wouldn't be a surprise since I'm working with Xnodes.)

Worked great! Though I wish it was easier to get adaptive terminals to work.

I usually create a new subvi on the diagram using a path to the template. SubVIs then have a method to place their contents. I am on my phone so this is from memory.

That's actually a good idea, and I'm surprised I hadn't thought of it. I'll give it a try and post if anything goes wrong (which wouldn't be a surprise since I'm working with Xnodes.)

The icon editor uses a 256 color palette, which is why it won't let you select 254, but I believe 255 should be allowed inside the bounds. That said, recently I've been using LV 2009, where I'm pretty sure I'm using a modified editor, which might allow this even if the original doesn't.

And just in case you were thinking it . You won't be able to use scripting to "peek" inside a password protected diagram.

Also, what makes you think it's not for copying to another VI? If so, there wouldn't be an Owner parameter that does that. (Though come to think of it, it could be more for putting things in structures and stuff like that.)

All I'd like to do though is make a subVI that can be placed in an Xnode GenerateCode VI, which will duplicate the contents of a template VI and hook up some terminals. That way I can program the Xnode's generated code just like I would if I was writing a regular subVI. It's a shame Generic VIs are so problematic.

Oh really? Told you I wasn't a lawyer. I guess I'll just keep this to myself; sorry to anyone who's disappointed.

Scripting has a lot of these holes. The fact that it is official now does not mean it is fully debugged.

 

In this case, I don't think the Top Level Diagram should implement the Move method, as moving a diagram doesn't seem to make too much sense.

I thought maybe it would move/copy the entire contents of the diagram. Anyone know how I can do that? Keep in mind that all I have is the refnum for the diagram to put it in, since I'd like to use this in an XNode's GenerateCode ability VI.

I've noticed that whenever I select white in the VI icon editor, it doesn't actually draw white; just a very light gray. I finally decided to Google http://is.gd/NEsoDF]"labview icon editor white"[/url], and it said it's because for some reason, LabVIEW considers any white on the outside of an icon to be transparent. A little outdated, but I can live with it. The problem is that unless I'm doing it by accident, any time I'm drawing anything in white I'm doing it on the inside of the icon, completely surrounded with other colors. How do I tell the icon editor to knock it off, and just use the color I select?

Also, does anyone know why it uses (246,246,246) and not (254,254,254)? Manually selecting the latter just gives me the former, same as selecting pure white.

I found a bug that's reproducible using VI scripting. I was trying to programmatically place the entire contents of a VI onto a block diagram given the diagram's refnum, hoping it would help me make XNodes. (It's important to note that this bug does not involve XNodes at all, as if it did, I'd write it off as one of the reasons they weren't really released.) First, here's the code I used--notice that all the property/invoke nodes are cyan or yellow, not brown!
 

 
Drop that into a new VI, and then put any old VI in the VI reference node. It should be one with at least some controls/indicators, so don't just create a blank VI.

Now run the VI. A new front panel window with the same controls as the reference VI should open, but the block diagram will be empty. Double-clicking on one of the controls to jump to its respective terminal just opens the blank diagram. Just for the hell of it, I looked in Heap Peek, and no Front Panel Terminals were listed.

Finally, duplicate one of the controls and click Run Continuously. LabVIEW will crash.

If you are having problems installing VIPM you may want to contact JKI or post on their forums here.

 

As for alternative ways to install package files.  The packages them selves are just zips, so you can extract the file and see the contents.  The spec file defines things about the package, and the files and groups.  Using this information you can manually install the files by placing them in the right locations.  It wouldn't be too much trouble to make a VI that does this.

 

HOWEVER, this will go against what JKI has been trying to do with VIPM having configuration management.  Lets say you manually install a bunch of packages.  You have no way of knowing what conflicts, or limitations exist and you may end up with code that is broken, or missing components.  You also don't know what versions of what packages you have already manually installed, and you may overwrite VIs with newer, or older versions of them selves.  VIPM helps to know the dependencies, and links requires, as well as the limitations, and environments that those VIs can be used in.

Well I downloaded a bunch of package files on another computer, but I can't seem to find where VIPM stores its library. Where does it put the packages it downloads?

You could share it with NI and help everyone that uses the feature, you would probably help more people!

Well I don't think anyone you help is exactly going to go trying to get you in trouble are they. But then it might not be their software and then you are aiding IP theft.

As I say, I don't know exactly what could happen but I'd say there are as many people who stand to get hurt from it as benefit, just because you say you would be ethical with it, I've heard there are some unscrupulous folk on this Internet (though I don't believe there are many wandering the LAVA corner of the net)

Thanks for the offer, but the only way I'll ever improve DRM is by disabling it. I won't "help" them by giving them a false sense of security.

Besides, if they tell me it's their software, so I disable the password, wouldn't the law be on my side considering I had no way of knowing it wasn't theirs? As I mentioned, I'm not a lawyer, so I could be wrong.

Whilst I agree in principle that no harm is done there is a reason why they have password protected it and you have therefore gone against their wishes without know why they have put the password on. It is also hard to prove if you work on something similar that you have not taken inspiration from their IP (and there is little legal protection against this I believe). There is a reason why we have curtains on our bedroom windows 

 

I can't speak on behalf of the organisation regarding what would happen if you posted it, but it would certainly appear to be in breach of your license:

 

 

As for the consequences I don't know exaclty, presumably you could be at risk of being sued, especially for disseminating the information. If your employer owns the license they probably wouldn't be to impressed!

Then I'm afraid I won't be posting it. It's a shame, really, but I really don't want NI's lawyers to go after me.

I've seen some posts before about people having lost the password to their own VIs; could I get in trouble if I offered to unlock those for them as a favor? (and then, of course, actually did so?) In that case, I wouldn't be going against anyone's wishes, except maybe NI (though if they just need help with their own IP, I don't see why they would care.)

<sarcasm>What could possibly go wrong with this?</sarcasm>

Exactly. This is purely for fun; it would be idiotic to use this in any important VIs.

Here's a tip for editing objects: copy something to the clipboard, and then select BDHP Clipboard or FPHP Clipboard on the left (for block diagram or front panel, respectively) and select the object on the right with an asterisk before its name.

Not really. It also is in answer to some of your points, although yes it clearly is targeting also and even more so the points flarn makes.

 

While it is unlikely that you will get into legal problems if you look at a VI diagram that was not intended for you to look at and if you only use that knowledge internally, without redistributing what you learn from it, it is still not legal to break the password at all. Forcing the door of a house is illegal independent if you want to steal something or just nose around for your curiosity (or find out what has been done wrong there in order to not make the same mistakes in your own house).

 

If you or anyone else doesn't like the password protection of a VI, you should not download it or ask for a refund if you bought it, and cease using the VI and any accompanying software altogether, not breaking into it to use it anyways in the way you like.

I wouldn't try to make a profit off somebody else's block diagram without their permission, password protected or otherwise, but I don't see anything wrong with messing around with it, as nobody is any worse off than they were before.

Also, of course I wouldn't force open someone else's door to look around their house. With a password-protected VI, on the other hand, I'm not doing anything with anyone else's property (intellectual property aside.) Intellectual property is very different from physical property. The latter makes perfect sense, as it can only be in physical possession of one person, and if someone else takes it, they're depriving me of it. The former, however, exists only in the form of information. The idea of a certain sequence of bytes being the possession of one person any more than any other is purely a legal invention. As long as I'm not making a profit, depriving someone of something, or falsely claiming credit, I don't see any moral issues.

Back on topic: can I get an answer from an NI employee about what exactly could happen if I post how to bypass the password protection: Obviously I won't want to post it if I could get sued or something, but if not, I'd love to share my findings.

Well in the same way you can of course argument that users do not want to pay for contents and software and therefore it is legal to crack software and put it on the street for free. However there are users who rather pay some money for something useful and also enjoy the added benefit to not download viri festered content that way (most crack download and password cracker sites contain nowadays mostly unhealthy junk if they even contain a single working crack of what they claim to do).

 

And as Djed and James pointed out, the password protection is there because of user request, not to protect the few NI secrets they have (they are better protected by putting them in the 30MB of binary compiled LabVIEW executable code nowadays, and a few more 1000MB of compiled shared libraries). So which user do you want to protect with your password crack? The one who feels nobody has a right to prevent him from seeing a diagram, or the one who produces content for people to use, without wanting to throw all the details on the street.

 

There have been numerous cases of people posting "their" own libraries on various LabVIEW sites, some of them copying open source VIs verbatim, others copying functions from commercial toolkits. If your  position is that nobody has a right to hide his code from you you may have to live with the consequences that that code is not developed anymore for sale, but kept internally, so nobody can profit from it anymore.

 

Well, why do you think someone being very much active on this forum and providing contents and answers should pay, while someone who mostly uses this forum to talk about how to hack the software the forum is about shouldn't?

I never said I have any less of a moral obligation to pay as anyone else; just that I don't think a premium membership is worth it. I'm 19; I don't have a steady income yet.

Also, the only reason I feel entitled to look at the diagram is because it's in the VI file. If it's on my computer, I feel I have a right to look at it. If LabVIEW didn't have access to the block diagram, I wouldn't necessarily feel I should, but seeing as it's on my computer in an unencrypted form, I see it as fair game. Understand?

I'm not trying to "protect" anyone with this hack. Nor is it taking away any protection. By leaving the block diagram in the VI, they are throwing all the details on the street, as you put it.

I found a hack to remove the time limit to edit your posts, see here

Well played.

I can't say I was aware of that, but I don't think it's a big enough issue to warrant spending $40 per year, especially considering I'm not always active on this forum.

Thanks, though.

So I'm aware that OpenG can be downloaded directly from Sourceforge. However, it's not obvious how to actually install it. I would use VI Package Manager, but it won't run on my computer and just crashes. I've had this problem since version 2011. So what I'm asking is has anyone made a guide to install OpenG manually?

Also, even if NI "fixes" this exploit, it's just going to keep getting cracked. If the block diagram isn't encrypted, there's no way to prevent it.

And I think it's worth mentioning that I have a strong moral aversion to any kind of "features" like this, where programs are specifically designed to go against the user's wishes. When I see something like that, there's nothing I want more than to find a way around it.

(Why is there a time limit for editing posts here? It's simple on every other forum...)

I hacked the Bounds property of an Add node...when you move it you can see it's trying to draw a really wide , but it doesn't seem to be erasing properly. Also, the terminals don't scale with it.