Need radix display to be available on rings and enums when the digital display is visible

[sbus]

It's not a BUG it's a FEATURE.... that's why I have to present it here.

When the digital display is visible on a ring or enum, the option to display the radix should be present. I can't tell if a displayed value of "401" is hex or decimal without looking at the display representation...

OK, I give - I vote that this is a BUG.

[AristosQueue (NI)]

The visualization of radix came after the introduction of setting the radix, and the customer request to be able to visualize it was specifically on the numeric text box. Works as designed, so it's not a bug. 🙂

You'd like this feature extended to other controls. That's a more than reasonable request.

I doubt that we tackle anything like this in the LabVIEW 20xx platform, but I will leave the idea open and see what kudos it accumulates. I will flag your idea for LabVIEW NXG where we are doing most of our control redesign work these days.

[sbus]

Geez. Another example of the LabVIEW engineering group proving that "we don't understand the application of factorial design to software". If you allow the user to change the display format to display an object in a different radix, you should have allowed the user to display the radix,  EVERYWHERE.

The idea that you guys implemented radix display ONLY on numerics, and only because a customer REQUESTED it on numerics, is simply a symptom of lack of vision. Isn't anyone responsible for the big picture? And I've heard "it works the way we designed it" as a final response to change requests so much it makes me sick. Stating that something works the way it was designed is a tautology - and an excuse. The real question is "SHOULD IT HAVE BEEN DESIGNED THAT WAY".

We shouldn't have to ASK to have the behavior "extended to other controls" - NI's internal software development procedures should include implementing features factorially across different object types as applicable. In this case the user can look at an object and ASSUME that since no other radix is specified it is base 10. Not a valid assumption, and one you could easily make unnecessary.

