ShaunR

I think the main point Smithd was making is that the current thinking about replacing AEs is to use DVRs but with messaging architectures, global storage is handled differently requiring neither. You have, however, restricted your options by insisting that you don't want to use by-ref solutions (although I think you and a few others , maybe misunderstand what that exactly is since AEs are not by-ref)

Making copies is how LabVIEW resolves shared resource contention. Even with DVRs on a wire this is true except the resource is just a pointer to the data and so it is that which gets copied.However. Even then. With a DVR, you are forced to use an IPE to access it because it can be accessed from anywhere. This is your mutex around the data. Globals are not by ref. They also are copies (see above).The second biggest argument for why you shouldn't use them is that every instance is a copy of the data so liberally spreading them throughout your code is a quick way to resource starvation when that 250MB 2d array gets in there..

Software is like a fart. Yours is ok but everyone elses' stinks.

I don't have opinions. I have mental scars from fixing other peoples code.

A common thing with VISA is that you open the port then press the Abort on the diagram toolbar. This leaves the VISA session open so when you try to run again, the Open will fail (because it's already open but you don't have a reference anymore). If you go to the LabVIEW options (Tools>>Options>>Environment) and check the "Automatically Close VISA sessions" you shouldn't fall foul of that. (IMO this should be the default.) Automatically close VISA sessions—Automatically closes VISA sessions left open by the application when the top-level VI becomes idle. This checkbox does not contain a checkmark by default.

Or the Muddled Verbose Confuser pattern, as I call it. That must be the worst pattern ever invented. No-one can agree what should be in what bits. No-one ever puts the right bits in the right place after they have argued about it and everyone ends up with MC, MV or one of the other letter combinations (take your pick). Then every single one of the gazillion files only has one of 3 names (controller, view and model) In theory it's great. In practice it's foot shooting with a bazooka. Look at the "Event" examples that ship with LabVIEW. In your GUI you probably already have an event structure so create a "User Event" and get your GUI to register for it.

Not quite. I said they are wrappers around shared resources to introduce mutexes. The mutex is the VI boundary and makes access atomic. It is indeed about accessing things from processes running in parallel. I think you have forgotten that they are not reentrant so they have blocking behaviour around the resource. I'm not sure what you mean by " By-value objects are not sharable and have no use for mutexes. ". You can branch a class wire and what good would a global variable be if you couldn't put it on multiple diagrams?

Yes. And I can use a screwdriver as a chisel. (By-ref classes is an irrelevance.) Any class is a number of [atomic] methods acting on a protected storage container and this is what AEs attempt to do without the language support. Any other interpretation or extrapolation is just linguistic gymnastics.

Actors and AEs aren't equivalent. It's like saying a program is the same as a DLL. AEs are just wrappers around a shared resource to try and introduce mutexes. So you could have a "List" and methods "Add", "Remove", "Read" etc called by multiple VIs.. Nothing is "running", They were primordial classes - wrapping a global memory when we didn't have the language construct of classes.

Well. As I said. For me it's.polymorphic VIs because they have the menu in lieu of an enum (same thing but different) and de-clutter the compane. However. I don't think I have required global storage like that for a long time. Using a DB makes AEs (and a lot of other things) almost redundant since you just craft a query string.So for your average N sensors example it would be a one liner like SELECT avg(value) from Sensors WHERE status='active';

Action Engines are singletons and class clusters are an instance scoped variable, not global. So. If you want an exact equivalent then you have to jump through hoops like using a queue or a FGV (just like an AE-DOH!). The migration means you get new VI methods for each ENUM entry (I've talked before about code bloat) and forcing the user to drop a load of different VIs from a palette or quickdrop. You don't get a lot else apart from increased complexity and the ability to wave the "I'm using OOP" banner. Personally. I would prefer a polymorphic VI over a class because you still have the code bloat but don't burden the user..It looks like you have just swapped the enum for a drop-down menu and you get the adapt to type for the different inputs. If you want it as a class because.......reasons. Just wrap the action engine in some class methods (one for each enum). That's pretty much what you will end up doing if you don't use a queue and you can still wave the banner However. if you promise and "cross your heart and hope to die" that you will only have one instance then a normal class (with a DVR?) will suffice .

Make sure the VI is running before setting its position/size. This effect usually occurs when you use an external window sizer/positioner to the VI that you want to position (rather than on its own diagram) because the FP opens but the menus, title bar and sliders are visible (depending of FP settings) before they are hidden when running.

Transition from .NET 3.5 to .NET 4.0.

Ask the systems team at NI. They are good with names for NAFFISMs.

If you look at this post (see the attachment). Yair created a transport class for some interfaces. He adds a serial a couple of posts below so that maybe useful to you.

Can you show the result of a query that returns all rows before and after you have tried to delete? BTW. It is better to post a snippet or the actual VI you are using than normal images.

You can also wrap the dedicated inits in a polymorphic VI to give the appearance of a single init (with different inputs-unlike a class) and maintan the design time polymorphism of the class.

Indeed. But It is not a problem for you as the author but for me as a distributor of a composite or derivative works (including executables). Anyway, We digress into a well worn rabbit hole. Lets get this done.

try DELETE FROM %s WHERE 'user' ILIKE '%%%s%%'; maybe the data has inadvertent spaces or capitlisation

It doesn't just affect the source. It places a burden on making the particular source code used, and the entire build environment (usually tripling the distribution size) available for three years even if you just link to the binary. 99% of the time I' can't commit to that and adding the confusion when redistributing because the toolkit user needs to understand that as well (and usually they don't) means it's more hassle than its worth. As far as I can tell with GPL and LGPL. They are just licences designed to set traps for programmers without lawyers. Anyway. You are well aware of the arguments and the utter confusion voiced by many about openG licencing. So you release what you must. You seem to be the last man standing with the openG stuff and we all thank you for still consistently delivering. They say "one supports ones products until one dies" and so far you have kept to that

Sounds great. I'm a great fan of examples as black-box, system tests so when you post the code I'll come up with some "examples" to exercise it. Can the c source be under the same BSD iicence or is there a particular reason for LGPL shenanigans?

That's after you have been told to go away and learn thermodynamics and molecular physics when all you want to do is make a cup of coffee.

What would it take to make this release ready?

Yes +10 No. Just because you can doesn't mean you should. No. That's Linux thinking and should be derided at every opportunity..

The OS condition is project only. When you deploy your package, the end user needs to have that in his project too (it also won't work if the VI is opened outside of a project). It is better to use the TARGET_TYPE (Windows, Unix and Mac) which doesn't require the user to do anything and works without a project file.