ShaunR

I would say this is a bug, and a rather nasty one at that. Well done for isolating the cause! Back-saving to 2009 reveals that the method is "Set Cell Value (New)" which, of course, doesn't exist. Re-select "Set Cell Value" and the code runs as expected (i.e. works fine in 2009). If you then save the 2009 version and reload back into 2012 the node shows "Set Cell Value (Deprecated)" and, although it is a valid property, exhibits the same error. It seems that the method has been changed considerably between versions. Another thing to note is that the enum never changes its value when selected (wire it to a boundary then stick a probe on it). However. If you set the VI to "Highlight Execution" then change the enum and turn off "Highlight Execution"; the value will change and the VI will proceed without error.

I'm sort of on Darins side here. (I would add examples to the list of "comments are for"). Of course. I think most are all talking about comments in English. I wonder how useful Chinese comments would be to most non-Chinese LV programmers or, conversely English comments for Chinese? Comment language is not a problem for a graphical environment Generally I look at a piece of code and add a quick comment if it is likely I will not understand it "easily" myself in three months time (I tend to have a FIFO memory with limited heap) . For the rest, (taking account of Darins list) if you can't understand it from the other documentation (like the VI description or the design spec), then you shouldn't be hacking away at my code. Detailed design specs are for communicating function, not the block diagram. </RANT> And while we are on the subject. I hate people that cover wires with labels! I'm perfectly able to trace wires through the system EXCEPT if you cover them up with labels.Above, below, above to the left or right; fine. But not on top!. </END RANT> There is no such thing as "self documenting code", There is only "well designed code with documentation" or "experience.and expertise".

To hide embarrassing spaghetti code

What are you using (in LabVIEW) to query the database? SQL Toolkit? If you have already retrieved the blob data then you only need to save it to a binary file using the "Write to Binary File.vi" primitive. Once that is done, you can load it into a LV picture indicator with the "Read [JPG/PNG/BMP] File.vi" in the graphics format palette As Ton is intimating. You need to know the format (jpg, bmp, png) to load it back up because you need to use the right LV vi.

I think he just means it is binary (BLOB in database speak). In which case it will be whatever format the original image was and he just needs to save it to a file with the right extension and play with the picture toolkit. I also assume by his reference to "SQL Server Tab" that he can see something in a database viewer of some description. Of course "assume" makes an "ass" out of "u" and "me"

Don't forget that the user doesn't give two hoots about what is actually in your splash screen. They just want something that shows them that when they launched the app it did indeed launch and is doing something rather than hung. Everything else is just for your benefit. If all hierarchy is loaded with main then just load main and put an animated GIF on the splash FP. The purpose of a splash is a lightweight, fast loading placebo to keep the user occupied; nothing more. My apps are generally partitioned into sub-systems which are dynamically loaded so, apart from the UI, it just loads those then finally the UI (UI can be anywhere from 80% to 20% of the entire hierarchy....it doesn't really matter). All the "loading Plugin" is purely for me to see what I've missed or what has failed without waiting for everything. In the old days we used to just have a "VI Tree" which we would launch and the modern splash is just an extension of that. The only difference is that we can get the names and the number of those VIs and log them (if we want to). You've done the hard part (making the splash generic and not app specific). I really wouldn't spend a lot of time worrying about how it loads your application or whether your progress bar is linear or not.

a) Graph set to "Loose Fit" in the properties? b) Daylight savings time?

Indeed. The splash implementation I use loads the UI last which is only visible once all inits are completed and we are ready to rock 'n roll. It waits 2 secs then disappears. This means no matter how long or short the UI "show" is, the splash always hangs around for at least 2 secs (no quick blip and it's gone), the UI is always visible before it disappears and the application is fully active, configured and initialised. Well. I've never had to explicitly load vi.lib files. If they are used, they get loaded when the top level VI is loaded. But the rest of what you are saying is correct. I have a get path VI that augments the path (just a conditional structure) depending whether it is in the application or in the IDE.I also generally have one or two directories off of the App dir and usually, they're named Core and Plugin so that I can use the dir name in the launcher window-e.g. "Loading Plugin: xyz") . The loader also has the capability to just look in a directory and load any files in there so it loads plugins dynamically as well. A major difference is maybe that although the launcher loads the VIs. It doesn't necessarily execute them (that can be a flag in the cfg file but I prefer a specific naming convention). Therefore some VIs (modules required to be loaded but require ordered initialisation in concert with other modules) just get loaded. The launcher just obtains a ref that causes LV to load the modules hierarchy and then closes it once the main app is up and running and opened it's own. This means that the launcher only gets it in memory ready for the main app. It also has a sub-panel so things like checking connectivity can be shown in the dialogue for fancy additional indicators (scanning for RS485 devices for example).

