Replace constants with icons on block diagram

[Daklu]

I'd like to see a way to have block diagram constants take up way less space. I'll create large cluster typedefs and use them to initialize arrays, with Bundle by Name, or with Variant to Data. Sometimes I'll have real values in them but usually I'm just using them as a typedef. The problem is they take too much space on the block diagram. I know I can change Autosizing to None, which I do; however, every time I make a change to the typedef Autosizing resets to Size to Fit and I have to go back and resize all my constants. I even had to turn off the Auto Grow feature because I got tired of having my block diagrams blow up.

Something like a control-sized icon specifically for constants or typedefs would be fabulous.

[crelf]

QUOTE(Daklu @ Feb 19 2008, 02:52 PM)

I know I can change Autosizing to None, which I do; however, every time I make a change to the typedef Autosizing resets to Size to Fit and I have to go back and resize all my constants.

I don't agree with replacing constants with icons, but I certainly would like to see the resizing typedef bug fixed.

[CaseyM]

Couldn't you just make a VI that only contains the type def and wire that to the output? Then you only have the VI icon on your block diagram instead of the huge type def constant.

[gmart]

QUOTE(cmay @ Feb 19 2008, 02:47 PM)

Couldn't you just make a VI that only contains the type def and wire that to the output? Then you only have the VI icon on your block diagram instead of the huge type def constant.

Yes you could and that is what many people do, but then you are adding to your VI hierarchy, could make extra copies of the cluster, and may be losing out on optimizations such as constant folding.

QUOTE(crelf @ Feb 19 2008, 02:09 PM)

I don't agree with replacing constants with icons, but I certainly would like to see the resizing typedef bug fixed.

The "bug" happens when you change the data type of the typedef. This is due to the fact that typedefs don't have a display state separate from the data state. So the typedef is reinitialized to it's default size whenever the data changes.

[jdunham]

QUOTE(Daklu @ Feb 19 2008, 11:52 AM)

I'd like to see a way to have block diagram constants take up way less space. I'll create large cluster typedefs and use them to initialize arrays, with Bundle by Name, or with Variant to Data. Sometimes I'll have real values in them but usually I'm just using them as a typedef. The problem is they take too much space on the block diagram. I know I can change Autosizing to None, which I do; however, every time I make a change to the typedef Autosizing resets to Size to Fit and I have to go back and resize all my constants. I even had to turn off the Auto Grow feature because I got tired of having my block diagrams blow up.

Something like a control-sized icon specifically for constants or typedefs would be fabulous.

My solution to this is just to drop the typedef contant into a sequence structure, and then resize the structure to something I can tolerate. If I'm feeling organized, then I also label the sequence structure with the name of the typedef. I agree it would be nicer to have a "display as icon" option. You other option is to convert the cluster to an lvclass, but I am a bit down on classes since the data is not visible on my front panels.

[crelf]

QUOTE(gmart @ Feb 19 2008, 04:44 PM)

The "bug" happens when you change the data type of the typedef. This is due to the fact that typedefs don't have a display state separate from the data state. So the typedef is reinitialized to it's default size whenever the data changes.

I assume you put the quotes there because you disagree? I know why it happens, but I still don't think that it should. Each instance of the constant retains its' size when I move it, save a VI, etc, so why does it reset when something unrealted to size changes in the typedef source? Why can't each instance remain the size it was? I assume that it's easier for you guys to have each instance simply replaced, but when you have large (real estate-wise) constants in multiple locations, it can be a real pain resizing them all. It may not be a bug per se, but I certainly think that it's an unwanted "feature".

[gmart]

QUOTE(crelf @ Feb 19 2008, 04:00 PM)

I assume you put the quotes there because you disagree? I know why it happens, but I still don't think that it should. Each instance of the constant retains its' size when I move it, save a VI, etc, so why does it reset when something unrealted to size changes in the typedef source? Why can't each instance remain the size it was? I assume that it's easier for you guys to have each instance simply replaced, but when you have large (real estate-wise) constants in multiple locations, it can be a real pain resizing them all. It may not be a bug per se, but I certainly think that it's an unwanted "feature".

I have been bitten by this behavior as well so I share your frustration. I said "bug" because from the standpoint on what the data typedef behavior is, the behavior is expected - the data is replaced (though obviously not desired for the display aspect). We've tossed around separating a data change versus a display change for typedefs. More feedback from the community sure helps in decision making .

I'm curious. What is your objection to an option of having constant icons?

[crelf]

QUOTE(gmart @ Feb 19 2008, 06:10 PM)

I said "bug" because from the standpoint on what the data typedef behavior is, the behavior is expected - the data is replaced (though obviously not desired for the display aspect). We've tossed around separating a data change versus a display change for typedefs. More feedback from the community sure helps in decision making .

