Same Height of Unbundle by Name / Terminal / Local Variable

[Andrey_Dmitriev]

The problem that height of local variable is 17 pix, and terminal - 16 pix, but distance between terminals in unbundle function is 15 pix.

As result - aligning to vertical compress caused steps in wires:

Right nowterminals/local variables should be slighly overlapped for "step edge free" wiring.

Please synchronize size of these icons with distance between terminals (to 16 pixels - seems to be ideal size)

Not sure if it was already in Idea Exchange or not.

Andrey.

[Christina_R]

Re-opening because LabVIEW NXG has been discontinued.

[Taggart]

I hate to see NI spend resources it could spend on other things on this and yet it seems simple enough that I can't believe it hasn't been done yet. Of course that probably just means I don't understand the problem well enough. But its been done in NXG now, so presumably NI knows how to solve the problem and hopefully it translates easily back to LabVIEW.

[GregR]

I have been advocating internally for uniform terminal spacing. There are just a lot of other things that are higher priority. I built a prototype where all terminals on nodes and subVIs are on 4-pixel boundaries and at least 8 pixels apart. I think it works well but it is far from being ready to ship.

One of the complications is the connector panes with more than 4 terminals per side. The leading solution doesn't preserve existing options perfectly but is to have connector panes that are more than 32 pixels vertically. Instead of  that has 6-7 pixel spacing, there would be  with 2 less terminals but 8 pixel spacing. The icon would still be the same size and draw at the top. The extra vertical space would have a standard visual. If you use all the top and bottom terminals, this would mean switching to a pattern with more side terminals.

[Christina_R]

Implemented in LabVIEW 2023 Q1.

[RalfO]

Hello forum.

I am using LabVIEW for over two decades now. A *lot* of code has accumulated by now. As I am doing this for earning money, I am forced to uphold an efficient way of working and I need to deliver orderly looking block diagrams to my customers - else they wont pay me money.

After installing LV2023Q1 and (as usual with a new version) setting my fonts to "Tahoma 13" (for compatibility to way back when I started coding this project), I loaded my project. It looked like after an earthquake - most wires had new bends and most objects were moved a couple of pixels around. After a short search in the forums I got here and had to learn, that there is a new feature called "forced unbundle pixel size whatever".

I now have the following options:

1) I could go through the equivalent of about a football field of block diagrams and readjust miles of wires - Maybe if I had half a year of time to waste...

2) I could say goodbye to an orderly looking block diagram - my customers wont like it.

3) Avoid LV2023Q1 and skip LabVIEW versions until somebody implements an "off" switch.

As much as I hate this last option, I don´t see how I can avoid it. My customers simply won´t tolerate many hundreds of ruined block diagrams.

The idea behind this feature is a good one, I really like the idea of saving unnecessary wire bends. But the method of enforcing it on existing diagrams by introducing new wire bends is totally counter productive and a hard show stopper for commercial use.

This situation reminds me of the saying: "The difference between a feature and a bug is the existence of an off-switch". Maybe there lies the solution: If every VI would have a mode switch in its options dialog, where one could select if the new feature is to be applied for that VI (default off), and the LabVIEW global options would have a similar switch like "mode for new VIs" (default on), then everyone could clean their code when/if they like/can, old code would not be shattered, and new VIs would by default look better.

Pretty please...

Regards,

     Ralf

[wiebe@CARYA]

If there needs to be an switch (didn't make the move so can't really tell if I hate it that much), I'd prefer a 'legacy' switch on the (un)bundlers.

The switch could only be turned off; it's only on for old code.

That way, old (un)bundlers will stay the same, but will disappear over time.

The downside of this is that the overhead (data, code, complexity) will remain forever. Or maybe for 10 years or so, after then it could revert to how it is now; you'd at least have 10 years to adjust.

[RalfO]

@wiebe:

> The switch could only be turned off; it's only on for old code.

Yes, that would be totally acceptable. Good idea.

> The downside of this is that the overhead (data, code, complexity) will remain forever.

Also true - because the actual idea behind that is investment protection. I put years into my code and I want to invest my future time into new code, so that I can get payed. I ideally want to keep my old proven code forever, because it works. In a commercial context, proven code is of real value.

> Or maybe for 10 years or so, after then it could revert to how it is now; you'd at least have 10 years to adjust.

OK, that's realistic. I could live with that.

Thanks for the reply and the good idea,

     Ralf

[Cepera]

I can sign under every word that @RalfO said: I have also been using Tahoma 13 for all the three custom fonts for decades! I can't believe there is no Tools >> Options checkbox for disabling this new feature. For example, "red Xs at broken wires" and "place terminals as icons" can be disabled. Why not in this case?

Not cool!

Sergey L