Aristos Queue

Which VI did you pull that from? Because, yeah, the true case will never execute.

Is the intention to only support classes?

No other data type can define its composition function. If you want to create a class to wrap a raw cluster type, that's easy enough to do. But something has to supply the data translation layer and no other type has that ability.

Used to do so back in 2006. Worked, but didn't scale well beyond two modules in one app, for various reasons. Learned a lot since then about scaling up dataflow. Generally dropped the technique entirely these days -- avoiding anything that even remotely smacks of sharing state data anywhere in strong favor of message passing systems that scale much better in my experience.

http://ni.com/actorframework

But the notifiers are a reasonable starting point for exploration.

Time is short, but I'm mostly referring to code coverage. If I test a public method, even though I may not see the private methods that the public one calls, those private execution paths are still under test. If I make a change to one of those private methods, change can still be measured through the public methods that use that private method. That difference could be faster execution time, different return values, changes in state, or even a null change-- seeing no difference is often a valid and useful metric...

Indeed. It makes your test bed more useful for refactoring "this shouldn't change functionality" type testing especially.

You might be interested in this ongoing project of mine:

https://decibel.ni.com/content/docs/DOC-24015

If I hadn't broken my hand a week ago, it would be making active progress toward completion, but it is fully functional for the ~15 data types so far supported, without variant overhead.

The Infinite Reset Of Death dialog (that's what I call it anyway) almost never comes back in my experience, even though, as far as I can tell, it is always at least theoretically possible for it to come back. It's ancient code, deep in the execution system, but several years ago I went spelunking to try to figure it out. Seems to be -- and this is me not really understanding -- a tug of war in your code between a VI wanting to shut down and itself saying "Actually, wait, I'm not done with myself yet" and if the one process could ever get just a little more thread time, it could actually shut down. LV gets thoroughly hung because the UI thread is involved in the tug of war. That may be completely wrong. If anyone else chimes in claiming to know better, go with their answer. Regardless of the cause, I have waited multiple hours on that dialog, just to see, and only once of multiple tries did it unstick, and that happened after about 10 minutes. I treat it as a crash, myself, and if it occurs, I re architect to avoid it, though, as I say, I'm not really sure what causes it. What this means in practice is I change stuff until it goes away.

More people would use them if they were more usable.

No, it does not force the load.

It is better IMHO to NOT test your private VIs ever. If you cannot test it through your public interface then it cannot happen. Your test suite is more usable for refactoring if you only test public interface. (lots of other arguments to make here but hand is tired... search lava... i think we've discussed this philosophy option before).

True. Still, there's a usability opportunity, here. I'd argue that most users aren't concerned about a recompilation and would prefer to have LabVIEW automagically give them better performance when they password protect something. That's part of why we all love LabVIEW so much: it worries about (re)compilation and we don't

Ah, but you can open a password protected diagram while the VI is running. You can't turn on debugging while it is running.

the latest bug fix for Siri had an explicit fix for Australian accents listed in the upgrade notes.

AlexA: you would also need a queue that is specifically typed to that specific message type. but the idea is generally correct.

Debugging is a setting that requires changing compilation. Entering the password can be done without recompiling. Thus having a password does not imply turning on or turning off debugging. They're completely independent settings.

Imagine if an architect said "here's your new skyscraper, There's bound to be structural defects, but live in it for a year with a hard-hat and we'll fix anything you find".

Actually, they do exactly that. It is very common for building contracts to include clauses to make the new building more livable post-opening. The building is functional, but not necessarily usable. And there is always the possibility of a leak in some window or something like that.

Software isn't special because it is harder. It's special because it is easier. Don't like the carpets in new building? Expensive to replace and lots of waste on top of developer time. Don't like app theme? Only developer time. Might as well run a beta and see if you've got it right.

Consider making these into project templates for LV 2012 for those parts that do not overlap the shipping templates.

Fixed. I had edited my XNode... the equivalent of the "conpane does not match" error for subVIs. I was playing around and forgot to undo my changes before posting the library.

Martin: a slight variation on drjdpowell's suggestion, which works if it is not a constant: Add the value and a Boolean "has been set?". The data accessor VI that returns the value first checks the Boolean. If the value has never been set, it returns the default for that class (call the dynamic dispatch function exactly as described by drjdpowell above). If it has been set, it returns whatever value has been stored into the object.

The optimization is *already* in LV 2013. I saw the changelist go through about two weeks ago. This should not be taken as a promise that it will still be in 2013 when all is said and done -- features have been backed out before -- but I think this one is a fairly safe bet.

Did you install the Error Ring XNode from the web or something? This shouldn't happen with the one that ships with LV 2012.

(And you probably don't shy away from them... lots of nodes in the palettes are XNodes but don't look like it.)

Prototype of my Serialization library now available (JSON, XML, your favorite format...)

Over in the community forum, I have finally gotten around to posting the prototype for my serialization library. The prototype supports serialization to and from JSON for 9 data types and to XML (my own schema) for the same 9 (listed below).

https://decibel.ni.com/content/docs/DOC-24015

Please take a look. I've made it a priority to finish out the data type support for the framework generally and for the JSON format specifically. I will need community help to tackle any other formats: the framework is designed to make a single pair of functions on a class handle any file format, but the particular formats on the back end are not my specialty.

Please post all feedback on the ni.com site so that they stay all in one place and I can follow the threads easier.

meh would rather see time being spend on making templates, like in C++, be made available for LabVIEW.

Well, this is my side project, not work assignment, so I get to pick what I work on, and outside of work, I only work on G code. Lots more fun. :-)

In any case: Version 0.3 of the prototype is now available:

https://decibel.ni.com/content/docs/DOC-24015#comment-23516

Prototype posted. Feel free to ravage with feedback:

https://decibel.ni.com/content/docs/DOC-24015

It seems like I leave myself open to slowdown as a result of the large dynamic dispatch tree the project would have to navigate through. Am I right in this thought?

There is no performance impact from the depth or breadth of a dynamic dispatch hierarchy. The time needed to dispatch to the correct implementation is constant regardless of the number of classes in memory, the number of methods that a given class has or the number of overrides for a particular method.

I'm guessing this won't work reliably, as LV tends to miss mouse events for controls if the control is thin and you go through it quickly enough (which presumably would apply fairly regularly in a SP with a picture over it.

Except that this isn't a thin control -- you're talking about a subpanel *region* being entered. LV "misses" enter/exit events when you move quickly passed a control and the mouse is never registered as being over that control, not when the mouse actually gets registered over the region. It doesn't matter how thin the region is. I'm not surprised that Stobber got this working.

I am just guessing, but I'll bet this is done on purpose to avoid confusion about what happens when the subpanel is hosting a VI vs when it is not hosting a VI. Events on the subpanel tend to get routed to the VI it is hosting, so for consistency, events going to the middle of the subpanel tend to be dropped if there's nothing to receive them.

In practice, it probably doesn't save you much --- I can't think of a way to make arbitrary drag-n-drop work without having two procedures, one in the host VI that handles drag-n-drop when there is no subVI hosted and another in each of the subVIs to tell the host to change. Ug.

For the one in the host, I would suggest you should put a gray picture control over the top of the subpanel, use that as your drop target, and when it gets hit, hide the picture control. If you don't need to actually click on the subpanel, you could just make the picture control transparent and then leave it in play. But if you need to interact with it then any further drag-n-drop would need to be detected in the subVI.

You *might* be able to make it work using "mouse enter" on the subpanel and using that to trigger unhiding the picture control. I don't know how the timing on that would work out -- unhiding a control might not cause the events chain to reevaluate its drop target. Or it might. You'd have to test.