Notifier with buffer

[ShaunR]

True. If, on the other hand, it is an option it is a good one. For the record, I think for a number of reasons that the functionality in the DSC Module ought to be part of the LabVIEW core. In particular, the functionality in the DSC Module is an extension of existing functionality in such a way that it can take a while to figure out where the boundary lies. Moreover, the publish-subscribe option (Observer pattern) is extremely useful--and pretty much a common programming standard--and NI ought to promote its use in most applications. I think doing so would make LabVIEW development more effective and presumably enhance its marketability in turn.

I didn't try this, but I'm guessing from your question that it will be big. Then the developer must choose whether the larger memory footprint justifies the ease of development for the particular application. (I also presume that the footprint does not scale linearly with the number of shared variables.) I think for many (most?) applications the larger footprint is not a serious issue.

I don't have a problem with large installations per say, but when you have to deploy an installation of a couple of hundred megs to run a 300k executable, it makes Microsoft look positively anorexic.

I could understand it in the old days when LV run as a virtual machine giving you 32 bit applications in a 16 bit world. But now its just a huge api with loads of dependent apis that have nothing to do with your program (like PXI for instance).

---rant over

[jgcode]

In practice we haven't needed to create SVs from scratch at run-time yet.

I thought you might have, as this method of generation lends itself very well to an OOP architecture.

Having said that, I haven't had the chance to design any apps like this, but I have been lucky enough to do maintenance on ones that have.

And I can see the benefits are really cool.

[PaulL]

And I can see the benefits are really cool.

No doubt!

I think this is a great idea. We just haven't done this (except for some test cases) ourselves yet for the following reasons:

1) Most of our subsystems use RT SVs where (prior to LabVIEW 2009) LabVIEW objects didn't exist. (This isn't a dealbreaker, though.)

2) Our data SVs have been clear at design time and it has just been easier (and still successful) to create them using the project interface. That doesn't mean the better way wouldn't be to create them programmatically. Ideally that is what we would do.

3) On Windows we do support dynamic object data messages but to do this we create string variables ahead of time and send flattened LabVIEW objects of various types on a shared variable (topic) or two. We have implemented the Command Pattern effectively using this methodology. Again, we probably should create the string SVs programmatically but we haven't bothered to do that yet. The more SVs we create, though, the more important it would be to do this programmatically.

Paul