LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

double-clicking on a probe on a clone should bring you to THAT clone, not some OTHER clone

I have two pre-allocated clones. I probe the same wire in both of them. I go to the probe watch window and click on the first probe.

 

At this point, one would expect and hope that the probe-watch window would send me to the wire corresponding to that probe. Instead, it sends me to the probe on the same wire in the other clone.

 

Rather than repeating the unprintable response I gave upon discovering this, I will just say, DO NOT WANT.

0 Kudos
Message 1 of 9
(4,279 Views)

It helps if you actually report it in a way that people can reproduce and verify it. See attached example LLB (renamed because of a bug in the forums) demonstrating this (LV 2013). I agree that it's a bug, but I never noticed it before, even though almost all my reentrant VIs are prealloc and I do probe them occasionally. Maybe this doesn't happen in the older versions, where I still do most of my work?


___________________
Try to take over the world!
Message 2 of 9
(4,151 Views)

If you only probe in the one clone, it also takes you to the equivalent non-probed wire in the other clone. (2014-64bit-sp1)

0 Kudos
Message 3 of 9
(4,136 Views)

It helps if you actually report it in a way that people can reproduce and verify it

 

Find some pre-allocated clone somewhere of which you have more than one instance*. Open two or more of them. Probe the same wire in each. Go to the probe watch window, double-click on each entry and see what happens.

 

* If you do not have any, create a blank vi, wire 'true' to an indicator, subvi the 'true', set its execution mode to 'preallocated reentrant', duplicate it on the block diagram it appears in, and proceed with the rest of the directions.

 

Which of these steps was not apparent from what I said?

0 Kudos
Message 4 of 9
(4,083 Views)

@LukeASomers wrote:

 

Which of these steps was not apparent from what I said?


Yes, it was easy enough in this case (see the example in my previous reply showing that I managed to figure it out), but something which is obvious to one person might not be obvious to another and there are also cases where the bug isn't actually a bug. Posting a list of exact repro steps (or even better, actual code) allows people to have a shared base to work with. This can be annoying to do when you just spent some time on finding a bug and verifying that it's actually a bug, but it's more practical and it helps other users who see your report.


___________________
Try to take over the world!
0 Kudos
Message 5 of 9
(4,077 Views)

Why did this get moved to idea exchange?

0 Kudos
Message 6 of 9
(3,931 Views)

> Why did this get moved to idea exchange?

 

I guess someone thought it qualifies as an idea, although I'm not sure why. I would say that this is a bug, because the behavior doesn't match the expectation of users (and it couldn't even be argued to be just laziness or lack of work, because the focus is given to one of the clones, not to the original VI).

 

Of course, now that it was moved, the example I attached is no longer visible. Hopefully it will be moved back.


___________________
Try to take over the world!
0 Kudos
Message 7 of 9
(3,839 Views)

Now being tracked as CAR 535453. We'll see about getting this moved to a better forum.

0 Kudos
Message 8 of 9
(3,276 Views)

OK, it was moved back and now my example is visible again.


___________________
Try to take over the world!
0 Kudos
Message 9 of 9
(3,229 Views)