LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
X.

Subdiagram Label Size (VERY ANNOYING) Bug

Status: Completed

 Fixed in LabVIEW 2015 and later.

If you elect to show the subdiagram label in a structure (say a Case Structure), you're bound to be hit by the "All subdiagram labels shall resize to the same height" bug. Can't figure why nobody has reported it yet...

 

Take this example:

 

ScreenHunter_001.jpg

 

Now I switch to the other case, where I start a novella of a comment:

 

ScreenHunter_002.jpg

 

When I switch back to the previous case:

 

ScreenHunter_003.jpg WTH?

 

When I first encountered this bug, I thought OK, let me resize the label... like this:

 

ScreenHunter_004.jpg

 

Guess what? Here is the other case's reaction:

 

ScreenHunter_005.jpg

 

That's just great...

The weird thing (which might be the reason nobody picked up the problem before), is that if you start with the long comment

 

Don't get me started on the other "feature" according to which the structure will grow if it needs space to create the label without overlapping objects in it EVEN WHEN YOU HAVE TURNED OFF AUTOGROW...

 

I am attaching the LV 2012 VI I have used for this demo... as well as a link to a video illustrating the problem.

13 Comments
fabric
Active Participant

I agree that the implementation of subdiagram labels is pretty buggy. Resizing lables in different cases seems to have mixed behaviour for me, i.e. sometimes other cases are resized too and sometimes not.

 

I also agree that "don't auto-grow" should be honoured. 

 

...but I don't lose too much sleep over it. After all, my code comments itself.

LordNobady
Member

@fabric

that is the most heard mistake. ( exept perheps I dont have to test I know it works ) 

I like this idee.


Learning LabVIEW since January 2013
fabric
Active Participant

@X. wrote:

 

blah blah blah 


Oh - and I believe it is the custom in these parts to mention an idea somewhere along the way. Smiley Tongue

X.
Trusted Enthusiast
Trusted Enthusiast

Idea: look at the bug and consider fixing it.

 

Note: my post got messed up somewhat, with an interrupted sentence where I was explaining that the reason NI did not pick up the bug was that, as I am showing in the video, the label size is adjusted to the text dimension if the text is shorter than the box you start typing it in (for instance the "no comment" label has initially plenty of extra space, but once you finish typing - the first time! - the box is resized to a more reasonable dimension. However, any further edit is not followed by such adjustment and this is the problem

 

...and maybe add a spell checker to the label editor for us bad speller.. although that probably would open its own bag of worms...  🙂

X.
Trusted Enthusiast
Trusted Enthusiast

Just for the sake of completeness, I wanted to add that I have found a kind of workaround for this problem: color the label transparent. Now of course it does not remove the label and if you try to drop objects over the location of the label, whey will just go in netherland (go "poof" in other words).

HOWEVER, if you drop the objects outside of the label and then moved them over the label, things are just fine:

 

ScreenHunter_001.jpg

 

Just remember that if you color the label non-transparently, this is what you will get:

 

ScreenHunter_002.jpg

 

And of course, whether or not you have colored the label transparent, if you retouch it (in particular expand its size, it will most likely play tricks with your subdiagrams and try to avoid overlapping objects with the label. For instance, in the example above, I am forced back to that situation:

 

ScreenHunter_003.jpg

 

Not a really robust workaround, but sometimes helps with handling long labels...

 

ouadji
Trusted Enthusiast
SteenSchmidt
Trusted Enthusiast

This should've been an ordinary bug report instead of in the ideas forum.

 

The thing about objects being visible or not when the label overlaps them is dependent on object order. It's nothing mysterious, just reorder the object layers if you get into trouble with it.

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
JÞB
Knight of NI

X, By implemnting this you allow tunnels in the sub-diagram label area and hide the "Keep-out" zone on the border for cases where there are short comments. 

 

Just to really rile up the masses I'll go ahead and mention that this would completely break the Right Click Menu option "Replace Case Structure with Stacked Sequence."  We don't want to go breaking that now do we?Smiley Surprised 

 

Usually you are spot-on but, this time you didn't think it all the way through.Heart


"Should be" isn't "Is" -Jay
X.
Trusted Enthusiast
Trusted Enthusiast

I should have presented it for what it is, that is a lousy workaround. I am the kind of guy who doesn't mind hiding stuff behind a big sequence structure, so a transparent label is not a big deal... And BTW, NI should prevent me from doing what I showed in the first place if there is such a commandement somewhere against this kind of anathema.

Daklu
Active Participant

I can see how that would be annoying, but I'm not sure I would call it a bug.  Thinking about how I would have implemented the feature, the easiest way is to create a single label element that is reused for all cases and just swap out the text.  If each case has its own size, you'll either need to create a unique label element for each case or resize the box every time you switch cases.  Both of those use more resources.  (I'm not claiming they use significantly more resources, but there is truth to the saying, "a penny here, a penny there, and pretty soon you're talking real money."  That may have been one of the considerations in the original implementation.)

 

What struck me most about this idea is you are using the box for detailed comments.  I believe it is intended to be a short label.  If you want to put detailed comments in why not just use the comment box?