Nope Because I do it the same way One page ago The only real question is, how do you detect that the UI is initialised and ready to show since everything being loaded, doesn't necessarily mean the main FP can be shown (I use a queue or notifier for this, presumably you use an actress)?

B. Too hard, too buggy, too limited and too slow. X controls are the ActiveX of LabVIEW and I treat them with the same derision. We would be better off with NI just telling us how they create the real controls and be done with it (NI also have the capability for plug-in controls via DLLs which is completely undocumented).

It depends where/what your project model is. Here's an example of animating a There is also an example shipped with LabVIEW that animates a robot on the front panel (just a drawing animation)

Well. Ever since LV2010 I've noticed that even the IDE takes forever to shut down. I have assumed (rightly or wrongly) that it is something to do with making sure the run-time exits elegantly, so the implications of a task-kill may be subtle and/or horrendous in some unknown scenario (DAQ config?). Suffice to say. NI have done something during the shut-down process that has increased the duration significantly. I would compare your software with one that has been compiled in 2009. I would expect it to exit far more promptly if it is down to the NI environment.

Connecting VIs via their error terminals is the preferred method to a sequence structure.

Yup. LAN is usually the issue. Also. Different LV versions work only with certain processors - Something to bear in mind if you are trying to leverage an old PC sitting around. Requirements for Desktop PCs as LabVIEW Real-Time Targets

Nice find It would be nice if the tolerance had a default value so for most use cases we didn't have to specify it.

Yup. +1 to Ton

I never claimed "everything should be public" either. I argued protected vs private.

How I wish this one was true. I'd have definitely had a go Virgin ‘Little Red’ gets glass bottom

He can use a variant for different datatypes (array of boolean or array of doubles) and therefore won't have a problem with overrides.

Variant tomatoes? The problem isn't so much with different data-types, it is more numbers of terminals where you run into trouble.

A file with tag names, expected values and/or limits . Different set-ups have different files. (sorry to be sparse, but can't help thinking I've described this to you before, somehow )

That may sufficient for the OP and it is a lot closer than nothing at all..

Right! So that must be documented somewhere (as it was for the Single Precision Functions in the FPGA example I gave). I doubt if the "rules" for the particular target are that esoteric that you can only load this single precision object on this FPGA target when it's Tuesday and you have your left trouser leg rolled up. It's more likely that it will be things like an FPU isn't present on that target (that will be documented internally at NI) and the manual will supply the features that are or are not applicable. The OP says that it may not load on the target because the VI may be broken due to wiring, missing dependencies etc. So he is looking to weed out incompatible features (like the DLL checker that is used to check Pharlap DLLs). This is presumably so they can write it "offline" and verify the developer hasn't used unsupported features, At the simplest level you are trying to end up with a compatibility matrix accross LV versions, targets and features. I would be very surprised if an engineer at NI hasn't got a spreadsheet with it somewhere (probably an applications engineer) Once you have that, you can add simple rules for "odd" anomalies. You don't have to start with all targets or LV versions. However, eventually you will have a complete picture. After all. Most people that use the targets "know" what does and doesn't work. It just needs to be formalised to be able to use it programmatically.

I think this is the only (reliable) way. The functions and features supported on each platform are documented (example) but not in a single list that I'm aware of so you would have to spend a bit of effort pulling it all together (property nodes have tables in the help that state quite a bit about where they will and won't work). Once done however, it can be put in a DB along with LV versions etc making examining a VI fairly straight forward with scripting. You would just need to keep the list updated with the latest LV version. You never know. Maybe NI have an internal doc that pulls it all together. Worth asking your local rep.

Rolf is the man you need to talk to. But here is my limited tuppence. Pharlap uses a stripped down windows API that implements many but not all Windows API calls (I'm pretty sure you cannot use normal windows kernel mode drivers AKA sys files-Rolf will confirm). There is a checker that you can run on DLLs to see if they are compliant and you need the version for which LV version you are using (I've linked to the 2009 one, but there are 2011, 2012 etc that you can find with a bit of Googling). If it is not compliant and you do not have the source, then you are up a creek without a paddle. If you have the source, then you will have to hide in a dark room for a couple of months to make it compliant. If you need a "sys" file then this is a hard-core kernel mode driver and fraught with rabbit holes not only in respect of the driver, but also it working within Pharlap. It is an "expertise" in its own right - I would highly recommend you sub-contract it out if you cannot get support from the supplier or choose a different card.