Sorry if I'm flaming a bit - but I just found out that the behavior of error rings when dropped on the block diagram (they will automatically display terminals to connect variables to for display at run time, if you embed format specifiers in the custom error text, such as "Bad value %d received from port 2.") does NOT work if you database them in an error code XML file (tools->Advanced->Edit Error Codes). So basically there are TWO types of error rings - those that support format specifiers, and those that don't. Another example of lack-of-factorial-design, and  lack of vision on the part of the development group - or, more importantly, lack of guidelines for developers to follow internally at NI, and lack of software review and software engineering management. Any engineering manager worth his salt would have said to the implementer "you're not finished - you only did it in one place, ya gotta do it EVERYWHERE". Any engineering manager worth her salt would have realized that in implementing features in a non-factorial manner, not only do you end up with a product whose behavior is not predictable and consistent  (because things that work in one place don't work in another), but they would also have realized that in NOT implementing features factorially, unexpected things happen (like creating a 2nd datatype, but not documenting, renaming, or even being aware of it; in this case there are TWO DISTINCT TYPES of error rings; but they are typed the same according to the documentation, the name, etc.). A similar situation is true for the behavior of the runtime version of LabVIEW as compared to the LabVIEW development system - some functions supported in LabVIEW are NOT supported in the runtime. My software engineering release procedures would have disallowed releasing features in LabVIEW until they were supported across the board, unless they were a beta preview. Not following strict implementation guidelines (and not having them in the first place) ends up introducing bugs into a system and creating inconsistencies, rather than making the product better.

Flame off.

[sbus]

And Aristos, I appreciate your willingness to include it in NXG; but the issue is not so much if or when radix display across-the-board will get implemented; it's more about the general software design methodology followed by NI's engineering departments that allows this kind of inconsistency in the first place. And the effect it has in support - telling customers "we designed it that way" as if that excuses the poor implementation.

[AristosQueue (NI)]

I agree with every principle you stated. They are principles that LV R&D strives to uphold. There are issues with actually upholding them in practice. You provide some actual cases to discuss. Thank you! Too often this sort of feedback comes in without a teachable moment attached.

Customer service training tells me I should say, "Yes, you're right. We will work to do better in the future." But since you provided specific cases, let me unwind what happened in those cases and see if you have advice that would help us do better. That doesn't work in most customer service scenarios, but in this case, my customers are also software engineers, so it seems worth trying.

The TL;DR is simple: LV has a scale problem. We constantly work on better ways to manage it, but the breadth of the platform makes it all but impossible to consider all the interactions. And sometimes even obvious interactions fall through those cracks.

An Example From This Morning: Save For Previous on Set/Map Constants

Today, I'm fixing a bug with Save For Previous on the new sets/maps. It doesn't work when you save the VI for previous if it has a wired set/map block diagram constant (resulting VI is corrupted and won't load in old versions).

How did we miss such an obvious use case? I had to dig into that question. I was in charge of vetting the testing for SFP (and most of set/map stuff). I made sure we had actual runnable and broken VIs for all the items in the palettes to use as test cases, and those passed SFP. But when I first created those, the constant wasn't in the palettes yet. When it was added later, I just verified that we had a VI that had the constant on it, and that test passed. I didn't bother to make sure the constant was wired.

It didn't occur to me that being wired would be a special case. The code that replaces a control with a label is the same code that replaces a constant with a label (they're the same part, just different rendering modes). And the control knows to disconnect wires (because it goes through the same code path as when you delete the control from the panel). But there was a small difference in the code path for block diagram constants. And so we have a bug report from customers.

Was it my fault? Yes. Am I sorry for the pain I caused customers? Yes. And yet, at the same time, I don't know how to improve the situation. I literally couldn't imagine that a test case where the constant wired vs unwired would matter. It is a lack of imagination, as you say. But at the same time, the geometric complexity of features makes keeping up with it quite hard. I'm pretty sure the last time we had an entire control evaporate during save for previous was LabVIEW classes in LV 8.2, so communal memory is weak. That was 15 years ago, and even though I worked on that, I didn't remember that there are two "replace with label" functions, one for FP and one for BD. The one for FP works on constants... if it is unwired.

I mention that example because it goes directly to what you were citing, and because I want to make it clear that I agree with your critique. Some of what follows pushes back on your particular examples. What follows is not meant to be a rejection of your critique but an inquiry: how can we manage our scale better?

Radix Visibility

The radix visibility feature was developed systemically. Notice that if you drop a Waveform Chart and then right click Visible Items -> Digital Display, then you can right click on that and do Visible Items -> Radix. Same with Thermometer. Any control that is using the same numeric subcontrol part now has a Radix part.

So what happened with the enum/ring?

1. Well, first of all, until this thread started, I didn't even know there was a feature to turn on a digital display for an enum. I've never used the feature. So if I were the senior architect doing the feature review, I wouldn't even know to look at that. That's our first scale problem: the platform is large enough that encyclopedic knowledge of all possible interactions isn't known by any single reviewer or even team of reviewers. We've missed many interactions over the years because we just didn't know that a feature even existed.
2. Second, the enum's digital display was implemented differently from the digital display for the other controls. Now, you can say, "That's just an earlier example of not doing things consistently." And you're right. But it is an example that is 20+ years old, long before most modern software engineering practices were in place. The enum's digital display is not the same subcontrol as the numeric. Someone made the call long ago to use just the text block of a numeric, without the next layer up (the part that includes the inc/dec, radix, etc). Finding and refactoring those when we build the next layer up is non-trivial. So that's our second scale issue: differentiation over time.
   
3. But -- hold on... maybe that difference was *deliberate*. I started poking around and realized there's a big difference between the enum digital display and the thermometer digital display. Go right click on an enum's digital display. Look at the Visible Items menu. You see a bunch of items... all of which affect the *enum*, not the digital display. If you click on the digital display of the thermometer, you see items that affect the *digital display*.
   
   Is that correct or incorrect? The decision predates my employment, but I suspect that this decision is deliberate -- someone felt that the digital display is more just a part of the enum than the digital display on either the Chart or Thermometer, and you're right-clicking on the control as a whole, not just the digital display. So they *consciously* didn't make the digital display be the same part.
   
   So that's our third scale problem: the correct way to composite features isn't always clear, and sometimes inconsistencies are actually desirable. Whether it was desirable in this case is debatable, but there are clearly cases where it is desired.

Given all of that, when the visibility was added to numerics, adding it to the enum ring is not likely to be implemented. We wouldn't know about the feature to even test it. If we did discover it, we would have to override past UI decisions that may have had very good basis. If we did choose to override, it is now a *breaking change* for all scripting code that uses enum digital displays!

So, should we fix it or not? Is the consistency so important that we reject making radix visible on all controls because it cannot also be done on enums without a breaking change? Or is the discontinuity worth the value of a feature on the much more common case of plain Numeric controls?

Those are the questions that have to be evaluated. And when I say that it works as intended, I mean that the complete composite of independent decisions has resulted in a distasteful result.

That's a scale challenge that is really hard to compensate for. It's been a huge challenge for NXG as we try to maintain all the implied dependencies within LabVIEW while fixing the frustrations.

Error Ring

The error ring is a more interesting case because that was all my work. The error ring was largely written in the wake of the first CLA Summit, whose topic was error handling.

The decision to not handle % codes was deliberate.

Take a look at error code 1078 in the LabVIEW range. It has an embedded %s in it. This was clearly a case that I had to contemplate when writing that node.

The error code text files are not LabVIEW source code files. They don't get compiled into the VI. They are external dependencies -- deliberately, because that allows them to be localized and we will display the appropriate text when we load.

Now, the question is -- if the number of terminals currently on the node doesn't match the number of % codes in the string, should changing the error code text file cause a block diagram to recompile? Should a changed string that adds a % code break a VI in the IDE? Should it be a panic stop or a runtime error in the runtime engine?

After a lot of back and forth with various people, I decided to not include the feature of substitutable % codes in error strings. The behaviors that would be expected -- triggering recompiles of caller VIs when those strings change -- were too strange, in my opinion, for the relative value of the feature. That's not the same as saying, "Impossible," but it is borderline.

That means there's a difference in behavior between the custom strings and the built-in strings. That difference is one that I made the call to say was the better trade-off.

But the problem is -- as you noted -- it frustrates users. You're not the first to ask for that. How should I have clarified to users not only that the feature wasn't present but that it was deliberately left out (and why)? The design decisions that go into our features are often quite hard to communicate, and I have no idea how a UI should communicate, "Yes, I know you'd like to do that, but it would actually contradict this other feature that you've told us you value more." In this case, the independent variability of error code text files contradicts the ability to add/remove terminals based on embedded % codes.

Summary

A platform at the scale of LabVIEW is hard to manage. The dev team size is confidential info I'm not allowed to disclose, but I know from questioning people that we are way smaller than most users estimate. If you have recommendations for how to handle these situations better, I'm definitely interested, as is the rest of the R&D team.

[AristosQueue (NI)]

In case you can't tell, you happened to hit on a fairly significant personal concern of mine as a principal architect. It's something I worry about a lot.