LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

[LabVIEW Bug Report] "Create All Constants" fails to create constant for controls when mixed with indicators

Solved!
Go to solution

@natasftw wrote:

@X. wrote:

Creating a cluster constant for one.

 

I am just pointing at the fact that this shortcut menu does not do what it says it does (Create ALL constants).

You don't want to learn exception to rules, but instead assume that a function does what it literally says it will do.


[...]

Looking through this thread, it's taken several posts to get through the point you'd want to see this renamed rather than the functionality changed. 

[...]

There's also context.  You cite younger LV users as the reason this should be changed.  Do you know many young LV users that are creating cluster constants?  Most are mystified by constants of any kind.  (I'm not saying there are none that do.  But, we're looking at the exception to the rule, yet again). 


Regarding your fist point: no I did not want to have this function renamed. I was questioning the logic behing the result. It seemed that a NI developer (or support engineer, I don't know) was willing to rename the function to not have to modify anything to it. I said fine, but pointed out that there was still inconsistencies. This is the way discussions go.

 

Regarding your second point, you are extrapolating. I mentioned beginning users because I would think NI might be interested to not put them off too rapidly, but I may be wrong. Maybe NI engineers are developing stuff just because they think that is cool or makes the language more respectable to "real" computer scientists? As a matter of fact, while not a beginning user, but I occasionally get put off by some of LV's quirks. 

 

My example of a cluster constant is just that, an example. I was not aware that selecting indicators and controls simultaneously was frowned upon in higher circles.

Message 21 of 23
(564 Views)

The effort required to right-click and choose "remove case structure" isn't any more than the effort to rename.  That's not a discussion of wanting to avoid the effort of modification.  It's more a conversation as to which one makes more sense functionally.  Personally, I'm in the boat that says it makes more sense the way that it works currently.  That's why I asked for the use case.  I wanted to understand your position.

 

From there, it has nothing to do with higher circles.  A cluster is either a control or an indicator.  It can't be a mixture of both.  In order to get it to behave in that way, you start bringing in variables or property nodes to update things to make it appear as a mixture.  I was merely pointing out the single use case you provided isn't really a strong example if you wish to show something consistent.  It is just an example, yes.  But, it's also the example you chose to show as the single example to explain use cases for the functionality.  I'm sure we're all put off by quirks in any environment we use.  It's the nature of something built for a wide audience rather than an individual.  I was just pointing out citing the user that isn't likely to be doing what you're pointing out isn't exactly a strong point.  It's very unlikely to put anyone off if they never see it.

 

But, that last line is exactly why you get pushback.  It comes off as incredibly condescending (whether intentional or not).  If I were the developer, do you think I'd have much value in your opinion when you clearly have none in mine? 

 

Here's a question I'm curious to your answer: What percentage of the time do you believe someone wants to have a hanging constant created along side a group of constants wired to indicators?

 

Another, taking a look at your cluster example, it's likely pretty annoying those constants get wired into the indicators.  We want to move them immediately over to the cluster constant.  Doing so creates broken wires and extra steps.  Should we also remove the wiring functionality to make this example work better?  If not, do we have another example use case where we'd want to create a hanging constant for the controls?

0 Kudos
Message 22 of 23
(555 Views)

@natasftw wrote:

 

[...]

Another, taking a look at your cluster example, it's likely pretty annoying those constants get wired into the indicators.  We want to move them immediately over to the cluster constant.  Doing so creates broken wires and extra steps.  Should we also remove the wiring functionality to make this example work better?  If not, do we have another example use case where we'd want to create a hanging constant for the controls?


I agree that, if anything, there should be an option to not have newly created constants attached to their (indicator) terminal sink, but this is a different situation.

This being said, this would need to be an option, and this is were I demonstrate that I care a lot for the opinion of NI developers,  because the same function is used to create constant from VI inputs. And usually, in this case, you want the constant to be wired to the connector.

0 Kudos
Message 23 of 23
(551 Views)