Steen Schmidt

Lucky for him then . There is a big difference between using a hidden feature at your own risk that didn't violate any license agreement, and breaking a feature that could potentially invalidate the code security of NI's customers. But it doesn't upset me that much that flarn2006 wishes to look into how stuff like password protection is implemented, and maybe trying to defeat it. H***, all us techheads here probably have that urge in us, and we have done it in some form or another once in a while. We just have to look at how this or that works. Yes, that's an appealing trait. But it comes with a big responsibility, and that is where I feel the chain comes of. flarn2006 (what's your name really, I'd like to be able to call you something more human-like ) doesn't acknowledge this responsibility. Now he has asked in a couple of different threads if it's OK or not to tell people how to defeat the password protection. He seems to genuinely believe it is up to himself to decide which parts of a license agreement he may break, and he can judge all by himself that this is a feature that nobody but NI wants. I think the password protection scheme is a big deal. It can be broken, it's not that hard. I've seen it done numerous times over the years, it's not rocket science, so there's nothing to prove here. Only a skewed morale. If some of my (commercial) code ends up in his hands, I'll expect him to attempt to break into it, and I'll expect him to feel righteous doing it. But I'd be feeling robbed. So no, I wouldn't hire him, but I'd keep him real close if he was in my circles... He's by his own account only 19, so he can still change his views of course. Or he could be the one writing the next trojan that kills my backup servers... /Steen Did I really write "sole"? . Don't feet the trolls I must add then... /Steen

