Aristos Queue

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.

i.e. Prefer anything over xml .

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.

I'd really want variant and waveform attributes to be fully serialisable

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.

Oh yes, and in the UK we also use '.' as a decimal point even if we do put the dates as dd/mm/yyyy rather than mm/dd/yyyy !

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!" :-)

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.

We're all just humans, aren't we?

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?

From what I can tell, most of those are "antonyms" although it's difficult to classify "commander toady"

Read it again. It is a list of synonyms. Each item in the list is a pair.

I have recently been looking at code that suffers from a lack of synonyms. Everything in the system has a system-to-component-to-element relationship. There are so many systems and components and elements running around, it is hard to figure out what's up. I've seen this many times in my career. You'll see this in LabVIEW if you look at the collision of naming conventions that happened with libraries and classes -- parent and child are used both for the inheritance relationship of the class and for the virtual folder membership of the project tree. Ug.

It is one of our primary jobs as the authors of software to name things well. "Well" means distinctly, precisely, accurately, simply and unambiguously. Non-English speakers may have an excuse -- I do not know how plentiful synonyms are in the world's human languages. In English, we are blessed with a cornucopia of phrases, a symphony of words tuned to exactly the note we are seeking. In an effort to combat this in your code, I am offering up this list of synonyms. The next time you are creating an API with a relationship, please consider using the full richness of our language.

Feel free to add more as they occur to you. For bonus points, post glyphs to go along with the pairs that can be used in VI icons. Several of these are already part of the NI glyph library in the Icon Editor.

• whole part
  
• wrapper core
  
• system component
  
• speaker listener
  
• master slave
  
• outer inner
  
• primary secondary
  
• facade structure
  
• server client
  
• framework plug-in
  
• source sink
  
• parent child
  
• manager delegate
  
• caller callee
  
• refer refee
  
• source destination
  
• source target
  
• original copy
  
• controller puppet
  
• interface implementation
  
• object aspect
  
• container content
  
• amalgam element
  
• genotype phenotype
  
• base derived
  
• director actor
  
• exterior interior
  
• recipe ingredient
  
• body organ
  
• super sub
  
• group member
  
• real proxy
  
• package piece
  
• aggregate fragment
  
• general specific
  
• construct foundation
  
• product factor
  
• view model
  
• shell kernel
  
• mask identity
  
• carapace meat
  
• leader follower
  
• application add-on
  
• face heart
  
• sum segment
  
• edge locus
  
• commander toady
  
• senior junior
  
• owner operator
  

My husband, James Loftus, will be there with an FTC team from Austin. Look for the LASA team -- they're the ones wearing "as funky as you can get purple" elements of clothing. Their school color is purple and the mascot is the panthers. James is also on the LabVIEW team, so if you say hello, he'll know generally of what you speak LV-wise.

I would just get the project property of the new VI. That would also allow you to know which target within the project.

Isn't this a feature of the Packed Project library (that does not exist in other languages)? The PPL is used for "interface" and it would be nice to separate the "presentation" from the class itself. This would reduce a whole lot of "busy work" wrapping classes.

PPLs are not a part of the LabVIEW language. They're just packaging for functionality, no different in many ways to a .zip file. The PPL is not a presentation layer or any other formal aspect. It's just a tool for getting VIs to load faster.

When you ask for changes to scope, that addresses language features, which means changes to the run time behaviors that would impact dev environment and run time environment alike, regardless of packaging.

To me a better approach would be to just support private inheritance.

A good write up of why composition is preferred to private inheritance:

http://www.parashift.com/c++-faq-lite/private-inheritance.html

Doh! Good call, mike_nrao. I completely forgot about Ram's trick.

Google "delegate pattern site:ni.com".