ShaunR

I paste code snippets from C, ini files and SQL on the diagram so, # isn't a good choice for me. Not saying you can't. Just saying it's an arbitrary choice what to use as an identifier and this particular one has drawbacks (and you can't change it). Using the built in system won't get me any benefits. In fact it will limit it's use to LV2013+ (I use 2009 by choice). Besides, PP doesn't just do tags. You can also see if VIs have default icons, are broken,descriptions and history filled out, FP hints, descriptions etc. Tags are just a small part. and everything else requires opening the VI anyway.

Hashes are not a good choice as people use it as a shortcut for "number" or "hash" and it adds noise to the listings. The "tags" are definable in the PP, so you can use what you like but they have to be enclosed (tag), [tag], (my favourite) ~tag~, #tag# etc. But you could have #tags (methinks there are too many twitterers - or is that twits - at NI) Additionally you can assign different tags, different meanings. For example I use [tag] as "Requirements" (ala the NI requirements thingy) for calculation requirements coverage. I really must get around to productionising it. It's the "help" document that's putting me off as it will be huge due to the features, which are easy to use, but take a lot of words to explain-like the plug-in system and custom queries.

Hi SDietrich It seems the libpq.dll has a load of other dependencies. When loading, it couldn't find libintl.dll. Looking at the website, the binary download is 44 MB so there are a few more than just libintl.dll. I downloaded the zip and there were a few wxwidgets DLLs that you probably don't need, but there were the libeay, zip and a few other binaries (including libintl.dll). For an out-of-the-box experience, some of those will need to be bundled too.

Simplest way is to use vbscript to press buttons on the FP.

Maybe create it as a plugin filter for Bitman. I always found Vugies Bitman is far superior in rendering performance for anything I do in 2D.

Hi SDietrich. The DLL isn't in the package so I couldn't check, but I looked at the CFLNs and they are set to re-entrant. So did you compile with "--enable-thread-safety"? (otherwise it will have to be run in the UI thread). A note in the description of exactly what platforms/labview versions you are supporting would also be useful (Windows, Linux, Mac, VxWorks etc) For Windows users it would also be of benefit if you say whether you are supplying just the 32 bit or both 32 bit and 64 bit DLL (LabVIEW x64 cannot load 32 bit binaries and vice versa). jgcode is the Lavag Tools Network admin. Send him a PM and he can advise on how to get it on the tools network under the Lavag banner.

The scene object has anti-aliasing which is used in the 3D Graph Controls. Create a scene object and select "Specials>Anti-aliasing"

I think the OpenG Scan Variant From String is obsolete since JSON to Variant can handle all types now (apart from refnum and path-which are easily added). We should consider removing the OpenG Scan Variant From String completely. I would also suggest that for the unknown data type we output a string type and raise a warning rather than an error..

So that's a no then-there is no equivalent (I also couldn't find one listed). You have to write a wrapper whether your choice is DLL or .NET assembly.

Labview has no way to create callbacks that can be called from external code (the exception being some .NET functions). You need to create a dll wrapper that supplies the callback function and proxy it via a LV prototype (e.g. an event using PostLVUserEvent) which can then be used to get the callback data. If there is an equivalent .NET function, you maybe able to use the callback primitive in the .NET pallet to interface to it.

If you are as impressed with Inno Setup as I am (couldn't live without it). you might consider a donation.

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.