NI: Get to grips with Fundamental LV Shortcomings.

[Wiebe@CARYA]

>
> In the years I've been using LabVIEW, I learned not to depend too much on
> new features in new releases. Recently I fell for it again. I used the new
> pane background. The bugs just kept on comming... And jet another
example...
> The runtime menus for controls. First thing I wanted to do is change them
> during run time. Perhaps I'm stupid (probably), I still haven't found how
to
> do that. So I did what I am used to after years of using LabVIEW: I made a
> workaround...

Robbie pointed out to me that it is possible to change the run time menu's
of controls. You have to use the reference that is returned by the "Shortcut
Menu Activation?" event. I was looking for a property "Shortcut Menu
Reference" or something like that. Did try the event, but somehow I got an
error.

Regards,

Wiebe.

[Gabi1]

Extremely interesting thread.

---

@Aristos Queue wrote:
LVOOP is fully released, fully supported and intended for use by customers in their professional projects. That was true as of LV8.2. LV8.5 has improved many usability aspects (eliminating much of the tedious editor work), but functionality wise, everything was present in 8.2.

---

I think Ben refered to user friendlyness. at least i would refer to it. you see, up to now, if i wanted to do something new with LV, i tried, looked a bit at the help, read the forum, and 'voila', got my solution chick chack.

LVOOP really touched my curiosity cord, and as i was thinking of how to build my next project, i decided to jump into it. well, after 3 full LV days of trying around a reading a lot, i am still quite confused by the implementation.

So LVOOP doesnt sit (for me at least), with the legacy of intuitiveness of LV. and it is frustrating.

disclaimer: using LV8.2 yet.

[tst]

---

@tbd wrote:

> LV Classes are nothing like VISA, ActiveX, .NET or VI Server

I'm still not convinced that this needed to be true!

---

Aristos Queue would have been much more suitable for answering that (and he actually has, more than once), but here goes - one thing I know for sure is that the designers of LVOOP know more about OO design and have definitely spent (considerably) more time on this than we did, so we should give them some credit.

If you want, LAVA had some serious discussion about the implementation, but for a shorter document, you can read this.

[tbd]

To the hard-working at NI, trying to produce something of value - you have succeeded.  It's not perfect, but nothing is.  Loving the art, and having hitched my career to LabVIEW, I care about the direction you're going.  If you'd rather I and my department, base our test-solutions on a different language - shoot me some email, it will cost you only a few licenses (probably less than 5 in the next two years).

> geir wrote
"G purists" and
""Well, if you do not like State Charts, then you should not use them. Used in the right way and in the right places they do however communicate what the System does very well, and give a high level view of ** what ** the system does!""

"purist" yes, but my complaint isn't really with the StateChart tool (had it been, it might have been on topic  -), it's with the preoccupation, here (on this forum,) with the "State Machine" as a general programming solution.  At the core of every SM is an unconditional-branch and it's "power" is it's curse.  SM => Spaghetti Machine.

> > > tst wrote:
> > > LV Classes are nothing like VISA, ActiveX, .NET or VI Server
> > I'm still not convinced that this needed to be true!
> Aristos Queue would have been much more suitable for answering that
> (and he actually has, more than once)...

OK tst, please provide more than one link where AQ  specifically answers why a class-interface of the property/method type (used for VI-server, AX, .NET, and VISA ) would NOT work for LV-classes.

You've said "LV Classes are nothing like VISA, ActiveX, .NET or VI Server", yet here's a link where AQ says properties can be listed in property nodes.  He also says that they (the LVOOP developers) "held fast" to a VI class implementation, but also implies that "Invoke Nodes" and VIs are analogous.  Apparently, VIs implement methods, and all VIs could have an "Invoke-Node" representation.  Though AQ says that will never happen, why not?  It would make LV classes more "intuitive" - and the diagram more readible.

Even if you can back-up your "more than once" assertion, the answer is far from clear at the moment.
But you won't have any trouble providing just two links "answering that", right tst?

Message Edited by tbd on 10-09-2007 04:04 AM

[billings11]

tbob said:

"Not having experienced any problems with upgrading, I can't say that I feel your pain.  If I had to spend 400 hours fixing stuff after an upgrade, I would be upset too.  Perhaps you should not have upgraded at all.  You don't always have to keep up with the latest version.  That is a decision that will vary from situation to situation. "

That I will agree with!  But I felt compelled by the promise of a project amanger and LVOOP, and look where it got me!

[billings11]

tbd said:

"I haven't used the "LVOOP" either - and I've no excuse except that project-views without direct mapping to OS-directory-hirearchy is not something I'm ready to fight with.  I'm told LV 8.5 has fixed this, and it's here (still in manilla envelope), but LV8.2.1 was a big jump for me an I'm not anxious to make another jump right now - especially in the middle of developing a large app."

At this point I've dove right in and developed a fairly large-scale test app using a single but critical LVOOP implementation.  Its a basic test sequencer app, that can interchangeably run a number of tests in any order as specified by a user or loaded from a database.  My parent class is called "Test" and all of the different tests inherit from the "Test" class. 

The "Test" class private data contains general parameters about the tests, like what the sequence context is.  Then in each specific test class like "Step Response" the provate data contains parameters and results specific to that test.  I figured this is a very straightforward implementation and I didn't want to mak it any more complicated for my first app.  But its fairly involved because there are a lot of different types of tests.  I used to have a very similar sequencer app that used tests interchangably by using variants as standard inputs and outputs.  But variants copy data at every terminal, so I figured out one time that any piece of test data was getting its memory duplicated 67 times by the time it made its way through the whole hierarchy of vi's.  So the LVOOP idea might stop almost all those memory duplications.

