Format of Variables Change When Debugging

Question

When debugging in LabWindows, the format of the variables (decimal, hex, ASCII, etc.) is always set to the default under certain circumstances.  For example if you step into a function, change format of a variable, step out then back in, the format has been reset to the default.  There are other instances when you run, stop, rebuild and debug where this is done also.
I've asked NI to explain why the variable format can't be retained, at least within one debug session (until exiting LabWindows).  The explanation is they use a stack-based system to store this information so it is lost during debug.
I find this to be an extreme annoyance and an enormous waste of time.  For example, I deal with a lot of arrays of binary data.  Seeing these array values in ASCII is of no value.  So I'm nearly constantly setting the format back to hex during debugging.
I'm curious whether anyone else thinks this is a problem.  NI knows about this, but it's unlikely they'll do anything unless there is a lot of feedback from us users on the value of fixing this.  Post a note and let me (and NI) know what you think, whether you think this is important or not.
Thanks,
Dave

Answer 1

Hi Chris,
Yes, using Format >> Preferences is exactly what I was talking about when I said "change the format of a variable".  Thanks for giving the exact details of doing this.
I'm still using v8.1.  I'm leery of renewing my service contract because I don't feel NI is listening to me (as a customer, not just a LabWindows user) regarding the issues that affect my work and ways to greatly improve my productivity.  I have been suggesting this for a few years now, to no avail, both with tech support on the phone and through your product suggestion center.
I can't explain all the intricacies of the issue.  Maybe what you have to do is set breakpoints and run rather than step in and out.  Here's what an engineer in NI's R&D center said:
It's not actually rebuilding the project that causes the information to be lost. It's actually even worse than that. As variables come in and out of scope, the formatting and the expand/collapse state of each variable is lost. So, if you've hit a breakpoint in a function and re-formatted a local variable, and then continue debugging outside the function, eventually stepping back into the function, the formatting for the original variable is reset when the item is created anew in the variable display, based on the data type of the variable.
The problem we have is that the formatting information is stored in stack-based memory which is associated with the actual items that you see in the variable display. As these items disappear and are re-created in the variable display, the formatting information is reset.
The complexity of representing variable scope information, including arbitrary block scopes, makes it pretty hard to maintain variable information in global, non-stack-based memory. It's obviously not impossible, but unfortunately it would require a fundamental redesign of our debugging paradigm.
Finally, we have heard this request from multiple customers, and I assure you that you are not the only customer who has asked for this feature.  The problem with this feature, as with many other feature requests is one of trade-off. It is obviously impossible to accept all the feedback that we receive, and so we are constantly having to weigh development costs of a particular feature, the risks involved in implementing it, and how widespread its benefits are.  So far, this feature has not made the cut. However, this does not mean that we're ignoring it, or any other customer feedback. Many customer-requested features have made it into previous releases, and we're confident that this will too, in the not too distant future. As a matter of fact, we can honestly say that most new features in a given CVI release originate with customer requests. I also just want to re-emphasize that each time you reiterate how important a given feature is, it drives up its priority and makes it more likely that we will implement it sooner, rather than later. With that in mind, we definitely welcome your suggestion to post a note about this request in the forum. We expect other people to second the request, and the more people that do that, the better.
So my question wasn't posted for NI to respond.  It was to find out if anybody else using LabWindows finds this issue to be detrimental to productivity.
Thanks,
Dave