NI: Get to grips with Fundamental LV Shortcomings.

[geirove]

I am not new to software. Having done my fair share of traditional, and, for the last 15 years, OO development I have used quite a few tools and

programming languages: C, C++, Smalltalk, Java, Eiffel, C# and also written my own programming langauge. The most professional Programming

Environment I have ever seen is Eclipse (Java Programming Environment) (www.eclipse.org) which again has inherited it's  powerful ideas and tools from

Smalltalk envrioments.

I have used LabView for shorter periods in several of its incarnations.  I recently finished a fairly large Realtime Control Project  using version 8.2 and the

State Diagram Toolkit. (see this thread: http://forums.ni.com/ni/board/message?board.id=170&message.id=234831).

LabView is a very powerful environment, but like most environments it has its shortcomings. And now we are getting closer to what this thread is all about:

** Navigating Source Code ** (Search & Replace  / Find References to objects / Instances)

Fundamental Search
-------------------------------
The problem is: Many of these issues are ** fundamental ** and easy to fix, but nothing seems to be done about them! I recently upgraded to version 8.5,

and expected the ** fundamental ** lack of the ability to search for references to my Shared Variables to be fixed. But I was terribly dissapointed, and to be

honest:

If a developer cannot Navigate his / hers code, she / he is not in controll of the developed software!

I have never before seen a programming enviroment that has no feature whatsoever to find References to Variables used in a Program! Unnecssary to say,

this is an absolutley fundamental tool for any programmer: In text based languages you of course have text bases searches, which are crude, but it does the

job. In Eclipse you can even search for where variables are Assigned to, or Read from! (The search is actually searching the Parse Tree).

However, there is not even a Text Based search for Shared Variables in LabView 8.0 to 8.5 and all its intermediate upgrades!
I have spent countless hours using the extremely crude, cumbersome and time waisting method of deleting the Shared Variable and thereby getting a

compliler error showing me where the variable is used: Then I have to close my project withouts saving,  reopen the project again and get back to where I

was working. None of this time can be billed to my clients.

Yes, I know LabView in the meantime has received a host of powerful features. But this is fundamental feature would take any of NI's highly qualified

developers a few hours or a day or two to fix.

So why isn't it implemented? I bet NI's developers miss it as much as the next guy.

I guess this fundamental feature does not look so good on the Marketing Peoples brochures, so they figure NI's developers should spend their time on new

features that they can promote and use to get us to upgrade: Guess what: I will wait a very long time until I ugprade again.

The LabView Search Dialog
----------------------------------------
The Search Dialog miss one important feature: The ability to Point at any VI / object in a Block Diagra, to say "this is the type I want to search for".

Often I cannot find the type I want to search for in the lists the Search Dialog is presenting.
Other times I simply do not know what the type is, and where to find it, but I am looking at it in an open Block Diagram!

Enter the StateChart Module
----------------------------------------
As I said, we used the StateDiagram Toolkit to develop our Control System: 9 Processes each running their separate State Diagram on a cFP 2120 system.

The StateDiagram Toolkit is very basic: Not able to resize any state circles or even move more than one at a time: It has been like this for  more than two

years. However, we are in control of the generated code, and could find references to my VIs in the generated code.

The StateChart Module is an implementation of the UML StateChart Implementation. Going through the Tutorial I was quite impressed.
However, yet again the lack of the ability to search for References to important Resources lets the product down:

a) Not possible to Find references to where in the Diagram any Trigger is used.

b) Not possible to Search for any used instance / object within a Diagram: Objects / Instances used within the Diagram does not even show up under the

"VIs by Name list"

c) Text Searches possible, but matches are found in generated code and ** not ** in the Diagram.
    The generated code has no link whatsoever back to the Diagram.

I will post another thread with the shortcomings I have found in the StateChart Module and some ways to circumvent these shortcomings.

Upgrades: What about Tools Developers used in previous versions?
------------------------------------------------------------------------------------------
It is very important for developers to know what happens to the tools they are already using when upgrading to a new version.
We used the State Diagram Toolkit for thje project we just finished. However, I could not find any words about what happened to this Toolkit in version

8.5! Developers cannot upgrade without knowing that tools they are using are still working.

We did not upgrade to version 8.5 during our project, but stayed with version 8.2. And I am glad we did: After the project ended, I moved the source code

to version 8.5. Everything worked and the cFP 2120 code was also running: However, the performance had deteriorated with > 33%. See this link:
http://forums.ni.com/ni/board/message?board.id=170&message.id=275320

Question: What about the Next LabView Release?
--------------------------------------------------------------------
It has taken Natioanl two decades to produce a very capable development system. However, it only takes the introduction of a few more features where the

Programmers do not have Navigation Control (ability to search & find / replace) to bring the productivity of this product down to its knees.

I certainly hope that NI in the next LabView Release concentrates on fixing these and other Naviagion shortcomings (rather than introducing features) to bring

