Reduce the size of the Close Reference VI

[ReneW]

The size of the Close Reference VI makes it impossible to draw a proper block diagram.

It is too big!  It does not match with the Property Node vi.

Therefore I would propose: --> Make the Close Reference VI smaller!

[RavensFan]

I'm going to notify the moderator and ask her to edit your message.  The word is "Reference" not "reverence".  Without fixing it, someone searching for "reference" will never find your idea.

[ReneW]

Ravens Fan, Laura F. -> Thank you for fixing the title.

[David S.]

I draw proper block diagrams with it all the time!

[RayFarmer]

Actually it would make sense to loss the close and be able to set the Invoke node or Property node to close the reference when completed. Maybe change the reference out symbol with a cross or bar though it and no allow any connection to the terminal.

[RayFarmer]

I just seen RenW idea to get rid of the Close Ref (Integrate Close Reference into the Property Node)

[Daklu]

I'm generally a fan of making things smaller on the block diagram.  The primary issue I have with this suggestion is by reducing the Close function's size it becomes more awkward to use it with user-created vis.  The problem isn't really solved; it's just moved to a different use scenario.

[AristosQueue (NI)]

Wouldn't this cause a problem for all the non-property node APIs that use the 4x2x2x4 pattern? In those APIs, the terminals do line up. Seems to me the more correct fix is to make the top of the Property node taller so that they match. I wouldn't necessarily like that, but if we're going to line these up, I'd rather line up the property node than break the close node's alignment with other APIs.

[Darin.K]

> Seems to me the more correct fix is to make the top of the Property node taller so that they match.

That exact thought occurred to me the other day.  Given the popularity of all the "let's make this 1 pixel smaller" ideas, I guessed how well that would go over.

In my mental list of "fateful decisions NI made that we are all now stuck with", very near the top of the list is the decision to use the corners of the 4224 pane for the error and ref wires.  Now we get the virtual wall of wires which blocks the middle terminals along with the bends introduced by the Property/Invoke Nodes.

> Wouldn't this cause a problem for all the non-property node APIs that use the 4x2x2x4 pattern?

Perhaps.  My own crude statistical analysis indicates that the smaller node would remove roughly 87539319 wire bends near PN/IN in my VIs, and introduce about 2 bends near other VIs.  What about two versions, this function already appears at least three times in the palette.

[Samuel_James]

I had posted an alternate solution in the below link

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Increase-the-size-of-Property-Node-amp-Invoke-Node/idi...

Warm Regards

Samuel J

[AristosQueue (NI)]

> Perhaps.  My own crude statistical analysis indicates that the smaller node would remove roughly 87539319

> wire bends near PN/IN in my VIs, and introduce about 2 bends near other VIs.

I'm guessing you don't do "Create SubVI" around subsets of prop/inv nodes as often as I do. It would muck with a lot of my UI control libraries.

> What about two versions, this function already appears at least three times in the palette.

Yeah, but it's always the same node, just more accessible. And the worse problem is reading the diagram, getting people to recognize that both nodes are the same node. I would oppose generally any shipping of "this is the same node but drawn differently" regardless of which node we're talking about. It's part of my general reflex that lead me to oppose the "View cluster constant as icon" feature. I lost that argument... I might lose this one too. 🙂