I think that it's the expected behaviour for a strict type def, but not an ordinary run-of-the-mill general type def.

QUOTE(gmart @ Feb 19 2008, 06:10 PM)

I'm curious. What is your objection to an option of having constant icons?

Because it's a constant, not a link to a constant. I like how I can look at a diagram and work out what it does pretty quickly - representing a constant by another means is just one more step that I need to go through to understand the code. Another example of hiding things is some implimentations of express VIs - take "Time Delay" for instance - I'm not against express VIs per se (I think they have their place) but I never understood why you'd want to basically move a constant to some other place, with no desernable improvement to the code (except the error clusters, of course :thumbup: ). In short, representing constants by any other means reduces the readability of the block diagram (unless, obviously, that constant is a cluster of arrays of clusters of...)

[jdunham]

QUOTE(crelf @ Feb 19 2008, 03:23 PM)

I think that it's the expected behaviour for a strict type def, but not an ordinary run-of-the-mill general type def.

Because it's a constant, not a link to a constant. I like how I can look at a diagram and work out what it does pretty quickly - representing a constant by another means is just one more step that I need to go through to understand the code. Another example of hiding things is some implimentations of express VIs - take "Time Delay" for instance - I'm not against express VIs per se (I think they have their place) but I never understood why you'd want to basically move a constant to some other place, with no desernable improvement to the code (except the error clusters, of course :thumbup: ). In short, representing constants by any other means reduces the readability of the block diagram (unless, obviously, that constant is a cluster of arrays of clusters of...)

Chris is 100% right about not wanting diagram constant values to be hidden. The best LabVIEW diagram is one you can look at and see how it works with a minimum of opening stuff, right-clicking and mucking around. Theoretically you should be able to print out a VI and have a record of how it was coded, even if the various case structures have to be printed in that weird way. The express VIs don't really show any evidence of how they operate, unless you change them to icons.

However, I never fill in any of the contents in a typedef cluster constant. If you delete an item from the cluster, then often the cluster will revert to all default values. It vaporizes whatever you had stored in the constant, without the slightest warning of course. I just tested this, and actually it only seems to destroy your block diagram values if you delete an earlier item in the cluster. Anyway, this has burned me a few too many times.

So now I always use a bundle function to explicitly initialize non-default items in a cluster. That way it is very clear which values I care about initializing and which values I don't. I would prefer the actual constant to be hidden behind an icon, so I'm not tempted to change the values in there.

[Aristos Queue]

Not that I'm biased or anything, but you know, LabVIEW classes behave just like clusters, and their constants are a fixed size icon. There've been requests for a smaller icon size, but if you're looking for fixed size, there it is. Of course, then you're subject to the complaints about diagram values being hidden. Win some, lose some. ;-)

[gmart]

QUOTE(crelf @ Feb 19 2008, 05:23 PM)

I think that it's the expected behaviour for a strict type def, but not an ordinary run-of-the-mill general type def.

In my experience, a strict typedef is typically used for keeping the look a certain way for front panel controls. Strict-ness doesn't really apply for block diagrams constants. Hence why the confusion with strict typedef ring constants not updating their strings when the typedef is updated. But that's a whole other discussion .

QUOTE

In short, representing constants by any other means reduces the readability of the block diagram (unless, obviously, that constant is a cluster of arrays of clusters of...)

