Aristos Queue

As far as OO is concerned, the video says "there are lots of OO enhancements in LV 2009, including targeting to real-time hardware." The list is WAY longer than that. I'll write something up for next week (when the release is official).

The NI Requirements Gateway interacts with the NI Unit Test Framework. It matches the tags in the code against the tags put on a given test against a given test requirement from the original spec document to show that a) the requirement was implemented in code b) there was a test written for that specific requirement and c) that test is passing.

You know what makes this NI Week so exciting? OO being used in so many places, I'm not even aware of all the presentations, demos, etc, that are using it!

Should be a much better venue, IMHO.

Your dreams are too limited. Think broader... Your dreams are too broad. Insufficient time has elapsed for such a grandiose feature to come into being. Would you settle for one out of two? Some of you may be thinking, "But I thought .lvlib files are namespaces." Yeah, that's what I thought too. But after conversations with Daklu, I know that what he's asking for is the ability to have namespaces that can span multiple library files, something, perhaps, like X1.lvlib and X2.lvlib, etc, that, when loaded in memory, are all the X.lvlib namespace. Or something like that. This is in no way shape or form a hint of things to come -- off the top of my head I can think of several problems with that particular implementation -- but it's what Daklu is hoping for. His use cases are as a way of having a single module developed in several separate parts, without having a central file be the bottleneck for development, or so that a company could have a top-level namespace for all of its separate products.Curiously enough, of the top three big improvements to OO, none of them make your list. But I think you'll like your presents none the less. ;-)

Don't tell Norm -- we're having bars installed on the door to his cube... ;-)

Check out the new NI Requirements Gateway. Your local NI sales rep should be able to demo it for you. It's a great tool for highly-regulated industries. I was shocked at the documentation level that some industries require and the hours and hours required to generate those docs, and I saw the Requirements Gateway reduce the time needed to generate AND TRACK those documents back to the source VIs from hours to minutes. Amazing tool, if you're in an industry that needs it.

I begged. I pleaded. I failed. "The project is for file organization, not for defining a single application." But if someone wants to lobby for this, I'd back it in a heart beat. I've kept "ctrl+shift+R" open just in case we need a "Run the VI that my current project has marked as the top-level VI" shortcut key. And, while I'm dreaming, we could even mark *multiple* VIs as the top-level or start up VIs, maybe some of them are on other deployment targets, and hitting ctrl+shift+R could deploy as needed and kick them all off and running. Whoa... a whole new flavor of uber-geek nirvana.

LabVIEW class constants are immune to the data wipe that can occur when you edit a typedef. You might consider that approach (though I'll be the first to admit that the way you go about creating a class constant with your values set into it -- writing a VI that puts the values into an indicator and then converting that indicator to a constant -- is less than easy-to-use).

As the owner (NOT the original author) of vi.libutilityerror.llb, let me just say: "If you use any VI not exposed on the palettes that is included in this error.llb, you should be aware that in any complete overhaul of error.llb, it may be wiped out, refactored or renamed. In particular, GEH Core.vi was created so that I could have a subVI that I could adapt and change to suit the needs of strange callers, such as Automatic Error Handling, the project providers, the FPGA compile system, etc, and that VI may need a lot more inputs, which may result in it going to the ridiculous 6x6 conpane in the future. This is true of any VI in vi.lib that isn't in the palettes, but is especially true of error.llb that is, at this time, being strongly considered for a near term refactoring (no guarantees)." But, hey, it's your code! ;-)

Come to the "What's New In LabVIEW OOP" session at NI Week. Known issue CAR numbers right up front in the PPT. There was some conversation about the wisdom of that. What ultimately carried the day was the comment from someone on my team: "We're talking about what's new, and, honestly, that crash *is* new..."

Completely correct. That's part of why the patterns aren't something that can be implemented once and reused by everyone who needs them. They vary in details for every implementation.

Patience... 9 more days.

I don't get it.

A very fine tutorial manual exists within LV's help files. Launch LabVIEW. On the Getting Started Window, in the right hand column, click on the link for "LabVIEW Fundamentals". This launches the LV help. In the left hand column is a list of topics. Search for "LabVIEW Object-Oriented Programming". The first link you'll find is for "LabVIEW Object-Oriented Programming error codes". Keep searching. The second one is for "LabVIEW Object-Oriented Programming". That's the link you want. Underneath that topic is a whole range of Concepts and How-To articles. If you printed it on paper, it is almost 70 pages of really good information.

Smokey says, "Only you can prevent wild wires!"

Perhaps?

If that worked, it means that sometimes your For Loop is executing zero times... you might want to check your other tunnel outputs to make sure you're ok with the values that they return if the loop executes zero times.

Actually, it just needs to know the value.... but the value of the number "4" as an integer is binary 00000000000000000000000000000100 as a single precision floating point is binary 01000000100000000000000000000000 The binary is actually different, so code that needs the single-precision float cannot share the memory with code that needs an integer.

It was deprecated, which means we strongly recommend you do not use it at all and it may be removed in the next+1 version of LabVIEW. Generally the context help of the deprecated function describes the intended replacement function or the reason why this functionality is not stable/usable/meaningful in the latest LV version.

We talked about the possibility of cloning *all* of the possible subVIs that you might call -- after all, it is a finite set of VIs that might be invoked -- but ultimately we decided that was very rarely useful, to the point that it was better to just steer everyone into the share clones model. If you need some state for your function stored in an uninit shift register, the recommendation is to put that shift register on a static dispatch VI that calls the dynamic dispatch VI as a subVI.

I've added this option to the Tools>>Options dialog for the next version of LabVIEW so it'll be easier to find.

Don't worry... I already filed the CAR to make the Call Parent Method node require the dynamic dispatch wire for its own dynamic dispatch input. This hole will be closed. :-)

You didn't see the data for D change... and *that's* the problem. ;-)Let's take a simple case: Class A has a private field "numeric" (default value 0)Class B inherits from A and has a private field "numeric2". (default value 0)Class C inherits from B and has a private field "numeric3". (default value 0)Class A implements a static dispatch VI "Get Numeric.vi" that returns the value of its private numeric field.Class A implements a dynamic dispatch VI "Increment.vi" that unbundles Numeric, adds 1, and bundles it back into the object.Class B overrides "Increment.vi" to unbundle Numeric2, add 1, and bundle it back into the object. Then it invokes the Call Parent Method.Class C overrides "Increment.vi" to unbundle Numeric3, add 1, and bundle it back into the object. It DOES NOT invoke Call Parent Method. What happens when we call "Increment.vi" and then call "Get Numeric.vi"? If the object is of type A, we dispatch to A:Increment.vi, and Get Numeric.vi returns 1.If the object is of type B, we dispatch to B:Increment.vi, call up to A:Increment.vi and Get Numeric.vi returns 1.If the object is of type C, we dispatch to C:Increment.vi, and Get Numeric.vi returns 0. Would you agree with me that any time I call "Get Numeric.vi" on a C object that I should get zero as the answer? Since C has overridden Increment, there's no other way for that field to be modified. So one of the invariants of C objects is that Get Numeric always returns zero. Now, what happens if, on the diagram of B:Increment.vi, we wire a C object directly to the Call Parent Method node? When we call "Get Numeric.vi" on that C object, we get the answer "1". That violates one of the invariants of C objects. The defined interface of the class is broken. And that's a problem.

My solution to this has been to scan the "View Unread Content" list and instead of clicking on a topic directly, I use "Open in new tab" for a topic that interests me. I don't close the "View Unread Content" page nor do I refresh it until I've cherry picked from it all the topics that catch my attention.