I have to say once I worked my way through all the initial release bugs the implementation went great.  Since all LVOOP class data is private the only way to access it is by making a method vi for everything.  So to get data from teh class you have to actually create a method vi to "unbundle data".  You can't just unbundle it.  But the nice thing is that method vi's don't copy memory at the input and output class terminals.  So almost all of those 67 memory duplications got saved.  I tackled the whole "project-views without direct mapping to OS-directory-hirearchy" by just creating a careful identical directory structure in the project as there was in the directory.  But I have to admit it feels a little weird that classes completely contradict every rule I've made for myself over the years about vi namespaces and directory structure.

I would definitely agree that it is strange they decided to express "method vi's" as actual vi's instead of invoke nodes.  It seems like a perfect fit to model methods as invoke nodes.  Maybe they could add an option to express a method as either one in the future.  I mean... it seems like invoke nodes are a graphical implementation of C++ classes inside labview... are they not?

The real "horrible pain in the neck" problems come when you try to build your project into an exe.  You can't "remove as much as possible" with classes, but of course it doesn't tell you not to.  Also you can't "disconnect unused typedefs" in the build because it also disconnects all classes from their private data typedefs or something.  But it doesn't tell you not to do that either.  Also you can't build a single executable anymore either.  Every single method vi, in fact the entire project folder structure gets copied to the data directory with every method vi in it, and it all has to accompany the exe as support files.  Plus the error reporting is not really ready for primetime.  I've seen way too many "The class this vi belongs to contains a broken vi" error messsages without being told what vi is actually broken.  And then all the little things where labview crashes if you click three times on the title bar or something.  But I hear a lot of that stuff has been fixed by now and all I have to do is upgrade again.  Great!  But while it is still subject to question, LVOOP did offer a real benefit for my application.

[AristosQueue (NI)]

> I would definitely agree that it is strange they decided to
> express "method vi's" as actual vi's instead of invoke
> nodes.  It seems like a perfect fit to model methods as invoke
> nodes.  Maybe they could add an option to express a method
> as either one in the future.  I mean... it seems like invoke nodes
> are a graphical implementation of C++ classes inside
> labview... are they not?

This is a fascinating tangent this conversation has taken. You're the first batch of customers who has actually *wanted* the Invoke node view. In most conversations I've had, the Invoke nodes for all the other APIs are considered a failure precisely because they are text and not icons.

The reasoning goes like this:  LabVIEW Classes are LabVIEW data types implemented in LabVIEW. The functions that operate on those datatypes should look like functions in LabVIEW. SubVIs are icons. The methods of classes are VIs. When they're invoked as subVIs, they look like icons. The Invoke node appearance is actually a problem for a lot of people -- code written in one human language isn't readable in other human languages but the icons are recognizable to all programmers. LabVIEW, as a graphical programming language, prefers the graphics over text. Text changes size when names change, disturbing the surrounding diagram. Icons don't.

If you want your subVIs to have an invoke node feel, then simply popup on them and uncheck the menu item "View as Icon". Boom -- you now have a node where all the terminals are displayed as names. It's even got a yellow header on it.

Ultimately, most of the people I've spoken with -- both before we released classes and in the year since then -- see the Invoke node as a step backward in LV's graphical syntax. The property node gets less of a knock because it at least brings more functionality to the table (stacking multiple properties together in a single node), so it is useful syntactic sugar. But it still fails the "is it graphical?" test.

As for the question of the Invoke nodes being graphical implementation of C++ classes... no, they're not. The Invoke nodes are elements of the diagram that invoke code somewhere. The code they invoke varies from hierarchy to hierarchy. But none of them are a direct reflection of C++.

[TCPlomp]

---

@Aristos Queue wrote:

This is a fascinating tangent this conversation has taken. You're the first batch of customers who has actually *wanted* the Invoke node view. In most conversations I've had, the Invoke nodes for all the other APIs are considered a failure precisely because they are text and not icons.

---

I use this feature provided by XControls!
It's very intuitive and great for VI-server like programming. Offering such an API seems quite powerfull.

Ton

[MichaelAivaliotis]

---

@Aristos Queue wrote:
> I would definitely agree that it is strange they decided to
> express "method vi's" as actual vi's instead of invoke
> nodes.  It seems like a perfect fit to model methods as invoke
> nodes.  Maybe they could add an option to express a method
> as either one in the future.  I mean... it seems like invoke nodes
> are a graphical implementation of C++ classes inside
> labview... are they not?

This is a fascinating tangent this conversation has taken. You're the first batch of customers who has actually *wanted* the Invoke node view. In most conversations I've had, the Invoke nodes for all the other APIs are considered a failure precisely because they are text and not icons.

---

People may not have expressed the idea of invoke node view but I'm sure many users expected it. Why not? Every other native class in LV is expressed this way. VI server classes are expressed this way. When I first sat down to work with LVOOP, (not having read or seen anything about it before) the first thing I did was wire the object wire to a property node. Then quickly realized what an idiot I was and how embarrassed I felt. "You mean the object data is on the wire?" That's wierd.

[billings11]

I don't know, to me invoke nodes seem obvious and easy.  To me, the advantage of labview's graphical nature is the ability to implement dataflow-based programming as well as view and understand the program structure by representing it as a block diagram.  It really makes no difference whether the components of that block diagram are little squares with tiny text telling what they are, or bigger rectangles with selectable text that implement functions.  I don't know see what difference it makes as long as you have the graphical block diagram.