Lets' take the latter first; No, you're right, I cannot (nor would I) guarantee that anything bad will happen to our guy here. Of course not. What I really meant was that he would be breaking his contract, so he's not on safe ground. Almost no matter the circumstances, an exception being force majure-like circumstances where there could be legal outs to breaking an otherwise legally binding contract (the whistleblower policies for instance). But by "getting into trouble" you could argue that he derates his personal value, and maybe choses the path of lesser opportunity - i.e. he is less trustworthy if he choses to break a signed contract, and that will stack up against him eventually. Anyways, I reread my own post and I may be coming off as something of a doomsday preacher. Sorry about that to all of you! About the non-equality of intellectual and physical rights. You're right again, they're not the same, but similar in many ways. Especially more similar than flarn2006 seems to recognize. It's a topic that can't be treated with fairness in this forum, it's far too complicated. My isolated point was that regarding ownership and who-can-decide-what they are very equal. If you agree to some terms of usage, well you will have to abide by those rules. But there are several differences as well, but not in favor of the end-user; the clause of termination rights for instance, that does not exist for physical entities (I'm grateful for that). Add to this that intellectual property is treated slightly differently in different legal domains, but so are some physical property laws. So sure, they are not equal but equivalent. flarn2006 seems to think that "intellectual property" equals free-for-all though, and that's my main concern. /Steen

Doesn't it sound funny in your own ears: License agreement, and then breaking that agreement? Why do you think it's up to you to decide which parts of the agreement to follow and not to follow? That is the main point, I think, that irks us on this board; that you display such indifference to violating a contract that you have signed. I would never hire a guy like you, if I found such statements as yours on the internet. I simply wouldn't trust that you would honor any agreement that we made. Sure, software licensing is up for a major change over the comming years. That probably goes for large parts of the digital media usage legislation. But until that happens you have an agreement with your software vendor, no matter if you have paid for that software or it's free. One of the much talked about things currently is if you actually have the right to resell "used" software. My opinion is that you should be allowed to, but many software vendors disagree. Several large companies are in the process of changing their licensing schemes so you lease their software for a limited time (20 years for instance), in which case you definetely cannot transfer your contract to a third party. So, probably nothing bad will happen if you don't tell anyone what you do, but it's definetely a problem if you involve others. And even if you keep it exclusively to yourself it's still a violation, it's just not one with a high risk of getting spotted by anyone. Anybody can put anything into a contract as long as it's not violating any other law, and if you sign that contract (for instance when buying a car) it's binding. Using your analogy; Porsche had a very special paintjob on a very small number of 911s a year or two back, where they put in the buyer's contract that they were never allowed to repaint the car, and any damages to the paint should always be taken to the Porsche factory for repair. Nobody else are allowed to touch up that paintjob. That's a legal contract, and I expect those select Porsche owners are thrilled by owning such a special car . You break a contract. Contracts (your trustworthyness basically) and money are two things that glue the world together. It's taken very seriously when you mess with either. And damages? One could think up a number of possible damaging outcomes from you looking at source code you agreed not to look at for instance; You could get technical inspiration that made you rich in a couple of years - you could even turn out to become that software vendor's biggest competitor in the market. It could be even worse than that. A slight mention of how to break a licensing scheme (just wisper "MD5" and "Calypso algorithm" in the wrong forum) could potentially mean that some poor sole sold 5 instead of 5,000,000 licenses of his or her software. There are many many real world cases that supports this statement; Nero Multimedia, Winzip, Ghisler (makers of Total Commander), and IDM (makers of UltraEdit) for instance. /Steen

Thanks again Darren, that VI basically does exactly what Yair suggested and what I turned down as too much work . /Steen

Thanks Darren, I'll have a look. /Steen

Just stumbled upon this thread... @flarn2006: It's hard for me to see your points in any light different than the "new generation's view that everything in this world was made for them, and nothing that CAN be obtained is to be held from them". A few of my own comments: - There is no difference whatsoever between intellectual property and physical property. If you can't see that then you just have to live a while longer and it will dawn on you eventually. - You WILL get into trouble for releasing to the public any information that helps break the LabVIEW password protection scheme. The definition of "public" being any entity outside yourself basically. You will be in breach of NIs license agreement as well as the intellectual property laws of almost any country. Those laws typically state that if a lock is in place, you may not attempt to break it. They do not consider themselves with the strength of the lock, merely its presense. - Personally I'm for DRM when it's done right: it's the sole right of the intellectual property owner to chose which platform you may use the digital content on or with. The problem is that 99.9% of all DRM protected material is flawed by nature. The usual beef people have with it is that they felt they were promised that the digital content would work on some device that it turns out it doesn't. That can be categorized as mislabelling to downright fraud from the seller's side, depending on the circumstances. Unfortunately it's really hard to come down on a big company when they have promised you something that they can't or won't deliver. It's actually difficult for me to grasp how you can think that you own the intellectual rights to some software that you've only paid a tiny fraction of the development cost of? Do you sincerely believe it's OK for you to reverse engineer Word for instance, just because you forked out a couple of dollars for it? "Reverse engineering" in my eyes is just a matter of level. A password protected VI takes less work to get back to the clear source code, while an object file is a bit harder to reverse. You have in both cases been locked out from viewing the "source". It's not yours. And simply by looking at it, you obtain valuable information. Of course it's a pain if it's your own VI that happened to have a malfunction with the password protection scheme, but then as suggested you should contact NI to get it resolved. Regards, Steen

Darren, it's a shame the 'Read Icon Data from VI.vi' is password protected, as I'd like this functionality for LV 2010 onwards (as well as the corresponding 'Write Icon Data to Vi.vi' of course :-). /Steen

ShaunR: The Icon Editor isn't helping either. It doesn't get the conpane image really, it builds a slightly larger terminals outline image programmatically from conpane info. This conpane info is publically available, and I could use that to create my own conpane image... And then we're at what Yair suggests, namely that I build this image manually instead of grabbing it from somewhere, and hoping this process is faster than what I do now with scripting. The programming involved is quite extensive pixel-chipping though, so I think I'll stick with what I currently have and use those hours on something else in the BatchEditor. Thanks for your suggestions :-) Cheers, Steen

Phillip, the 'Get Conpane Image' method works fine, it just doesn't return the image I need. Marc Page's Polish VIs library does not get the image I need either, it builds a larger version of the conpane step by step - sort of what Yair suggests, just larger. /Steen

Yes I have, the 'Export Interface' method returns the same image as the 'Get Conpane Image' method. That is, the icon (not conpane "icon") including any controls and indicators connected to the conpane. It doesn't include the VI Description text either, which I had actually expected (to the extent that you can expect anything from private methods). That method is also a bit funny as it's marked as "Deprecated" (as in your image) when imported from an earlier LV version, even though it's still present, and selectable, with the exact same name in LV 2012 for instance. /Steen

