Leaderboard

LabVIEW Wiki: We've updated the LabVIEW Wiki to the latest MediaWiki supported version (1.16). Changed the skin to the latest one which is also used on Wikipedia and MediaWiki. It's very clean and modern. Added a reCAPTCHA extension to trap bot registrations. Also added a bunch of other extensions to hopefully reduce spam pages which we've been getting lately. Removed the wysiwyg editor because it was adding bad formatting to pages. Replaced the editor with the new one used on MediaWiki and Wikipedia. It's better than the plain wikitext editor and has some cool help features built-in to assist with editing when you forget the syntax. LAVA Code Repository (CR): Updated to the latest version which adds a bunch of cool features: New imroved landing page. Which highlights code better and allows for "Featured" main entry. Built in version number feature. Now, there is a built-in feature for version numbers. Before we had to add a custom field for this. We are slowly deprecating the use of the old field. New Changelog feature. Now there is a field for changelogs. So with every new version of your file, you can fill in the changelog and LAVA CR keeps track of it. No need to put his in your description section anymore. It also gives you a summary page with a complete changelog history. Old feature but worth mentioning: You can submit multiple files. When the user clicks the download button, they are presented with an option to download one or more files associated with your submission. With this version, we now have the ability to provide free or paid tools on LAVA. If anyone is interested in selling their tools. please send an email to support@lavag.org. In addition to the above changes, the LAVA team is always tweaking and adjusting things behind the scenes to make your stay here more enjoyable. As always, we welcome feedback.

Thanks Priscilla I'm not really sure what you have in mind here. Maybe your current VBA application is sequential because the operations are indeed sequential (no point re-indexing a table before you delete a load of rows for example). I think generally speaking though, that any move away from VBA (and definitely away from Access ) will have performance benefits with the caveat that there are not many interfaces to Access that would be more efficient than the interface between VBA and the DB (I assume your using VBA within Access). With databases, just running more threads of the same process doesn't equal better performance (a thread will stall if a table is locked by another thread), but moving away would enable you to optimise your queries and give you greater control over those functions that can be executed simultaneously. Perhaps a better short-term route might be to look at Visual Basic since you will be able to more easily port existing code (CopyPasta with Hacksauce) whilst being able to assess what functions can be realised asynchronously. In addition, you will be running compiled code rather than interpreted (I think VBA is interpreted at least) and you will be able to see more easily how and where the software is idling; waiting for the database to complete. Many people just go for a text file with the SQL and squirt the SQL direct using PassThrough to bypass JET. The VBA becomes little more than a file reading function with a for loop and to change the queries you don't have to write any VBA. I have heard of significant performance improvements just by doing that alone. Indeed, you could very easily write something similar in LV (very quickly) and see if you can achieve better performance by doing a side-by-side comparison with a section of the existing VBA code. After all. You don't want to commit to a technology change only to find 2 months later after re-implementing that it's just as bad