LabView up to the Speed an Productivity that it is capable of: NI got the engineers to do it: Give just give them the time to fix the problems!

Can we please have NI's dedication to fix these easy to fix issues and thereby give back Navigational Control to us, the Developers ?

Please, I do want to continue to impress my clients with what LabView can do, in a short amount of time !

[Dave_Thomson]

   I've got to agree with your main ponits.  I particularly miss the ability to search for Shared Variables.  I complained about this when SV's first came out.  I believe I was told that the ability to search for them was in the works, but I was really disappointed when it wasn't released in 8.2 or 8.5.
   One other minor comment - I can't tell you how to bill your clients, but if my client has agreed to pay me to develop an applicaiton using a particular tool (e.g. LV) and that tool requires tedious and time-consuming steps to accomplish something required to complete the project (e.g. deleting SV's to be able to find them, then closing LV and...), I would not hesitate to bill my client for that time!

Here's hoping that Shared Variables continue to improve,
   Dave T.

[Rodnebb]

Agree to most here, I'm also annoyed by the difficulty in searching - for instance when finding where variables in a cluster is "checked in / out". Generally it seems LV's been written as a prototype language, and that most users write relatively small programs so these problems are perhaps not that big for many.

[Jarrod_S.]

This is all really good feedback. I can make a quick point about one of your comments:

"

The LabView Search Dialog
----------------------------------------
The Search Dialog miss one important feature: The ability to Point at any VI / object in a Block Diagra, to say "this is the type I want to search for".

Often I cannot find the type I want to search for in the lists the Search Dialog is presenting.
Other times I simply do not know what the type is, and where to find it, but I am looking at it in an open Block Diagram!"

If you highlight something on the block diagram, then hit Ctrl-F, then the search dialog automatically has that object as the thing to search for. Try it out!

I completely agree that searching for SVs shouldn't be so difficult, and that it is a perfectly reasonable request that it should be integrated into the product. One workaround you might consider for future projects (but that might be more time than it's worth for an existing project) would be to create a subVI for each SV that is solely responsible for reading and writing that SV. You never make a direct call to the SV in your code, you just call the subVI. Then, if you want to search for instances of your SV, just search for that subVI. Again, you shouldn't have to do such a workaround in an ideal world, but it's something that came to mind. Hope this helps!

[PhillipBrooks]

I agree with your points. There is an "unlisted" Special Interest Board" called "LabVIEW Developers Features Brainstorming" with a thread started by an NI employee to solicit input to how you might want to search from within the LabVIEW environment.

Why this forum continues to remain hidden is a mystery to me...

[tst]

That's a great tip about finding things on the diagram, Jarrod.

It should probably go into the LAVA tips wiki (hint, hint, Philip. Sorry, I'm just probably going to log into LAVA in the next couple of days and will probably forget).

---

@Phillip Brooks wrote:

Why this forum continues to remain hidden is a mystery to me...

---

Fear not, all mysteries will be solved.

[Jarrod_S.]

Another not-so-great solution for searching for shared variables in your application is to always set their Label to visible when you use them in your code. If you do that, you can at least do a text search for the variable name and you can find them. But you'd have to remember to set the Label to visible every time you add a new variable.

[MichaelAivaliotis]

I agree with many of the original points. Not enough attention is spent on improving the navigation experience for developers (us). In fact, things are getting worse. For example, I used to use the "Window" menu to navigate to my opened VI's. Not anymore. NI crippled this very usefull feature by limiting it to only 10 objects. Why?

BTW, more tips and tricks can be found in the LabVIEW Wiki: (see: LabVIEW tips and tricks)

[TCPlomp]

---

@jarrod S. wrote:
Another not-so-great solution for searching for shared variables in your application is to always set their Label to visible when you use them in your code. If you do that, you can at least do a text search for the variable name and you can find them. But you'd have to remember to set the Label to visible every time you add a new variable.

---

I've never used Shared Variable, but I think you can use the search method 'search for hidden parts'
Keep us posted.

Ton

[mikeporter]

Most of the "shortcomings" that LV exhibits arise from NI trying to placate people such as yourself who have no idea about how to go about creating a good LV-based application. In terms of specific responses I truly don't know where to begin with your points. To begin with, its clear that despite your years of experience working in other languages you don't know squat about developing in LV. For example, you start with the assumption that using dozens of named variables is a good thing! Did it ever occur to you that if you are having this hard a time with maintaining an application that there might be something fundamentally flawed in your design - no of course not - it's easier to blame the tool.

LV is an ideal environment to develop very large applications - as has been shown time and again. However, you must keep it straight that there is no correlation between complex code and complex functionality. Unfortunately, most people thing there is. They believe that to have complex functionality they need really complex code. As a result they write an incredibly bad implementation of something that is essentially a simple process. Starting from this faulty example they then try to extrapolate what it would take to create a large application and immediately assume that LV is only for "small" projects.

Mike...