Hi, Do you know of a simple way to check programmatically if a VI (any LV file actually) is compatible with different LV targets (Desktop, Real-Time, FPGA)? Currently I plan on scripting an empty project, add Real-Time and FPGA targets, add the VI under each target and check for execution state. Since I expect this approach to be slow as ****, and a broken (e.g. under construction) VI will defeat the check in any case, I'm looking for a better alternative. Is there some private VI Server methods that can tell me if my subject LV file is compatible with this or that target? Preferrably while loading as little as possible of the file into memory. Of course a VI and its dependencies need to be loaded to check for compatibility, but I want the process to stop as soon as a problem is encountered (since by then I know the answer is "not compatible"), and I definetely don't want the "searching..." prompt to appear if a dependency is not found at the expected path. Looking forward to your input here! Cheers, Steen

Hi, I'm building a BatchEditor to bulk edit/verify for style many LV files at once (projects, VIs, controls, folders etc.). For that I need to get the 32x32 pixel connector pane image. Not the icon (I can get that with the public VI Icon.Get As Image Data method), and not the image from context help (I can get that with the private Get Conpane Image method for instance). Instead, look at the output of my VI here: I do that by scripting a new VI, dropping in my subject VI as subVI, then showing that subVI's terminal image instead, then grabbing the image from there: In case you're wondering; the 32x32 pixel "Black frame icon" is set to get correct conpane images of subVIs that are smaller than 32x32 pixels to start with... But, this entire scripting approach is slow and convoluted, do any of you guys have a better idea to get this image? Cheers, Steen

I actually missed the above part when reading your post the first time - probably because the font was so large and in a different color that I mistook it for a commercial or something like that . But anyways, I have already modified the label and caption of those error clusters. The labels are now "Error in" and "Error out" instead of "error in (no error)" and "error out". The captions, which were empty before, does now hold the default value by default. I remove those default value parentheses when "Error in" is required (which it actually is for some of the functions in my "Error & Warning" toolset). The GPower style guide contains these rules (among others) regarding control/indicator labels and captions: - No default value nor unit in the label. - Labels start with a capital letter and every following word in the label start with small letters (thus "Error in" and not "Error In"). - Labels must be in bold. - Control captions are "<Label><space><(default value)><space><[unit]>". - Indicator captions are "<Label><space><[unit]>". - The <Label> part of a caption is in bold, the rest in plain text style. - Units may be left out of captions if the value is unit-less, else unit is required (also when there is no default value specified). - Default value specifier may only be present in the caption if the control isn't a required input on the connector pane. - Default value must also be specified for empty values (if the above rules state so). Such empty values could be "" (for strings), <empty> (for arrays), <none> (for variants) etc. So, following the above these GPower error controls and indicators have captions like the ones you see in the image in my OP; "Error in (no error)" and "Error out". I remove the " (no error)" part of the caption when "Error in" is required. I don't agree that the error cluster control should have special treatment when it comes to indicating its default value. I do find the connector pane tip strip indication (of some kind) of the default value a really good solution that would enable us to get rid of stating the default value in the caption of controls and indicators. So I've kudoed that idea. But no special treatment of the error cluster from my side. That said, the NI error clusters don't follow the GPower style guide, therefore they are updated for my use. I'm not sure how a better indication of unit should be implemented. It would be great to get rid of units in the captions as well, and I don't think the current unit implementation on controls in LabVIEW cuts it for this purpose - it's much too rigid to use in practice, so I never specify units on controls in reuse VIs (you know, the unit field that can be enabled for numeric controls). Regards, Steen

Yair, making an intermediate XControl delete itself after doing its stuff is actually a novel idea. I'll ponder that for a moment... /Steen

