ShaunR

Use the OpenG variant config to save the clusters to a normal ini-file then run this on it (you might want a little more error checking). Split-Ini.vi

Edit: Yes. What Phillip said.

I concur. Make sure you get the GUI which is separate (Inno Setup is the script engine).

Well. The ant-pedant in me ( ) would qualify that in respect to it is inherently secure at the application boundary. There is no software defence for a post-it note of the password on the monitor. Copying is not an issue, per se. It is the clearing of the memory locations and I don't know either way if LabVIEw does that. It is, however, swings and roundabouts since the key has to exist at some moment in time, in memory, so it is a case of reducing the persistence so that capturing at exactly the right moment on random off-chance is unlikely (not impossible, just unlikely). Of course. If there is zero cleanup, the keys can still exist for quite some time even after the application has terminated making them much easier to capture (until the OS decides it needs it for something else). So LabVIEW probably doesn't score well on that front. But more generally you get more bang for your buck by defending the edge (application/OS/network/buliding) and reducing the opportunities and attack vectors rather than trying to mitigate aspects that require enormous effort and skill levels to make the attack effective. Saying that. The SQLite API does clear all its keys immediately after use, but that's not a lot of consolation if LabVIEW holds on to the un-hashed password string like a drowning man to a buoy Probably the best you could hope for is that LabVIEW clears its memory when it exits so then at least an attacker would have to have the software running after you have entered the password. However, if your secret data is so secret that you are worried about determined adversaries getting the keys from memory, it is better that they just don't get to run your software at all (lock the office door).

It depends who you think your adversary is and what they will have access to. You should never "store" a key, rather let the user enter it - that is the only secure way. So when I'm encrypting a file, I never store the key (well, you could argue it is "stored" in memory, but that is transient and a whole subject in and of itself). Many apps will store something in a file so that users don't have to keep entering the info. This should never be plain text, rather a hash of the password or the password with other stuff combined (SHA256 or SHA512 are quite common-don't use MD5), but this assumes the adversary will either not have access to that hash or will not be able to hook into the software where the key is used if they do get their hands on it. It's more of a case of "security through obscurity" than "secure".since whilst they may not be able to recover the original plain text directly, they may be able to inject the key, look it up on a public database or use it at some point in the applications process space. When used in this way, the key will usually be the result of not only the password, but the password combined with a salt. This, in essence is just another obscurity layer but means that two pieces of information are now required to reconstitute the original. It will, however, be for naught if they are both stored in the same place (a website, for example will store the hash in the DB, but the salt in a file). Software is a tricky beast since if a competent adversary has access to the machine, then all bets are off!.It's just a matter of time, persistence and budget.

oooooh, that was a long time ago now. I'll see if I can dig it out

LV 2010 2013 = 13008000 2012 = 12008000 2011 = 11008000 2010 = 10008000 2009 = 9008000

Hmm. The quick reply seems to screw things up. Here they are again: Websocket demo Examples

Websockets were created to resolve this sort of problem since browsers do not allow incoming connections (websockets create a bi-directional TCPIP connection). Some of what you describe is a little confusing to me since you talk about "discovery" and "polling" but that has little to do with TCPIP since you must know the IP address and labview isn't event driven (so must poll). You can try it and see if websockets do what you need by running the demo on the server and using your browser to .connect ala these examples. When you have installed the Demo on the server, just navigate to the examples website and change the IP address in the example pages for that of your server.

The fix has already been pushed to bitbucket. The others will review it then, if it's acceptable, drjdpowell will fold in any other changes and build a VIP package for the CR (only he can update the CR).

Answered in the Support thread.

Added Path case to "Variant To JSON.vi" and updated example. (See this post) Variant To JSON.vi Example JSON Variant Tools.vi Because the intention is (was?) to remove OpenG dependencies completely...

It's not a complete replacement, though, is it? I think this algo can fail with certain numbers so you'd have to fall-back to the printf and incur the overhead of running two in series. Maybe those numbers cropping up are statistically insignificant though.

Looks great. I get the following error when trying to download the free version (after entering details).

Wrong. Your specification actually states: TDMS is not a "fully featured" database system. None of this is "easy" in LabVIEW. 1. LabVIEW doesn't support QR codes. There are some threads on this forum for some 3rd party solutions 2. You will not find an "off the shelf" solution as this is a specific requirement that many would outsource - you will have to write it.. 3. If you have the Database Connectivity Toolkit - use that (you probably do as you are a student). 4. If you don't have the Database Connectivity Toolkit - use SQLite. 5. You will have to learn SQL.

Check the VI Server: TCP/IP Access permissions.

Just to expand.......... TDMs is a flat-file database. Basically a data table with a look-up table (by name, index etc) with no relationship between entries .MySQL, Postgres, SQLite et. al. are relational databases. A simple way to decide which is preferable for your requirements is to think about what questions you want to ask of the DB. : If you just need to look up data based on a single criteria, e.g. channel names. Then TDMS.. If you need to ask "open" questions such as "How many", "What has" or "When did". Then relational database.

I think the only person that could help is probably AQ. It's been known for some time that LVOOP takes a long time to compile (I have commented before to those that think hours to compile is acceptable). However. I actively avoid LVOOP so my experience is limited for applications. Some might say I have softened a little since I do on occasion use it for trivial APIs to save connectors. The kind of advice I would proffer would involve converting to classical LabVIEW. I expect that isn't an option for you, though, if your whole architecture is OO.. There was some discussion a while back about mutation history getting very large and bogging down load times. Daklu was moaning about it; I believe. You might try and find it on this forum (I couldn't after a cursory look) and try experimenting with deleting the mutation history (see the conclusion and make sure you have backed everything up) for a class or two and see if things improve. But that's just a wild stab in the dark.

They have identical issues to removing diagrams from VIs. i.e. not cross platform or cross CPU arch.For most developers that create tool-kits, utilities or reusable components that are distributed to other devs; they are not a good choice. If you only have one product and only ever use one OS of a single bitness and that will always be the case then that's fine. - welcome to Labviews version of DLL hell I personally avoid them like the plague-little upside, huge downside. A LLB is superior IMO. However. In your case. I can't help but feel the only reason you are considering them is through desperation - to cure the symptom of a much deeper problem.

You already have the code-it is shipped with LabVIEW

I've never used "Data Finder" but I just load csv files into a SQLite DB. The SQLite API for LabVIEW has a VI to do this for you, but you can do it yourself and once in there, it just boils down to how you want to view the info using queries.

Yes. See the "Noise Statistics.vi" or "Probability Density Function Estimation.vi" in the LabVIEW example Finder.

Search the labview examples for "Histogram"

Just a bit slow, that's all

Crypto-G Project Probe Windows API