From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

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

Right/Left Justify Local Variable Text

Status: Declined
See AristosQueue's comment below for technical reason. This is valid feedback but something that will require a larger investment. We have logged your feedback and will use it to correct the issue in feature releases once the investment is acquired. Since this won't be implemented in the next release (2014), I'm going to decline the idea for now but it has still been acknowledges and logged within R&D to get worked on in the future.

If you have a local variable and you either rename it's control/indicator, or you click it to change it to refer to a different variable, all local instances resize based on a centre justified behaviour, which can have undesireable layout issues.


For example here is a what happens when it's made longer next to the bounds of a case structure.
(The Boolean is provided to show how it's aligned, and also to show it resized the case structure).

 

 Screenshot

If the local variable were Left justified as a 'Write' type (expands to the right when changed) or Right justified when a 'Read' type (expands to the left when changed) it wouldn't make such a mess of things!

 

3 Comments
Thoric
Trusted Enthusiast

I think this might be better suggested as "For objects with single terminals that increase their block diagram widths automatically, ensure the terminal node remains fixed". As the read locals have their terminals at their right side, and conversely the write locals have a terminal at their left side, keeping these locations fixed would achieve what you require. This approach could then be applied to virtually everything with a single terminal node that could ultimately change size automatically.

Thoric (CLA, CLED, CTD and LabVIEW Champion)


AristosQueue (NI)
NI Employee (retired)

I took three hours to work on this today. I am unable to change this behavior without significantly more effort, and the idea doesn't seem to warrant that level of refactoring.

 

Essentially, there's a comment in the code that says when the text changes, it is ok to change the bounds, but the terminal hotspot has to remain where it is... this code apparently can be called at times when we can't do any wire stretching operations. Thoric mentioned that the terminal for read is on the right and the terminal for write is on the left... that's not actually true. The hotspot for both is in the dead center. Wire a node and then triple click to select the whole wire -- you'll see the selection lines going all the way into the heart of the node. If I can't move the hotspot then I would be growing the bounds to the left or to the right and letting the hotspot slowly drift off of the node's center. That's actually ok to do from the standpoint of the node -- it doesn't care where its hotpoint is, but it would be fairly weird visually to have this slowly drifting hotspot. It would also mess up folks who like to wire out of the bottom/top of local variables.

 

I could probably find a way to post a wire stretching update, but the amount of work involved in fixing this is rapidly increasing, as is the risk level. I don't get a whole lot of time to work on these long-tail feature requests, and I just can't see spending much more time on this. Moreover, it seems like this same sort of behavior change would be needed for enum constants, property nodes, and other nodes that grow when text changes.

 

I can't fix it today. I think this is something that will have to wait for a more substantial UI rewrite that addresses lots of shortcomings of our nodes today. There is already a much larger idea afoot to do a more general rework of LabVIEW's diagram that would encompass this. Because of that, I'm going to decline this idea. Sorry.

 

G-Money
NI Employee (retired)
Status changed to: Declined
See AristosQueue's comment below for technical reason. This is valid feedback but something that will require a larger investment. We have logged your feedback and will use it to correct the issue in feature releases once the investment is acquired. Since this won't be implemented in the next release (2014), I'm going to decline the idea for now but it has still been acknowledges and logged within R&D to get worked on in the future.