Hi. I have this 'Error & Warning' toolset with a functions and a controls palette: The controls palette contains only a single control, basically a subVI dropping its contents on the front panel when dragged there. That contents is two error clusters so I don't have to visit the control palette twice to get those (there are a small number of additional changes to these controls, mainly label and caption formatting to match GPower style). When dragged and dropped I have this on the FP: When dropping these it'd be nice if some additional stuff happened, like they automatically got wired to the correct connectors on the conpane (if they are available), maybe they placed themselves more conveniently than where you just happened to drop them etc. Now, I have been wrecking my brain about how to do make them do this. If I turn them into XControls it could probably be done, but I'd hate to turn something as fundamental as the error cluster into a proprietary XControl and litter those all over my (and other people's) VIs. I can't seem to get anywere with scripting on this one - the VI isn't being run when it spills its contents when dragged from the palette. Do you have any ideas, or is this too much work? I could maybe register some internal LV app event when the 'Error & Warning' toolset gets installed (it's a VIP), but that seems like a lot of work. Cheers, Steen

There's a bug in v1.3 that expresses itself this way. Please get v1.4 from the LabVIEW Tools Network. Cheers, Steen

VI Launcher is noted. I like that, and I agree that 'launcher' underlines the async behavior, where 'caller' can be both. /Steen

It is asynchronous. The toolset simplifies the process of dynamically calling, sending data to, running, and closing a VI. Like when you open a VI reference, setup control values on it with VI Server, Run it with VI Server, and then close the reference, possible invoking the Abort method if the dynamic VI hasn't stopped when you needed it to. So Dynamic VI Call & Run would describe it quite clearly, but is cumbersome. The VI Call & Run part I combined into Dispatch, but that makes the name conflict with launching class member function VIs. Dynamic Call(er)? Dynamic Launch(er)? Dynamic Load(er)? Dynamic VI Call(er)? Dynamic VI Launch(er)? Dynamic VI Load(er)? Dynamic Invoke( r)? I'm probably inclined to Dynamic VI Caller at the moment. Cheers, Steen

You're probably right Dave. Any ideas for a good name? Cheers, Steen

Within the next few days I hope to have an update to the VIRegister toolset ready. This update fixes the issue brought up by Götz Becker without sacrificing too much performance. Cheers, Steen

Oh, now I see what you mean. For sure, if you obtain a named queue A in callchain B and B goes idle before anyone else obtains A, then A will be released, thus losing any data in it. That's correct. Hmm, what would an elegant way around that be? I think a requirement of having to read all variables at least once at each call site is too much. The data should remain in memory even after callchain B goes idle. I'll have to think about this for a moment. Thanks for taking the time to construct the example. Cheers, Steen

Thanks, I'll take a look. Cheers, Steen

The quick answer would be that you have no need to communicate with idle code. The VIRegister instance(s) you create in the calling (non-idle) code will continue to live. There is no risk of a VIRegister in running code going unreferenced due to some other dynamic code going idle. Each instance is self-referencing as named queues are used - there is no "owner" of the queue other than the LV instance. That would've been the case with unnamed queues. /Steen

For a single I32: VIRegisters are 10-15% slower for a single read/write than the simplest LV2, but much faster than the LV2 for parallel reads (twice as fast for 5 concurrent reading loops for instance). Performance may depend somewhat on data type (the case for both technologies). I see the biggest benefit from VIRegisters in the fact that you don't have to tie them to anything to make them work. With globals and LV2 vars you need to create and maintain a file on disk. A local you must bind to a control/indicator on the front panel, and you'll have different sorts of performance and compatibility issues depending on the configuration of said control and hosting front panel (and you can't easily share this data between VIs). Variables like Shared Variables you must configure in a LabVIEW project, and they may need additional backends to work (the SVE for instance). A VIRegister basically wraps up a single element queue. You are given automatic obtain, error handling, and the most performance efficient method for accessing this queue. And it all lives inside a single "template"; the VIRegister polyVI. That it also performs almost as well as the fastest ordinary variables is just an added benefit in my mind. Even with 10 times worse performance I'd been happy (I actually improved performance from ~10,000 reads/s to more than a million reads/s along the way). /Steen

Since nobody else is replying I might as well keep this thread going with an important bit of info : A VIRegister must be located in an unshared call chain if you do not wire the Scope VI reference input! This means that no VI, in the call chain from the Top-Level VI all the way down to each caller that contains a VIRegister function, may be configured as shared reentrant nor non-reentrant. Only preallocated reentrant will work. The reason is that a VIRegister can be seen as equivalent to an uninitialized shift register when the Scope VI reference input isn't wired. The only way to get around this (as far as I can currently see) would be to check the Top-Level VI identity at each read and write - and that would make a huge negative impact on performance. There will be a note about this in a future update to the user guide, unless I find some elegant way to get around this limitation. Cheers, Steen Update: A quick test shows a 100 times performance degredation if I need to pull the call chain on each access. That's unacceptable. But I can make the VIRegister throw an error at runtime if it finds itself in a possibly shared call chain, without any impact on performance. That is acceptable for now I think.