ShaunR

You need an excuse? I thought it was our nature to play with this sort of stuff Keep it in your palette and I'm sure you'll think of something.

If you mean when there is an error condition you are getting an error dialogue when you shouldn't be, then you probably have an unwired error out cluster (or none at all) and "Enable Automatic Error Handling" is set in the offending vis "Execution" properties.

Possibly. This release basically does a "GetRow" and has to iterate for each row. There is another method, but it isn't implemented yet. (Still trying to figure out how to do it....if it is possible in LV). Do you have a real-time target that uses ETS?

Its not the number of statements. Its the number of "TRANSACTIONS". When you use the "INSERT" VI in a for loop, each iteration is 1 transaction. Additionally, the insert vi opens the file before the transaction and closes it afterwards for a slightly safer implementation. The insert is for convenience and a bit more safety. If you want blistering speed. You need to use the "transaction query.vi". this will wrap your Insert statements in the "BEGIN...END" and execute all the statements as 1 transaction. With the test below. I achieved 10,000 inserts in 609 ms.

You are not generating an event. I've had a play and it seems that the panel close event isn't really an "OnPanelClose". It is only an event generated by clicking the close button. That's not really what you are after. To also include a boolean you would have to attach to the on-value as well.....too much effort. Might as well put an event after the while loop. Back to the drawing board I never had a lot of luck with it (maybe because I don't fully understand it). But sometimes it worked, sometimes it didn't.

The example does, yes. Because you don't know what controls maybe on the front panel. But ALL vis have a generic on-close event So don't need to know anything about the sub VI. You just inspect the reference when the event comes in to find out which VI closed. So the install callback just becomes: Haven't been through it thoroughly and perhaps not as "clean" as you would like (I suspect you were expecting to just select it with 0 programming). But better than nothing eh?

The example does, yes. Because you don't know what controls maybe on the front panel. But ALL vis have a generic on-close event So don't need to know anything about the sub VI. You just inspect the reference when the event comes in to find out which VI closed. So the install callback just becomes: Haven't been through it thoroughly and perhaps not as "clean" as you would like (I suspect you were expecting to just select it with 0 programming). But better than nothing eh? Oppps. Posted on wrong thread...lol.

You can attach your own "user event" on launch by using a callback function. I've only ever used it to hook the other VIs front panel controls' events, but it should be possible to hook the on-close event. You are still generating a User Event, but as the callback is attached to any VIs you launch yo'd only have to do it once, and you wouldn't have to write any code in the VI your are trying to hook. Callbacks

Check the "VI's in memory" list?

Can't wait for the Labview version of Halo

Name: SQLite API Submitter: ShaunR Submitted: 05 Oct 2010 File Updated: 05 Jan 2011 Category: Database & File IO LabVIEW Version: 2009 License Type: Other (included with download) SQLIte API This LAVA Code Repository Download is no longer distributed or supported by LAVA. Please follow this link for further support. Description: This is a Labview API wrapper for the SQLite dll. From the authors of SQLite: "SQLite is a in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. The code for SQLite is in the public domain and is thus free for use for any purpose, commercial or private". More information can be found on the SQLite website http://www.sqlite.org. The LabView API contains all the basic SQLite features but it is not a full implementation. However, it is comprehensive enough to satisfy most application requirements for a databse enabled application and the featurelist will grow with each new release. Currently supported features include: Creating, deleting, listing and renaming tables and columns. Selecting, inserting, updating and deleting records. Retrieving SQLite system informaion. "Onlne" database backup. "On Insert", "On Delete" and "On Update" Triggers. File Import. Query Saving. Installation: Unzip to a directory of your choice. Install the pallet menu file (.mnu) provided. Required Packages: Labview (Win x32, x64,) 9.0 or greater. SQLite DLL (Included). Supported Environments. Windows x32, x64 Known Issues. Cannot use semicolons ";" in values when using "Query Transaction" polymorphic instance. Workaround: Replace semicolons with another character (e.g. tilda "~") or use the standard "Query" or "Query By Ref" VIs. Versioning: Current version 1.2.1 New Feature: Added "Conflict Clause" to SQLite_Insert and SQLite_Insert Table.vi (allow replace, fail ect) Performance: Changed "SQLite_Prepare.vi" and "SQLite_Bind.vi" to pass data as a U8 array rather than string. Performance: Changed "Insert" (SQLite_Insert Row.vi) to use "Insert Table". (All inserts now use prepared statements. Performance: Changed some low level VIs to re-entrant for better concurrency. Bug Fix: Changed all polymorphic API VIs to show instance icon. (some context help for VI was not being displayed when set to polymorphic VIs' icon) Bug Fix: Exposed "Distinct" boolean on "SQLite_Select.vi". (No terminal on compane). Bug Fix: Replaced some cursor "Unset Busy" with "Set Busy" in SQLite DB Manager. Bug Fix: Changed "SQLite_Bind.vi" to force sqlite dll to use local copy of data. (Fixes reported bug in LVx32 insering the same data in multiple columns). Changes: Changed icon on "Insert Table" to make more visually discerning from "Insert". Version 1.2.0.0 See changelog.txt. Special Thanks to Gepponline MattW Contact: PM ShaunR on lavag.org (http://www.lavag.org) This LAVA Code Repository Download is no longer distributed or supported by LAVA. Please follow this link for further support.

If it is full blown implementation then it is a lot of work. I think, however, most people only need/use the basics. I just hope its not ADO or .NET.

I assume its an offshoot from their embedded tool kits (you can't run LV on for example an ARM processor). where you write stuff in LV and it generates the C code which you then have to compile using a C compiler. The other way round would be awesome.

Can't wait for the JKI Virus Scanner

For the sensor, I'd probably go for something like this. USB to rs232 lead to get it into the PC and there are pre-shipped examples for serial comms in LV. Only £20 too Ultrasonic devices work much better than light devices outdoors and are not as susceptible to things like dust and dirt.

Do we get cake?

Where can I buy one of those buttons? And does it come with LV drivers?

So what are you trying to say Cat eh?

$5,771.42 For that price I'd expect it to take out scud missiles from 10 km

Labview is designed for interfacing to sensors. What is your budget? How much time do you have? Can you build simple or complex electronic kits? Can you program micro controllers? Can you use a multi-meter? Don't be frightened by the questions. I'm just trying to get an idea of your skills.

I believe 6.0.2 is the one shipped with LV2010. Its for versions 8.6 and above.

I have 3 machines at home. 2 are x64 1 is x32. One of the x64s has both x32 and x64 labview. I don't have any problems switching between OSs or labview. But there are some things to bear in mind. 32 bit dlls will work on a 64 bit machine, but you can't use LVx64 (must use LVx32t) x64 dlls won't work at all on a 32bit OS. (you will get load errors if you try to use LVx32 to load them). Likewise 64bit applications written in LV will not work on a x32 machine. LV must recompile between x32 and x64 every-time you load (the whole hierarchy) which might be a bit of a nightmare for your source control if switching to and fro. Editing with LVx64 on a x64 OS is like lightning. LVx32 runs like a slug. Anything pure labview (like scripting) is totlay interchangeable. Install BOTH

Indeed. It was a quick demonstration of a theory rather than a solution. If you change it like so...... Then you get unique intersection values for example. Sweet. that'd be even faster

I thought I'd seen this problem bedore Here is another method that's similar to your first one rather than the second. This VI (wrote it a while ago now) returns the array differences but the theory is the same. Slightly different in that it actually does a search and eliminates data, therefore reducing the data set as it goes. Its very quick especially if the duplicates are sparse and isn't explicitly linked to the data-set size, rather the number of duplicates.