ShaunR

Car analogies are disingenuous. You buy a car and ownership is transferred via a document with a signature. With software you buy it but you don't own it! You buy the right to use it.

That's not a "crime". It (the EULA) is a civil offense and last I heard, lying wasn't a crime unless you were in a court under oath. The war that's raging about whether pirating/copying is stealing will not be resolved on forums and, I don't think it will even be resolved in courts (as bizarre as it may sound). The argument on one-side is that an "opportunity" has been denied and needs to be recompensed to the amount that "could" have been obtained. The argument on the other; that an "opportunity" has no value, cannot be proven and cannot be "stealing" since it was never realised or owned. Which side you sit on depends a lot on your world view and whether you prize cooperation over ownership. One is a communal view, while the other is feudal. History tells us that they are generally orthogonal and each rises to be the "norm" at various times. Again. Historically, cooperation has been the most common and invariably when the greatest leaps in human progress occur. Might I suggest we move all these to the "Licencing" thread where they belong?

I'd use normal VI sequencing and dynamically launch it. If you want to stop it just Abort/close the VI. Quite often there will be a "controller" to launch/abort which the rest of the system messages to, effectively making it a module with an API.

I don't think we are being hard. Just providing fair warning. It's not us he needs to worry about Licence 出る杭は打たれる。

Indeed. So you only have to write a LV implementation of ripemd160, secp256k1 and a base 58 encoder and you can claim some bitcoins

Well. On a slightly more esoteric point. You say in the OP that that it is like a local variable. Here you are talking about a single VI. I think you need to define the context of what you think a VI represents. For example. you can have multiple methods in other languages and they do not require a single file per property/method.to access the storage In labview you must have a VI (file) per method/properties that you wish to manipulate from the cluster (storage). Taking my previous statement about "static". In other languages I could put a static variable in one of the methods to count the number of times that method/function had been called. This would translate (I think) into a single VI method with local (to that VI) storage outside the purview of the cluster (i.e. only accessable inside the function but could be exposed via a terminal of that VI - the return value in other languages). Is this a similar scenario to what you are describing here? Or am I really out there in my understanding?

5 BTC competition - LabVIEW app to get address from private key Source

It was in response to your comment on protected (should be flogged etc). It is stating that private (generally) is not a "good" thing IMO for the fore-mentioned reasons. You are wishing to make fields "uber private". If that is off-topic then so is Jacks. What you don't get is that I do use OOP extensively. I use it in PHP and delphi. I just don't like it in LV. So I am a little bemused that my thoughts invalidate any comment because I'm a classical LV programmer.. So back to "Any proposals for utility for private-to-one-VI fields of an object?"., Yeah. If you're going to do it (I can't see a use case apart from bringing it in to line with other languages in the same sense I can't see the need for a static equivalent). Make them protected not private or give us a choice how to scope them with protected being an option!

Accessors, fields, data or lemons. It doesn't matter. The point I was trying to make is that if a user wants to modify/abuse my code to get the desired behaviour; they should be able to without editing it. By making it a protected rather than private lemon, they can and is making a conscious decision to do so by writing additional code rather than messing with mine. 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.

