ShaunR

Indeed. But our topologies (and philosophies) are entirely different. Ahhh. I see what your getting at now. Yes. they will be different because you have to redraw more data, more of the control and more often.. It's well known that redraws are expensive (put a control over your graph or make them all twice as large and see what happens). And it is not just Labview. The major difference is in what and how much has to be updated. If you (for example) turn off the scaling (visibility) and keep the data-window the same size, you will see that the CPU use drops a little when it is scrolling. Presumably this is because it is no longer has to redraw the entire control; only the data window (just guessing). You are much better off updating a graphical display in "chunks" so you need to refresh less often. After all, its only to give the user something to look at whilst drinking coffee Humans can only process so much graphical data (and only so much data can be represented due to pixel size) so there is no need to show every data point of a 10,000 point graph. It's meaningless- It just looks like noise! But I bet you want the user to be able to zoom in and out eh?

Probably. I don't use un-named queues since I have a single VI that wraps the queue primitives and ensures there are no resource leaks (and I don't like all the wires going everywhere ) Are you still getting differences in the graphs? When I run your example, I see no difference in CPU usage between scrolling and not (~5-10%) although I haven't looked at all the "Questions"

I think so. Yes the bottom loop is free-running. Put an indicator on the front panel wired to the difference between 2 "GetTickCount" VIs. You will see that it is pretty much "0". You are in fact putting all the data onto 1 un-named queue. So, every 3 ms you are adding 4 lots of data, but you don't know which order the bottom de-queues execute in or, indeed, which order they were originally placed (but that's another issue). Your time-out is is exactly the same (3 ms) so if there are 4 pieces of data on the queue, then everything is fine. However this is unlikely since the producer and consumer are not synchronised. If a timeout occurs; you still increment your counter so, due to jitter, sometimes you are reading data, and sometimes you are just timing out.....but.... you still only display the data (and add it to the history) in case 19. And although you will read it next time around, you don't know on which graph it will be. You have a race condition between data arriving and timing out. Does that make sense?

Not quite.. Here are the licensing options. They are quite clear.

Haven't had time to go into all the above. But have noticed that your bottom loop (dequeue) is free running (0ms between iterations). I get a very stuttery update (just ran it straight out of the box). Changing the time-out (deleting the local and hard-wiring) to, say 100ms, and everything is happy and the dequeue loop updates at 3ms. I imagine there's a shed-load of some time-outs going on which is causing you to miss updates (not sure of the mechanism at the moment)..

Datatypes in SQLite Version 3 If you give me a a specific example of what you mean. Maybe I can help more (but read the link first)

I've never found an easy way to do do this programmatically within LV. I use one of two techniques. 1. Create a function in the DLL called Get_Ver which will return the the dll version and LV version used (I don't use this much any more) 2. When you build the dll, put the LV version in the description section. It won't help you for the current DLL. But you shouldn't have a problem in the future.

Sin? Noooo. But this is an interesting one. It will fit on 1 screen. Just do a "Clean Up Diagram" with shorter variable names and you're pretty much there. But that's not the interesting bit There is a large number of operations that are identical. Identical operations easily be encapsulated into sub-vis. This not only shrinks your diagram, but also segments it into easy to digest chunks of code. Consider this piece of code.... this is replicated no less that 6 times. I would be tempted to do something like this : It achieves several benedits. 1. it is more compact 2. It is easier to identify repeated functions.. 3. It reduces wiring errors 4. It gives more control (you can, for example make it a "Subroutine" for faster execution) 5. You can re-use it . There are many more places within this piece of code where it could benefit from sub-vis. The net result would be that it will probably fit on 1/4 of a screen and be a lot easier to read/maintain. There are also a few areas that would benefit from "For Loops" too.

Because classes aren't very friendly? I would imagine it's because a class is an entity and you access that entities data through methods and properties by exposing them to a greater or lesser extent (I think of it like a box with buttons and indicators on it). As such your interface boundary is the "class" so you are in fact saying that the Method B should be able to poke a couple of wires behind the buttons and indicators when all Method B can do is press the buttons and read the indicators. But then again. I usually over-simplify things there's probably a more technical explanation.

You can use "REPLACE" which will "INSERT" if it doesn't exist or, "DELETE" the old record and then "INSERT" if it does.

Queues are good for this sort of thing. they give you inherent FIFO sequencing. You can use the "Event" structure to place the controls' refnum on the queue then replicate the changes by emptying the queue.

Indeed. You can. When you edit the pallet menus, there is an option (right click on the VI) to "Place Vi Contents". I you create a VI and set this value, the contents of the VI will be placed in the diagram instead of the icon. lol. JGCode is a faster typist than I

I don't think they are any more painful than, say, queues or notifiers. My only gripe is that there aren't more built-in ones.(but that's something different).

Sweet. I'll update it for the next release.

An elegant solution . That's going in my snippets draw.

What's wrong with using "File>>Save For Previous Version"?

OK. Definitive answer. Change the "SQLite Read Blob.vi" moveblock call to "LabVIEW" (note the case...it matters!) instead of "labview.exe" or "lvrt" Let me know if it fixes your issue and I'll add it to the API library.

Hmmm. This could potentially be a nasty one Open the SQLite project and Find "SQLite Read Blob.vi" Open the "MoveBlock" call library node and change it from "Labview.exe" to "lvrt" Click "OK" If it starts to search for the dll, Help it by browsing to your "/program files / national instruments / shared / Labview Run-Time / [your version] directory and selecting "lvrt.dll". Save the vi and the project. You should now be able to open your project and build the app. It may ask you again to find the lvrt.dll. If it does, so the same "browse" again as the above. I can put in a switch to detect the change between run-time and dev, but if its not automagically picking up the run-time dll, this will cause a huge headache in multiple version systems. I'll look more closely into this, but the above should enable you to build your app until I find a better solution.

www.ni.info is available

You're right. In my quick scan of the examples I assumed that identifying which ones had changed was also a requirement. If it's only the number then it should count them OK.

You can use the "Order BY" in the where clause. e.g Note that you have to have a where statement of some description so you can use RowID>0 to return all rows in a table if you have no "Where" constraint.

It beats the cr@p out of Labview for web services But my response was to the question "what other languages do you use".

Because his example only updates and checks when there is a change in data. Your version (without the event case) continuously evaluates the difference between the current and previous values so you miss the change. By the time you press the stop button, the previous and current values are the same (although different from the starting values) therefore you don't detect a difference.

Not any more