Leaderboard

Okay I think I got it. Attached is a main and graph VI saved in 2011. The main can launch a new graph because it is reentrant. You can create a new graph window by clicking a boolean, or by dragging an item from the multi column listbox. Closing or stopping the main will cause all of the reentrant graph VIs to stop. If you created a new graph using the MCLB it will follow the mouse movement (with 50% transparency) until the mouse button is released. I used a few tips that fabric mentioned, but I did it using only native LabVIEW code, no Windows DLL calls, just the mouse VIs, and the VI property nodes. MCLB Drag Reentrant.zip

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

I have written a paper on the Strategy Pattern (with appendices on Interfaces and the Factory Method Pattern) in the hope that this will be a useful guide to others. We have published a PDF version of the paper: StrategyPatternWithLabVIEW and a zip file that also includes the source and model: StrategyPatternWithLabVIEW--WithModelAndSource. You can comment on the paper here, if you like. Paul

Ok, just got notified of this post. I'll fix it as soon as I can. Sorry about that. I have no idea what the problem is but no worries. I'll fix it. Thanks for you continued support of the LAVA Forums.

I almost feel like the sarcasm tag wasn't even needed for this one.

I've shortened quotes for sanity and added parenthesized numbers after statements to indicate what I'm replying to where. Yeah, it is kinda silly that people expect miracles from it. That's why in 2012 we added this to the password dialog: And why we published Security of LabVIEW VI Password Protection vs. Removing VI Block Diagrams. And why we continue to openly state that it is circumventable and only provides as much security as a locked door -- a determined intruder will get in due to the nature of a house. You want the homeowner to be able to get in a house and open the windows. You want LabVIEW to be able to get into the VI and open the block diagram. You can break the window or use a battering ram, or you can use the key. NI made this clearer in 2012, though no amount of warnings or papers will be enough for some people. That's why it's silly for people to rely on that. But just because they weren't smart/motivated enough to protect themselves does not give you the right to break in. Open source is great and I'm a huge fan. I've been running various flavors of Linux exclusively for 9 years. And I'm a software engineer. I realize that although great things come out the FOSS community, it is very very very hard to make a living off of FOSS software. Most FOSS software doesn't have a large enough user base (or code base) to make money purely off of support. You need to pay for software sometimes because that's how the technology industry works. We software engineers need to be paid, too. If you're only looking at VIs and not misusing the contents (plagiarizing source code, redistributing, stealing) then I don't think there's much harm. However, I think there is harm in immediately releasing information on how to break password protection because other people will misuse it. You are not the only user. LabVIEW is obeying a different user and disobeying you. Why should LabVIEW disobey a different user and obey you? Just because it's your computer doesn't mean you gain rights over other people. You choose to run LabVIEW. If a parent tells a child they can't have ice cream before bed, that doesn't mean the can have ice cream before bed in someone else's house. This was probably on the order of 1/10000th the effort put into LabVIEW 2012. We don't only have a duty to develop features important to customers, but also to continue to support older features important to customers, even if the feature isn't perfect and cannot be. Don't throw out the baby with the bath water. Although ShaunR opened with a bit of a dig that really blunted his message, I think he's definitely got the right message. flarn2006, check out Responsible Disclosure and a quick list of companies with Responsible Disclosure policies. Although NI doesn't have one, we have worked within the general framework of responsible disclosure with many people. If you'd like more of an assurance, I can try to find something for you. Finally, even if you're helping NI, it's probably not going to make us significantly more money. It might not even make us money. But you will also be helping customers by helping ensure customers have a more secure application. You talk like you're fighting a battle for the proletariat, the unwashed masses of LabVIEW users, against NI. In reality, we're pretty open to playing ball as long as you don't make it a pain.

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

"So, I think your question indicates you're still seeing Implemented methods like a Dynamic Dispatch override." No, I get it. You're looking for a statically resolved link. The possible paths code could take is completely resolved when things are compiled. Note: I'm going to use the word "interface" a lot in this post, and I mean it as a general point of interaction between pieces of code, not the abstract sense which comes up in some languages that use it as a keyword, or in several theoretical discussions we have had here on lava. I guess for me dynamic dispatch isn't fundamentally about just changing behavior via overrides or producing concrete implementation. Sure, that's the mechanics of it, but in isolation is of very little value. A class that has any dynamic methods defines a programming interface at one level that derivative classes can modify or must implement. The value in such a mechanism comes when the programmer writes code calling the dynamic methods from the superclass interface-- completely unaware of any derivative classes. This code can be part of the superclass itself or completely separate. The code that operates on the dynamic interface at the superclass level is essentially laying down a series of hooks, detailing the conditions when these methods will be called and has done so completely decoupled from any derivative classes which may exist at run-time. I suppose if I'm going to boil it down to one sentence it is this: just as important as the dynamic dispatch method itself is the contexts under which the method is called. (You can at this point hopefully imagine how important I feel documentation is for these methods. I die a little inside every time I see an undocumented dynamic dispatch.) So that's why I'm not sure I understand why a "must implement" could be useful. You're basically saying if you're going to have an "is a" relationship with me, you need to do something(). But an interface can't be provided so you can't provide the context in which something() will be called. No code that operates via the superclass interface can do anything with something() due to the lack of this interface. The code requires direct knowledge of the derivative class, which has completely defeated the purpose of defining something() at the superclass level. I will concede one point though, a "must implement" will indeed provide a good set of clues as to what derivative classes should be doing. However I feel the inability to enforce anything beyond the mere existence of something with a given name means these hints really don't belong in code in my opinion.

There is a very small book that I like to recommend to people. It is the best general programming teaching tool for OO that I know of: http://www.amazon.com/Object-Oriented-Thought-Process-Matt-Weisfeld/dp/0672330164

I would say, yes, you should demote it to a mere library (although, since it already is a mere library -- because a class inherits from a library and thus fulfills the "is a" relationship -- it might be better to say "only a library"). If the situation is as you describe, then the functions are just a collection of VIs. Creating a data type and then not using it is just wasting system resources, however small they might be. And, implied in that, I would not have Object In and Object Out terminals. What would be the point? If you wired them, all you would be doing is creating false data dependencies between functions. Now, having said all that ,before you actually build the new library, I'd pause a while and ask, "Am I absolutely certain that these functions belong together at all? What data *are* these functions operating on? Should they be packaged with whatever class represents that data?" Maybe they really are math operations or string utilities, but I don't see many programmers creating large libraries of those.