ni.com is experiencing intermittent service disruptions.

Support teams are actively working on the resolution.

LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
ouadji

Debug mode - Radix

Status: New

 

         in "debug mode" (retain wire values), be able to choose the "radix"

 

                something like this:

 

                toto.png

 

           yes, I know the custom probes, but I'm not talking about that. .
It would be nice and useful to have this in the native behavior of LabVIEW
                                        sorry for my poor english, i do my best

7 Comments
JÞB
Knight of NI

yes, I know the custom probes:

 

"Smart Probes" were added to LabVIEW 2015.  Are They "Smart Enough?"  Maybe- Maybe not... Stand BY!  The free 8-Ball TK will address some of that when I release it.  

 

Some things I do not want NI-R&D using their limited resources to do.  Like, these custom probes that are easilly added as extensions to the IDE by any developer with sound experience.  Let NI R&D focus on the stuff we can't easilly touch (Like making it easier for us to add extensions we want!)


"Should be" isn't "Is" -Jay
GregSands
Active Participant
Jeff, I think this idea is not talking about probes at all, rather the values that show when "Highlight Execution" is turned on. As far as I know, there's no way to hook in to this and alter the representation of the values shown, and ouadji is asking for that to change. I'm not voting for it at the moment though. My worry is not this small idea on its own, but where it may lead - string representations, ways of displaying arrays or clusters or classes etc. That's likely to make slower what is already a slow display, and I think smart(er) probes is a better way to address that. But I'm willing to be convinced otherwise.
ouadji
Trusted Enthusiast

@ GregS : " Jeff, I think this idea is not talking about probes at all, rather the values that show when "Highlight Execution" is turned on "

 

It is indeed what i meant to say. (thank you Greg)

 

 

JÞB
Knight of NI
OK, I stand corrected. Kudos

"Should be" isn't "Is" -Jay
AristosQueue (NI)
NI Employee (retired)

The request is interesting, but I have a sense that it would be useless in practice unless the request is adjusted slightly.

 

If you are watching the execution highlight values, you often need to see them flowing through your program and you're often checking to see if two wires have the same value. What this means is that if one wire needs to be hex, you probably want more than one wire to be hex. In the picture accompanying the idea, if that input wasn't a constant but was instead a control, you'd probably want to see that value displayed in hex so you could compare before and after the increment.

 

Clicking on every little wire is going to be tedious, and there's no way to show on the diagram "hey, this setting has been changed." That sort of "the diagram has behavior coded into it that isn't visually reflected" is something I strongly dislike.

 

So what if we said this feature was only for typedefs of numerics (or clusters/arrays containing numerics), and the wire of the typedef would use whatever radix was set in the definition of the typedef? That way it would be possible to set this once for the type (in the definition)... something you've probably already done if this is a numeric value that you commonly want to view as hex/octal/whatever.

 

Thoughts?

GregSands
Active Participant

Applying it to typedefs makes sense to me, I could vote for that.  I'm assuming it would use whatever display format is set?

 

It would be good to also include units which are part of a typedef (also, it would be great if the value displayed in the probe watch window would also use the typedef formatting).  

 

Would you also include strings (hex or '\' display)?  Maybe there'd be less call for that.

AristosQueue (NI)
NI Employee (retired)

>  I'm assuming it would use whatever display format is set?

 

That was my thought.

 

> Would you also include strings (hex or '\' display)?  Maybe there'd be less call for that.

 

Seems like a reasonable suggestion.