ShaunR

Indeed. So you are getting the status directly from the device as and when you need it rather than "remembering" state in the software. It doesn't matter what the method of transmission through the software is (actors, events, queues, notifiers or whatever-a good point to again whinge about not being able to hook up VISA refs to the event structure ).

Unless your hardware uses push streaming (rare as rocking-horse droppings). The hardware cannot tell the UI since it will be CMD->RESP.

To paraphrase Hoover............ With a stop button only. If you click the X button on the form (as users have been trained to do). Your panel will disappear (so can't get to the stop button) but your VI will still be running.

Google is your friend But looking at the javascript source here should help you out As for ranges. Well. They key is to convert your measured frequency to numbers of semitones from a base frequency. You are not counting in frequency, rather, semitones so round up or down fractions of semitones/crotchets/quavers/lemons/whatever (just be consistent). @Hoover. Glad I don't work for you.lol.

Well. The case statement is looking a bit unwieldy. You can take advantage of the fact that an octave is 2^n of the fundamental and a semitone is the 12th root of 2 (or about 1.059)since you are only interested in the fundamental frequency. Then you should be able to calculate directly and represent it as a bit pattern.

Having dealt a lot with hardware systems. There were a few conclusions I cam to quite a few years ago.That is that with hardware settings, you should always rely on the device to tell you what you can and can't do. If you start restricting user input values before sending to the device, you very quickly end up trying to replicate the device logic which can get very complex. With this in mind, it becomes just a case of setting max/min values to the controls. Additionally, most modern devices give readable error responses, so usually you only need to bubble them back to the UI. Similarly. When it comes to device state. You should not try and maintain it in the software, rather, interrogate any state information as and when you need it. Maintaining device state in the software will vastly over complicate your code and lead to hard-to-debug disparities between the actual device state and that of your software. This situation is totally avoidable and means that very simple recovery procedures can be facilitated without complex code and the code can reflect state without logic. If you bear in mind these "rules-of-thumb". You devices will do all the hard-work and greatly simplify your code as well as being far more robust.

I've always rolled my own. However. I've heard some good things about this one but from C# programmers rather than labview (they have an eval kit).

You looking for "off-the-shelf" or "roll-your-own"?

Well. Leaving aside the economic arguments for now..... The big thing about bitcoin is there is no centralised accountancy, it is almost an instantaneous peer-to-peer transfer. And it is extremely hard to trace (anonymity). A few years ago you might argue that the latter was only a benefit to criminals. With current events (SOPA, Snoopers Charter et. al.) many ordinary folk feel that they need to protect their privacy. Many economies are also being sucked dry by corporate interests and other monetary systems have arisen to combat this so people are looking for alternative strategies. Bitcoins are gaining popularity mainly because of these two points and you could say it's filling a need at the right time. Bitcoins obtain their "value" from scarcity (limited maximum number of 21 x 10^6) and by the energy consumed in generating them (electricity to run a bitcoin miner). There are a couple of bitcoin "exchanges" where you can convert bitcoins to fiat which is probably a more understandable, although flawed, measure of value (as of writing 1 bitcoin~= 14 Euros). ...... But on to the interesting stuff ...... Bitcoins are "mined" (that's the terminology) just as resources (like gold) are. Instead of digging a hole, however, a computationally expensive algorithm (a hash) is used by a Bitcoin Miner. This is synonymous with password "cracking" in computational terms, but the intent is quite different. Whilst in the early days you could mine with a fairly low spec PC. The "difficulty" has progressed to the point where you now need dedicated hardware-usually racks of GPUs in the 10s of Giga-hashes per second. (This has led to an argument that early adopters gain a significant wealth advantage, but let's stick to the interesting stuff ) The design of the bitcoin system is such that there is a maximum of 21 million that can ever be created (currently there are approximately 10M in circulation). A bitcoin itself is just a history of transactions (the block chain) from the "base" bitcoin block and the difficulty in "cracking" the hash changes in relation to the rate at which bitcoins are mined. (I should also point out that bitcoins are not mined singularly, but in batches). The number of coins in the batch (currently 50 at this time) also reduces as more bitcoins are mined meaning that the cost/BC (electricity consumed) increases with more bitcoins in circulation. You can get a more concise overview here. Suffice to say. On the surface it looks fairly straightforward (just money, right?) but the deeper you go, the more you realise just how much thought has gone into the system and how technically elegant it is (and not a banker in sight!). I can see a couple of issues that need to be resolved (bitcoins can be destroyed but not recreated and defence against a party taking over 50% of the network). But it does look very promising and certainly has gained the attention of the authorities.

I thought you would have finished it by now

Well. We are so OT.........what the hell:

Another alternative:

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.