Conducting a peer review

[RS_233]

Yup, it's that time of the development cycle.  Here's my question.  In C++ if you see a problem, you just say foobar.cpp line 410, you're using a redundant for-loop.  In a text-based language, it's rather simple to pinpoint exactly where the problem resides by just saying the line number.  However, I can't really do the same in LabVIEW (at least I don't know of a way.)  I know that when I move the scroll-bars with my mouse (bottom and right), I will get the little bar at the top saying origin (-401, 234), is there a way for me to get the same level of precision from my cursor?  It's much easier to to say: In foobar.vi 20, 319, you're using the wrong sub-vi.

I'm using LabVIEW 8.6.

[RavensFan]

Are you talking about putting some debugging information in your error messages?

I don't understand what the cursor position as to do with your error message.  You can't identify subVI's or functions by a particular position on the block diagram.  The block diagram is a visual representation of the code only meaningful to the programmer.  It has no meaning whatsoever to the compiler.  The compiler converts the block diagram layout to something it understands.  You could comnpletely rearrange your block diagram and wind up with the same compiled code.

If you need to put additional information in your error messages in pop up error dialogs, then you can modify the source text box inside the error cluster to add some additional information.

[RS_233]

There is no error message, the code runs without any compiler or obvious run-time error messages (I don't think I said that I'm getting an error message.)  I'm talking about when you conduct a peer-review (as part of the development process), you need to be able to point the developer where you (the reviewer) thinks is a flaw or a better way to do something.  This is trivial in text-based programming languages, since I can just say go to foobar.cpp, line 410 and the developer knows exactly where I'm talking about.  There are no lines in LabVIEW, the best that I can do is point the developer to the VI and say "top-left of the block diagram" (or in relation to other components), which is extremely imprecise and vague.  I would like to be able to just get a set of co-ordinates from my mouse cursor so that I can use those to point the developer into the exact location in the block diagram where I think there is a problem, without any guess-work.

[RavensFan]

I understand now.  I was thinking error messages is because the only time I see .cpp error line ### is right before LabVIEW development environment crashes on me for some reason.

What you could do, is turn on labels for important sections of your code.  So turn on a label for a SubVI and edit the label to something unique.  If you have a Build Array, that is what it will say when you make its label visible.  You could edit that to say Build Array100, to distinquish it from Build Array 101 somewhere else nearby.  It would show up on screen and on printouts.  And it would maintain that name no matter how the block diagram would get rearranged.  Of course it would take some diligence on the part of the programmer to assign and modify these labels.  But it might be possible to do some scripting to browse through the block diagram items and assign some unique modifiers to the various nodes and ensure the labels are visible.

[DFGray]

Screen shots work well, especially with annotations added.  Large block diagrams could cause issues with this - yet another reason to keep them small.

There is a fair amount of free software better than Paint to graph screenshots and annotate things.  I use GIMP, but it is a bit complex for the casual user. A search for open source bitmap editors should give you lots of options.

[Darin.K]

---

DFGray wrote:

There is a fair amount of free software better than Paint to graph screenshots and annotate things.  I use GIMP, but it is a bit complex for the casual user. A search for open source bitmap editors should give you lots of options.

---

The Code Capture Tool comes to mind.

[hecmar.arreola]

---

DFGray wrote:

Screen shots work well, especially with annotations added.  Large block diagrams could cause issues with this - yet another reason to keep them small.

There is a fair amount of free software better than Paint to graph screenshots and annotate things.  I use GIMP, but it is a bit complex for the casual user. A search for open source bitmap editors should give you lots of options.

---

Paint.NET (Windows only) is a good alternative to GIMP for this.

As for the 'yet another reason to keep them small' comment - OOOORRRR you buy a larger screen (or have your boss buy you a larger screen) :P!  In all seriousness that is one lesson I had to learn the hard way.  Now, I keep my code all within 1 screen and if it extends beyond that I rethink what I'm trying to accomplish.

[blawson]

one possibility: the reviewer could put comments right on the BD.  Perhaps use a free label with a special background color.  Use a unique tag in the label. Then you can find all of these comments by searching for the tag text on block diagrams.

more complicated but faster to find: create a broken subVI and drop it on the BD where you want to call attention.   Then you can find these "comments" using the List Errors window.

[RDR]

I use free labels when going through a review with a unique tag to distinguish these labels from other text in my LV code.

For example, if you create a label during your peer review (double-click on empty space in the BD) and start each of these free labels with "Initials-EDIT: ....." you can then go back later with Edit > Find & Replace (text search) and search for all of your edit notes by searching for 'Initials-EDIT'.

Message Edited by B O B on 02-22-2010 04:38 PM

[Guruthilak]

Thats exactly what i do... I just add a label "Guru(reviewer Name):and the comments" wherever the attention is required so that the developer can search for "Guru(reviewer Name):" in the entire hierarchy and make required corrections.

Guru