I'm going to try to explain some details of loading a VI. What happens during load depends upon what happened when the VI was last saved, so let's start there. A good VI is one that has an unbroken run arrow. A broken VI is one that has a red X next to its name in the Error List Window because that VI itself has some problem. A bad VI is one that is listed in the Error List Window because some other VI/library that it depends upon is broken. There's a special case involving typedefs, poly VIs, and global VIs that are in the middle of being edited but are at the moment valid typedefs (i.e., they would not be broken if user did Apply Changes). Such VIs have the pencil icon next to their name in the Error List Window. Those VIs are good, but VIs that use them are bad. If a VI was good, then we can compile the VI, meaning we can generate the assembly instructions for that VI to run. If a VI is good, when we save, we compile the VI, and we save the compiled code as part of the VI. If a VI was broken or bad then we can't compile it, so when we save such a VI, we obviously can't save the compiled code. However, a VI might have been good, been compiled, and then become bad without any changes to its own block diagram. In that case, we already have the compiled code for the VI, and so we'll save that with the VI. There's also the special case of a VI that is broken only because it is missing subVIs. We may already have compiled code for such a VI, and so we'll keep that code around if we are asked to save again. (In the case of typedefs, they do have compiled code. They carry the instructions for copying and comparing their data. PolyVIs have no code. I'm not sure about global VIs.) Ok. That covers save (or, rather, it covers enough of save that we can now talk about load). When we use the phrase "a VI is in loaded into memory", we really mean, "some portion of the VI's file is in memory in a way that other VIs may link to it and it can be edited and/or executed." If you use the VI Server method "Read Linker Info", that reads the connection information of a VI without loading the VI -- so although we opened the VI file and read some data out of it, we didn't properly make the VI available to the editor and execution system. Same when the palettes load -- they read the icons out of the VIs in the directories, without actually loading the VIs. There are N parts of a VI, where N is a number I don't remember right now. But for the purposes of this conversation, we can really think of there being just three parts: the front panel (FP), the block diagram (BD) and something I'm going to call "the linker/code block" (LC). That's not a term you'll find anywhere else because I just made it up. The LC is all the stuff that makes a VI be a VI in memory, including: the linker information (the list of other LV files upon which this VI depends), the identity of the VI (which library owns this VI), the compiled assembly code (unless the VI is broken, in which case there is no compiled assembly code), and probably some other stuff not relevant to this conversation. In the development environment, whenever you say File >> Open and load a top-level VI, the LC and FP load into memory. If the VI was last saved as bad or broken or if it turns out to be bad/broken after it finishes loading its dependencies, then the BD also loads into memory. If that VI has subVIs, the LC for all those subVIs load into memory. The FP loads if the subVI is considered necessary (see my earlier post in this thread for things that make that necessary). Both the FP and BD are loaded if those subVIs were saved bad or broken OR if they turn out to be bad/broken once dependencies are loaded. For all VIs, if an edit is needed during load (say, a subVI conpane changed while the caller was not in memory, or a typedef needs to update, or LV version mutation, or updating the path to a subVI), both FP and BD load. In the runtime engine, the BD never loads. Obviously, the BD doesn't load if the VI was saved without a block diagram. In a real-time system, neither the FP nor the BD ever load. After loading the VI (and all its dependencies), if the compiled code is missing and the block diagram is loaded and the VI is not broken/bad, then LV will go ahead and compile the VI and put a docmod on the VI (the little asterisk that means "this VI has unsaved changes"). The FP and BD will eagerly unload as soon as the reasons for them staying in memory are dealt with. So if you fix a broken VI and then save the changes, FP and BD will unload unless the windows are open or the FP is necessary for the VI. If you want proof that the diagram loads independently, try this: Save a caller VI and its subVI. Open the caller VI. In the operating system, copy the subVI file on disk to a temp location. Back in LV, open and modify the subVI's diagram. Save the subVI and close the panel and diagram (keep the caller VI open). Now copy the temp file over the subVI file. Now open the block diagram of the subVI again. You'll get one of the more interesting dialogs that LV has to offer, noting that the diagram saved doesn't match the VI in memory and you can either choose not reload the diagram or do load the diagram which will recompile your VI for the new diagram code. If you didn't save the subVI (meaning you choose Defer Decision on the Save Changes dialog), then the diagram is already in memory and I'm pretty sure you won't get that dialog because LV doesn't bother to check disk for stuff it already has loaded.

Name: Icon Editor API Submitter: jgcode Submitted: 25 Jan 2011 File Updated: 29 Jan 2011 Category: *Uncertified* LabVIEW Version: 2009 License Type: BSD (Most common) Icon Editor API Repack Extended. The original Icon Editor API has been recompiled to User.lib. This code makes calls to v.i's/.ctl's in the Icon Editor plugin directory which is not of a symbolic path. This may lead to linking issues and therefore the API was extended to accommondate this. The Icon Editor API has been extended to provide additional functions such as Class Library Refnum wrappers, Global Stores and helper VIs. See http://decibel.ni.co...t/docs/DOC-8647 for the source code of the Icon Editor API. Code snapshot taken as of 15/05/10. Note: This original Icon Editor API code be updated by NI in the future. The password for the Extended Icon Editor API Library is "jgcode". Click here to download this file