Community scope. Meh. Still don't really understand what that is for. However. Protected? I don't desire it. I demand it. In other languages I never declare "private". I always declare "Protected". The reasoning goes like this....... If someone is going to use my class then it must do what they want it to do (not necessarily what I think they might want to do or what I have designed it to do). If I declare a private function.(or variable for that matter) then I am denying them the option to make it work the way they want it (and don't talk to me about "FINAL"). However. Regardless of me making it private, they will hack the class to bend it do their will and, ultimately, modify my code (which I have spent a lot of time testing). At this point we get into arguments since the onus is always on the supplier to prove that the problem isn't with their code.when things go wrong. Eventually you figure out they have hacked it and you get into the ....... "You shouldn't have modified it because.....I modified it because.... You modified it therefore I'm not fixing your code" .... ad nauseam. Declaring as "Protected", however, does not deny them the opportunity of modifying the bahaviour of my class and, more importantly, if they want to modify it to bend to their will; can inherit and not trash my clean and tested code to do it (we'll ignore the fact you also end up with multiple variants of subtly different code). Sure, they can break the functionality that I have carefully considered. But that is a problem with their code, not mine and I can prove it by making them go back to the original without overrides/extends etc. If they then say that they modified it. I can tell them they should have overridden so go away and try again.

Thanks for the detailed explanation. I avoid.NET a (and ActiveX) like the plague, so I was taking pot shot at a path issue. Added to my list of "reasons (excuses) not to use .NET"

Do you still have the same issue if you put the assembly in the system32 folder?

Interviewer#3 :So, do you have an exact itinerary of where you will drive and park? Me: Yes I do. Interviewer#3 : Can I see it? Me : Of course. Do you have signatory authority to sign this non-disclosure agreement? Interviewer#3 : No. Me : Then perhaps I need to speak with someone who does. I can only give you that information if you sign the agreement.

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

Yup. Except that it's not just the "ability to require implementation" currently, is it?. It's the ability to require implementation with identical arguments. I could re-architect so that the dummies weren't required. In fact, I did start out on that route. What you are seeing is "after" refactoring where I reduced the codebase for that part of the system by 65% and removed 3 supporting classes in complexity. So I have made the conscious decision to trash the "proper" architecture . I don't care how "correct" an architecture is if it bloats my code by that much just to fulfill some sort of feigned righteousness. It would be more elegant and compact still, if I could get rid of the dummies too (hence my interest;) )

"Read" Nope. It's not as effervescent as that in this case. I care not for architectural astronautics The override is used because of "re-use" and to avoid code replication which is not a pre-requisit for override which is generally used either to modify the object or as a placeholder. The override enables me to put operations that are identical in all the child classes (error translation for example) into a single location. The dynamic dispatch is still, however, required as the child (in the example, the protocol) is still determined at run-time. This is no different from the parent calling the "Read" from within a case-statement (where each case is a different protocol) and then carrying on to process the result of the call. However, with the case statement scenario I could indeed have different terminals for each protocol.

.......it creates a shedload of code that you have to maintain

I mentioned PHP because it is one I'm fairly competent in rather than as a reference to your examples. My grammar is shocking sometimes I'm actually forever [intentionally] circumventing LabVIEWs type safety. It was useful to stop me shooting myself in the foot when I was many moons younger but as the grey hairs rampage to my neck-line (and lower) I've come to view it more as a hindrance than a feature. I expect if you took it away I'd also bitch about that too , but it does sometimes prevent some truly elegant solutions and compact generic code. Variants (the feature that never was...lol) aren't really the same as variable length argument lists. I consider that the com-pane is the labview equivalent of a function prototype (one terminal for each argument). I have been down the route of just having a single variant input instead of a number of terminals, but the amount of code you have to write and tricks you have to pull to make it useful, is just not worth it. Readability also becomes non existent. I'd rather have someone elses cake and eat mine

Well. I think you mentioned something earlier about varArgs and PHP (which admittedly may be easier because it is interpreted at run-time) has the capability to accept variable length arguments (func_get_args). Like most of these sorts of things, I don't care how it's implemented; that's not my job. However, it would be nice if it did.

IC. I have actually come across this instance before where it was frustrating that I couldn't have different terminals for an override. It forced me to have "dummy" terminals which were only functional in certain overrides which (to my mind) was unnecessarily confusing and meant more documentation. . (I didn't use LVPOOP because I wasn't talking about LV )

You can't win an emotional argument with logic!

That's the "She was asking for it" argument and says it all really!

Indeed. However removing diagrams is a maintenance nightmare if you are providing cross-platform, multi-version support. I use the password protection on the installer for the SQLite API For LabVIEW. Mainly to hide the mess underneath , but also because it's actually another development (a "Wizard Creator") that was co-opted very early in it's development to be used as a quick and dirty installer and can be a bit pedantic when fiddled with. If someone hacks that, it's just a testament to their character rather than a serious commercial implication for me. The API itself (the real software) is open source and relies on the "honor" system for purchasing which most of the LV community have the integrity to adhere to. However. If I had tried to make the installer "source-less" I would have ended up with 8 installers (and counting) just for windows let alone the other OSs.

Haven't read the whole thread (i.e the replies) as yet so might be going off half-cocked (as per usual). But is this definition (Must implement) just another name for abstract? Reference