"Search Results >> Go To" tentative Bug Report

[X.]

Start from the following simplified situation:

Then go tho the Numeric Control terminal and right-click>> Find>> Local Variables.

The Search Results window should show this:

If you double-click any of these two occurrences, LV will bring you to it.

Now change one of the Numeric Control local variables into a String local variable (simply left-click on it and select String from the drop-down list.

You'll get this:

Now check the Search Window again (don't do a search, just go back to it).

It hasn't been updated!

If you double-click on the second "Write" item in the list above (which does not exist anymore, since it is now a local variable associated with String), you will be brought to...the String local variable:

Brings you here:

I would have expected something similar to what happens in the Search Results window when you delete an object, that is, the occurence of this object in the Search Results window becomes grayed out, like this (check item 2):

which proves that the Search Results window CAN respond to user events happening in some other windows

Now, are you ready for the best part?

OK, so if I Undo the deletion of the local variable on the diagram (which I did to obtain the snapshot above), what do you think happens?

Well, obviously nothing, to be consistent with the previous lack of update of the Search Results window... or wait... it did actually react to a deletion, but it does not to an "undeletion"?

So now we have two "Numeric Control" write local variable on the diagram, but only one is accessible from the Search Results window (same snapshot as above).

I tried the usual black magic Ctrl-Run Arrow trick, but to no avail.

I'd say it is a bug.

Tested in LV 2013 SP1 W7-64

[SkyWalka]

What's the behavoiur when you close out of the window and reopen it?  Do the values update properly?

[X.]

Not sure what you are getting at... If I close the search window, I need to perform another search, and of course it will find the correct objects.

But that's not the problem here.

The problem is that this kind of changes is not registered by the Search Result Window, while it should (at least in my very humble opinion of non-power user who doesn't know what he is doing most of the time).

[X.]

OK, maybe I should state the obvious, and why it is not a solution to simply restart the search (close the window and reopen it): it will unselect all the ocurrences of the object I am searching for, therefore leaving me uncertain of which one I have checked out and which one I haven't (and in the case of the scenario I was describing, which one I have changed into another local variable).

Let me also be very clear about what I am looking for: not for a workaround but to have a CAR filed for this issue.

[JÞB]

The easy work around is "Stop writing bugs"

Again, how many users are going to encounter this?  Developers only see this if they .... well, write a really bad bug where they need the search tool to find local variables linked to the wrong data type!  and a re-search fixes it!

I thought I had made every mistake possible writing source code in LabVIEW.  and most of them in deploying solutions! 

While I agree that this search behaviour could be improved------ why?  

(New style numeric constants) comes to mind. 

Give me what I need to train developers to develop good code and deploy those solutions.... Forgive my developers for some of the most common mistakes... make the RTE bulletproof.... Chastise me when I do foolish things.............oops you linked a local to the wrong item.... should search fix it all or meerly try to keep up with you?  I'm OK with it trying to keep up.

[X.]

I have no clue what you are talking about, but at least 2 people do, which I guess is reassuring...

Are you saying: stop writing bug REPORTS? Because I don't see using local variables as a creating a potential bug.

The example I have provided is for illustration purpose.

My use  case was different and more serious: I was refactoring my code and needed to find out where a local variable for the Control I was modifying, was located in the code. The fact that the Search Window did not pick this change by graying out the case where the wrong local variable was picked is potentially creating a bug in my code.

Which is not helpful.

Do you have other links you want to share?

Please use the free space below.

[RavensFan]

Jeff is saying to stop creating code in LabVIEW that has bugs.  The steps you undertook to come across this bug within LabVIEW itself are very unusual.  You created a local variable of the wrong data type.  Then you needed to search through that code for all the instances of that local variable and need to replace it with a local variable of another data type.  As a result, the search dialog box just didn't handle its updating as cleanly as you would've liked it to.  If you didn't create a bug in your code where you used the wrong local variable, you never would have needed to do the search and replace that you did.

In order to stumble across the LabVIEW bug, you had to create a certain set of circumstances that no ordinary LV programmer has ever seemed to done.  There is a reason why this particular LV bug has never been discovered before.  Using the wrong local variable and needing to replace it with another this not that uncommon.  But using the wrong local variable that is one datatype such as numeric and then needing to replace it with another of a different datatype such as a string, especially much later that you need to use the search function to find them all, normal people just don't do.  Usually, you figure out you have the wrong variable when you see you have the wrong datatype and it doesn't wire up to the rest of the code the way you might expect without broken wires.

I'm sure NI appreciates you finding bugs and reporting them.  You seem to have an uncanny ability to find bugs that nobody else seems to come across.  More than your fair share.  I don't know why that is.  Somehow I think you have a different mentality than other programmers that leads you down paths that others just never think to do.  Whether that is a good thing or bad thing, I don't know.  NI takes notes issues CAR's and evaluates them and tries to fix them as they can based on priority, scheduling, resources, ....  They aren't going to be able to fix things as quick as you might like them too.  And if it is  bug that is not significant, or not affecting a lot of people, or has a viable but perhaps inconvenient work around, then it is going to take them much longer to get to fixing it then a major, showstopper bug that affects everyone with no workaround.  It might even take years.  But you seem to have developed more of a negative attitude such as "I can't just believe NI allows this bug to exist in their code that obviously has existed for years"  for bugs such as this that I don't think anyone before you has ever come across before.