Aristos Queue

I read "null" as a value of a field, not a separate data type. But I can see how it can be interpreted that way.

JGCode: I checked the Perforce logs... all changes to the Preferences Dialog in 2012 were in before the first beta, so you should be able to investigate this further on your machine. I have to go now. I may get another chance to look at this later this week, but probably not.

JGCode: Have you tried this in LV 2012? Opening and running your example project, it is taking 24 seconds to launch the Preferences Dialog and between 5 and 10 seconds to switch pages within the dialog. No idea why. Just doing Tools>>Options within LV comes up within half a second (human counting, didn't bother actually benchmarking). (I would try installing into my LV 2011 to compare, but VI Package Manager won't talk to LV 2011 on my machine... keeps complaining about the VI Server security settings no matter how I set them... it's almost certainly my fault -- I've got my 2011 loaded with almost every module and who knows how many packages in an attempt to replicate a weird CAR report, but until I get that untangled, I don't have a 2011 to look at.)

The biggest problem with using string for common data types is that it leaves the formatting of that data up to each individual Serializable class to define the format. If you have N objects encoded into a file each of a different class and each one has a timestamp field, you can end up with N different formats for the strings. On the other hand, if we give Formatter alone knowledge of the timestamp (and other types of interest), it can have methods to control the formatting and parsing, and then we leave those off of the PropertyBag class. I'll draw it up and see what that looks like.

> I presume your reluctance to support many of the types in LabVIEW ShaunR: That's part of it. Just as large a concern is the complexity added to developers of Serializers having to work with all the types, and the work that Formatters having to handle all of the types. I do keep looking at JSON's 5 data types and thinking, "Maybe that would be enough." But I look at types like timestamp and path, and I know people would rather not have to parse those in every serializer or serializable, and *those* *aren't* *objects*. That historical fact keeps raising its ugly head. They don't have any ability to add their components piecemeal or to define themselves as a single string entity.

Since I'm not planning to support complex as a scalar type, complex waveforms would be particularly nasty to support. I think we'd have to admit the scalar complex first.

I wouldn't have bought them either, Darren, if they hadn't been cube shaped. You're just lucky that MFOA didn't add the tag line "and they'll make you a faster LV programmer." :-)

Try posting this on ni.com. I suspect the AEs will have a ready response for you. My answer would have been the same as the one crelf already gave you. That login dialog is certainly not on by default in any version of LV.

ShaunR and I agree on very few things, but when we do, it is adamant agreement. Whatever your data communications problem you're having, if XML is your solution, you actually have two problems.

Todd: In theory, later this year the makers of Cubelets will change out all the logic cubes for a new style that allows bluetooth to change which instruction each cube represents. Includes ability to put custom logic on drive cubes, etc. But that would mean buying a new set of cubes... *sigh*

Jack: I replaced the docx with PDF. Generally, that's not going to be feasible, as I said in the document... an open ended type system doesn't work for a general serialization architecture. I've found zero instances of anyone building one successfully without sacrificing either performance or extensibility. The attributes of waveforms can be handled as flattened binary embedded in XML or JSON, but that's not the same as making them readable in XML or JSON.Now, having said that, if you're serializing an object that has a variant field that is, for example, one of the key-value databases, you're free to add each attribute as its own value to the property bag, calling the appropriate type function. Damn Brits! As my physics teacher used to say, "Behave or I'll make you compute that in BTUs! You think thermodynamics is hard, wait until the British get involved!" :-)

I do believe that some days the Marketing Forces Of America decide to target me personally, as they did about three months ago when I first saw the Cubelets video online. Cubelets are like the physical manifestation of Actors: cubes that each do their own action and pass messages between each other using dataflow buffers to create robots! So, I quickly ordered a set, because that's what you do when personally targeted by MFOA -- you don't want to make them angry. They arrived today. And, oh yes, they're neat. I had a couple false starts, but quickly built up the basic "come to my hand" robot. Shortly thereafter I had a robot running around, capable of turning to dodge my hands and flashing light patterns. But I quickly ran into the LEGO problem. You know the problem: You *never* have enough LEGOs. In this case, within a half hour of playing, I found myself wanting two inverter blocks, and I was "hacking" using a flashlight block as a data blocker block. And fifteen minutes after that, I had exhausted the permutations available with my limited set. Why must the coolest toys be so expensive?! Check out the price list! http://www.modroboti...vidual-cubelets And then, I realized the answer to that question: it's hardware. Physical matter costs. And I looked at my cubelets, and I looked across at my laptop, which had on screen the cube control of one of my actor classes. Looking from one cube to the other, I realized just how lucky I am that nature made me a software engineer instead of a mechanical engineer. And then, my next thought... "Hm... perhaps we should start charging $25 per cube? If people are willing to pay so much for hardware cubes... and, hey, the software cubes are *reprogrammable*!" But then my cat started chasing my cubelet robot, and I realized this is the one area that the software just cannot compete, and I guess that justifies the hardware price: no software actor is going to have my cat pouncing quite so adorably. So I guess it's better to keep the software cubes priced like an all-you-can-eat buffet: buy LabVIEW and get all the cubes you want. And I'll just dream about the day when we *finally* get reprogrammable matter. And then we'll see software *can* keep cats on their toes! (Side note: When one of the hardware cubes receives two messages simultaneously, it averages the messages. I wonder if there's any way a feature like that would be useful in a software actor framework? Add it to the brainstorm list...)