The above is case is why people would want the option to view massive clusters as icons. Yes, it is optimal to be able to view a diagram and see what is going on, but it gets really annoying to have to make room around a huge cluster constant just because you need to initialize a shift register with default values. While it would not be my first choice, I would be ok using a VI just to hold the massive constant if it acted just like a constant (which it doesn't now).

[PJM_labview]

Just to add one more point to this conversation.

While the cluster size is reset to its default size it also has the side effect to hide back all the Labels. Strict type def cluster are not necessary huge. If I have a very large strict type def cluster and I do not benefit to see a large constant on the BD, then I wrap it in a SubVI, but quite often I want to see the cluster constant and its labels for documentation pupose. So if you happen to "improve" on this particular behavior, please do not forget to preserve all aspect of the constant (labels visibility included).

PJM

[Daklu]

QUOTE(gmart @ Feb 19 2008, 03:10 PM)

We've tossed around separating a data change versus a display change for typedefs. More feedback from the community sure helps in decision making.

How much more feedback do you want? I can copy and paste the post as many times as it takes to convince management. :laugh:

[Ton Plomp]

Instead of dropping a VI contant, you could drop a control, hide the FP-part and display it as an icon.

Ton

[Dirk J.]

since you can edit the icon of a typedef in such a way that it tells you about its contents,

it would be nice if there was a 'display as typedef icon' option for such constants.

[Ton Plomp]

QUOTE(tcplomp @ Feb 20 2008, 07:52 AM)

Instead of dropping a VI contant, you could drop a control, hide the FP-part and display it as an icon.

QUOTE(Dirk J. @ Feb 20 2008, 10:41 AM)

since you can edit the icon of a typedef in such a way that it tells you about its contents,

it would be nice if there was a 'display as typedef icon' option for such constants.

What's the functional difference between those two?

Ton

[Dirk J.]

QUOTE(tcplomp @ Feb 20 2008, 01:52 PM)

What's the functional difference between those two?

Ton

nothing really, I guess.

[crelf]

QUOTE(gmart @ Feb 19 2008, 08:56 PM)

In my experience, a strict typedef is typically used for keeping the look a certain way for front panel controls. Strict-ness doesn't really apply for block diagrams constants.

I know - I'm suggesting that it could

QUOTE(gmart @ Feb 19 2008, 08:56 PM)

The above is case is why people would want the option to view massive clusters as icons.

There's pros and cons of every arguement - I'd be *okay* with a cluster constant icon (let's not limit this to typedefs) as long as what it was is really obvious (let users edit the icon, but keep some kind of glyph that identifies it as a constant icon).

QUOTE(tcplomp @ Feb 20 2008, 01:52 AM)

Instead of dropping a VI contant, you could drop a control, hide the FP-part and display it as an icon.

That makes me feel very dirty (and not in a good way). You suggesting setting the default value of a hidden control, just to make the BD more readable? Sure, it'd work, but it's a horrible dirty filthy kludge. (I *hate* hidden FP elements - yes, *hate* them. I've yet to see a justifiable reason to use them. That said, that's for another thread - please don't hijack this one arguing this point!)

[JDave]

QUOTE(Dirk J. @ Feb 20 2008, 01:41 AM)

since you can edit the icon of a typedef in such a way that it tells you about its contents,

it would be nice if there was a 'display as typedef icon' option for such constants.

But you would have to have something to distinguish it from controls that are set to display as the typedef icon, like a thick colored border around the whole thing.

And when you hover your mouse over the "constant icon" you should, of course , have the actual cluster contents displayed like a tip-strip.

[crelf]

QUOTE(JDave @ Feb 20 2008, 12:32 PM)

And when you hover your mouse over the "constant icon" you should have the actual cluster contents displayed like a tip-strip.

Ooooooo - that'd be nice. I wonder if that could be extended to subVIs as well...

[Yair]

QUOTE(tcplomp @ Feb 20 2008, 02:52 PM)

What's the functional difference between those two?

QUOTE(Dirk J. @ Feb 20 2008, 03:34 PM)

nothing really, I guess.

Except for the hidden FP control, which I don't like either.

[Phillip Brooks]

QUOTE(gmart @ Feb 19 2008, 04:44 PM)

The "bug" happens when you change the data type of the typedef. This is due to the fact that typedefs don't have a display state separate from the data state. So the typedef is reinitialized to it's default size whenever the data changes.

Maybe typedefs should include an internal structure to store a Block Diagram display state?

It could be NULL by default (like a caption on a Front Panel Object). When the typedef data stucture is modified AND the BD display state is defined (not NULL) then the editor would show the new version and allow the programmer to change the BD constant appearance only once and have it updated everywhere it is used. The BD Constant should hav its own Strict option.

The Control Editor could use a splitter bar to show and allow editing of the BD constant when enabled.

(B/T/W Why does LabVIEW allow you to create a splitter bar in a control? )

http://lavag.org/old_files/monthly_02_2008/post-949-1203537990.png' target="_blank">

[TobyD]

QUOTE(crelf @ Feb 20 2008, 09:55 AM)

Ooooooo - that'd be nice. I wonder if that could be extended to subVIs as well...

I really like that idea...you could have a small image (similar to the navigation window) of the cluster and/or the subVI's block diagram popup when you hover.

[crelf]

QUOTE(TobyD @ Feb 20 2008, 05:51 PM)

I really like that idea...you could have a small image (similar to the navigation window) of the cluster and/or the subVI's block diagram popup when you hover.

That's exactly what I'm thinking - maybe you could even switch between the FP and BD of the node you're hovering over...

[Guillaume Lessard]

QUOTE(TobyD @ Feb 20 2008, 03:51 PM)

I really like that idea...you could have a small image (similar to the navigation window) of the cluster and/or the subVI's block diagram popup when you hover.

That could get really old if what you want to do is look at the current block diagram. Currently anything that pops up is fairly small and non-intrusive. If LV starts popping (reduced) block diagrams whenever the mouse pointer is stopped for 2 seconds... I can feel a surge of annoyance already!!

Pop it when a modifier key is down. Or show it in the context help window when a modifier is down. (Ah, the annoyance ebbs...)