NI: Get to grips with Fundamental LV Shortcomings.

[tst]

---

@tbd wrote:

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.

---

How about this?

I can't find a link at the moment (maybe it was explained in person), but one good reason not to have a simple access to the class data values is that using accessor VIs allows you to do range checking etc. and keeps the class data protected. You could probably create an interface which would allow doing this through property nodes, but it would be a bit complicated to handle (you would need to match the names to VIs).

---

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. 

---

I meant that they are nothing like the others in the sense that they are not by-ref, not that accessing them through the property node interface is a bad idea. In fact, I thought it was a good idea a year ago.

Here, Stephen, now you have two users who sometimes prefer text to icons. The property and invoke nodes don't always work very well (for example, when using the nested .NET or ActiveX hierarchies), but they have the advantage of being much easier to understand for those who know the language they're in.

[tbd]

> billings11 wrote
""
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. 
""

Hi Billings11, Read your entire post with great interest, partly due to having second-thoughts (see the section you quoted) - perhaps now is exactly the time to take the plunge into LV 8.5 - before this new app is distributed.  A co-worker recommends 8.5...
But the other reason for scrutinizing your post is that my app is also a test-sequencer! :smilyveryhappy: (People are shaking their heads and saying - you fools! use TestStand!  but they're just jealous because of the fun we're having!)  This "test-engine" launches parallel test-threads via heavy use of reentrancy. <queasy glif goes here>

> Aristos Queue wrote:
""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.""

Your experience may reflect NI's success in giving "text" a bad name!  Of course in "G" subroutines/functions must be 2D - does that imply value-identifiers ought to be be hieroglyphics?  Personally, I like syntax that employs text - good terminal-labels, bundle/unbundle by name, enumerated-types (especially when wired to case-selectors) and property nodes.  IMHO, these elements provide clarity while reducing - even eliminating - a need for (dreaded) comments.

As I understand your post, a LV-class method might have been selected exactly like selecting the method of any other more familier class object (VI-server, AX, NET, etc), but that form of method-selection was deliberately avoided because the invoke-node doesn't look like a VI, it's not what the people you spoke with wanted, and it violates an important tenet - the '"is it graphical?" test.'?

I saw your comment about text of different [world] languages being inconvenient to accomodate, programmatically-speaking, but seems there's also a strong tendency among LabVIEW designers to move away from anything "text" - in a prejudicial sort of way.  Having removed the text from primitives, do the designers have their sights on removing any other forms of text present in "G"?  I'm really concerned about existing source-code becomming less readable as LabVIEW evolves - though I don't see how it would be possible, except, maybe, enums becomming pict-rings.

> > > > > 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.
> I can't find a link at the moment...

Message Edited by tbd on 10-10-2007 08:42 AM

[billings11]

tbd,

A couple years ago I had a burn-in test station app where I used my older variant-based test exectuve re-entrant-ly.  It was a 24 channel burn-in and each channel had to be independent of every other and be able to run a different sequence from every other, so it might be similar to the reentrant app you are describing.  I can tell you, if I had to do it again I would definitely use LVOOP, but I'd definitely use a patch release 8.2.1 or 8.5.1 when it comes out.  It always seems like things aren't quite right until the patch release!  But for me there is a huge memory and performance savings from my LVOOP implementation just because all that LVOOP private data doesn't get copied all over the place.

Message Edited by billings11 on 10-10-2007 09:56 AM

[billings11]

Oh by the way I've posted this before on a seperate thread, but for that re-entrant app this may interest you:

Classes can be passed on queues!

[gls]

"I'm not too experienced with C/C++ code, but I disagree that you can switch
development platform without problems.

Especially if you take into account c#, MFC, and stuff like that.

Compiling a VC++ program with GNU C++ isn't always easy (although it should
if the program follows all the c++ rules).

Regards,

Wiebe."

It shows that you don't have much experience because C# is not part of C++, they are different languages.  Also MFC is Microsoft specific, so if you code in ansi C++, it is not compiler specific.

[RavensFan]

And what is your point?

That is what he said, that he is not too experienced with the C family of languages.

[llcl]

The point would be that they made an incorrect statement.

[RavensFan]

So.  They said they weren't experienced with C.  So are you going to take their word as Gospel?

Is there a reason why you keep hiding behind newly created fake aliases every time you comment?

Please say something constructive or stay off the forums.

[altenbach]

---

@gls wrote:

It shows that you don't have much experience because C# is not part of C++, they are different languages.  Also MFC is Microsoft specific, so if you code in ansi C++, it is not compiler specific.

---

It seems pretty pointless to nitpick a single 5 year old post that is pages away from your comment (embedded in a long thread of interesting discussions!)  and most likely stale and irrelevant in the grand scheme of things. Where in the quoted post did you find a statement that "C# is part of C++"??? I don't see it. 😮 No incorrect statement was made here (at least not by Wiebe). 😉

Let's keep the forum relevant! Thanks! 🙂