If you've ever had problems with LabVIEW's support for object serialization and wish to review a proposed API for improving that, your feedback is welcome here: https://decibel.ni.com/content/docs/DOC-22568

I think GregR was being facetious. The reason it may not be findable may be part of its insanity -- it might be disconnected from any object actually on your VI, but still somehow on the VI's heap list.

I would suggest one option even better than all these solutions: Use the Asynch Call By Reference node to spin up instances and set them running, and easily pass parameters into them. You can pass in your favorite data communications mechanism (queue, notifier, etc) to use to signal them as needed.

For the time being. We strive for better, and I hope to live long enough for the cybernetic implants to kick into high gear.

Mike5: The last property in my property node is the one I was talking about... but Mellroth's "Ring Text.Width" property is even better because you don't have to worry about the stupid "+ 30" that I'm doing to account for the ring. Mellroth: Does yours work for "zero strings in the array"?

> That VI doesn't seem to find clones started by the Start Asynchronous Call function. Bingo. And that's the problem we've been fighting. Worse than that -- opening a second VI reference to clone VIs is unstable. In fact, it was supposed to be impossible, and the fact that some of us have found ways to do it really disturbs the designers. Since the hack works well enough sometimes, I successfully talked R&D out of "fixing the bug" in LV 2012, but I'm not sure I'll be able to do that for 2013. The secondary clone references really aren't supportable without substantial refactoring of the whole VI Server mechanism. I'm trying to convince The Powers That Be that we need better debug support in the same version that our hack disappears, but that's been a hard argument for me to win. Hope isn't lost, but the windmills are winning at the moment.

Or is that just not possible to do? I'm specifically trying to find a way to do that to a System Ring control. [EDIT] I post to LAVA... and that way, LabVIEW knows I've sufficiently embarrassed myself publicly with my lack of knowledge, and so now it can show me the answer. There's a property that I *swear* was not in the pop up menu for the last half-hour called "Named Numeric Size" that I can use to resize the ring control. Not exactly what I wanted, but at least I can build it. Grrr. [EDIT] Just in case anyione else is looking for this...

An idea got posted last week for improving conditional compilation symbols. I saw it today as I was reading my backlog of ideas, and I quickly Kudos'd it. Then I noticed I was the only the second person who kudos'd it. Really? I would have thought that an ability to set constants in the project file and use them on the block diagram would have generated more interest. Is this really something that most of you would not use? [Note that other ideas posted after this one have 25 to 44 kudos on them, so I'm sure people have been looking at the Exchange during this time, but just passing over this idea.] http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Project-Defines-or-Project-Variables/idc-p/1982619#M18012

> Where the differences between FGVs, globals really lie is in "State" not "Data". I'm still not seeing any difference between a get/set FGV and a global VI --- other than that the global VI is more performant. The get/set FGV is NOT an action engine. The original comment was that if you're only using them only for get and set, you should be using a global VI. That I agree with. Of course, we also say that you should not be using a global VI. By the transitive property, you should not be using a get/set FGV. :-)

NI Week each year is held at the Austin Convention Center. The building has undergone some serious transformation to make it a much more environmentally friendly building, and that has lead to a significant reduction of operating expenses. The building is being held up as an example of the kind of green-envrionment-meets-green-finances success that more businesses might be able to achieve in the future. Part of their success comes from educating visitors about how to handle trash. In other words, when you visit Austin, please make sure you put stuff in the right bucket! :-) http://www.forefrontaustin.com/feature/forefront-two-solid-green-investments

I did finish reading the paper. Good writeup. I have only one request: At several points in the document, you use the term "delegate". I would like you to add comments to specifically disambiguate this pattern from the delegate pattern because the two are nearly identical in implementation. I *think* the major difference between the two is whether the secondary object is supplied from the outside or whether the primary object chooses the secondary itself. It is a fine line distinction that I am not clear on, and I think it is worth touching on.

http://ni.lithium.com/t5/LabVIEW/Can-I-load-pictures-for-a-picture-ring-control-at-run-time/td-p/1681952

My two questions: 1) I have not yet read the paper... is the implementation you give one that you have actually deployed successfully in at least one real application? There have been declarations of "this is a pattern" from folks that have never actually tested their implementation under real-world scenarios and those declarations have turned out false. 2) Assuming it is valid (which I'm expecting given your history of quality), do you mind if we link to it from the patterns page on ni.com?