Duplicate of https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-the-default-probes-smarter/idi-p/937728
The probe display in labview is currently really small and there is no way to resize it.
Resizing the window results in a lot of unused grey space and the actual value being displayed can easily be truncated or just difficult to view properly.
The ability to resize portions of a development envirnoment has been around fora very long time, why does lab view not have such a basic feature?
While it is a bit annoying that the default probes are not resizable you have to give credit to NI for allowing custom probes to be created. I am not aware of any other language IDE that allows you to create custom probes for their debuggers. Custom probes are quite powerful in that they can do more than simply display the data. You can actually do something with the data which can be useful for debugging in some cases.
Well I voted for the related topic of resizeable windows, I agree that all dialogs that display data should be resizable.
Regarding other languages....
I have created the equivalent to custom probe in the past using C# and it's immeidiate window, it was easy to do and allowed for an interactive debug session and didn't tkae long to do since I was able to reuse some of my display code. So yes while custom probes are good thing to have, the default probes should have a larger display.
I just found an option in the VI properties to allow resizing of the elements on the front panel propotioanlly to the size of the front panel.
I now see no reason why this feature can not be applied to the probe display since they already have some code to do so.
<rant> Sometimes NI seems to be lost in pointless development such as a new splashscreen with twitter messaging and Facebook login (I am pushing it but you get my point) while antediluvian annoyances (admittedly not much fun to work on fixing) continue to bug users version after version... Supposedly the kudo system was aimed at reframing priorities, but we have been told countless times that it's not really serious after all. I take this forum mostly as a venue to vent out some frustration, but I have stopped expecting it will be followed by any practical results. I recently asked an NI employee who had filed a CAR FOUR YEARS ago regarding a major problem with DBL indicators, what is going on with this bug which is still not fixed after 4 versions? I was kindly told that "This CAR (#117387) is not forgotten. Naturally, we have many priorities and we continously evaluate which bugs get fixed in each release of LabVIEW". So there you go.
The only time when you seem to be able to have an impact is during beta testing, but that's mostly for glaring flaws in NEW features. Trying to point at old bugs/features seems to go nowhere... There are exceptions, of course, as always. </rant>
I did a similar rant about the NI whitepapers. an NI rep sent me a link to a whitepaper which was meant to explain a topic and how to use it. it turned out the white paper went off in all sorts of tangents rather than sticking to the topic. Compare this to something like Matlab or the MSDN website and then we find that labview just really is not a very good programming language and the documentation just is not as good it should be.
It's shame to here that this forum is ignored and is just a marketing tool for them.
Now *you" are pushing it... LV is a great programming language! It just has its limitations and NI obviously has different priorities that a fraction of its user base. For instance, I can understand that they focus on solving driver bugs first and iron out "cosmetic" glitches last.
What is sure is that the CAR system is not an appropriate bug reporting system and what NI offers as bug reporting is not adequate. Maybe worth a suggestion, if it has not been done already? They' ve got to have something internally!
> ...what NI offers as bug reporting is not adequate. Maybe worth a suggestion, if it has not been done already?
How about this?
I assumed there was one. Kudo-ed. NI's silence on this one speaks volume...
I agree wholeheartedly. The default probes are not user friendly, and it should not be necessary to solve this by making custom probes. That's why I posted this one a long time ago:
...in which you can find yet another comment by AQ about the way NI sees this going.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.