Zoom function in Block Diagram?

[Beck45]

I think some variation of the feature would be useful.  One of  my current block diagrams (BD) is huge--maybe 4 screen areas!  But I find it completely easy to use, modify and come back to even after many months.  I have also used instrument drivers with 5 or 6 layers of subVI's that I highly frustrating to figure out, having to drill down to several different BD's, each of which has even more subVIs; you never get an overall picture.  Plus having 10 or 20 windows open isn't exactly convenient.  I'd much rather have one big well-organized diagram.

Doesn't it come down to logitstics?  You can't see more than 1 screen at once anyway.  Why is double-clicking and alt-tabbing better than scrolling?  Either one gets you the same information.  So, given the very same code, why woudn't it be better to have all "subVIs" neatly arranged in well defined areas, all on the same diagram so all data flow is immidiately available? 

One issue is, as stated above, it can be harder to understand at first, at a glance.  But then that's what an intelligent zoom function could do: zoom out all the sections into subvi's.  Another option would be hover your mouse over a subvi and it expands, flash-style.  

But what I did in my diagram is create a small "block diagram map" (a small image of the whole BD) where each section is highlighted and explained.  In fact it looks somewhat like a very small BD itself!  Isn't this the best of both worlds?  It seems to me we should separate bad coding practises (which I'm sure I'm guilty of as well) from subVI use/BD size--the latter seems entirely a matter of logistics IMO.  I've seen this in text programs as well.  Why is a longer main program a bad thing?  Continuously jumping around to functions that only have another 10 lines and are only used once, makes no sense, and is far harder to read.  True, because the function call has a descriptive name, the code becomes easy to read in that way; but that's what comments are for.  🙂  

Message Edited by Beck45 on 03-22-2010 12:20 PM

[Mark_Yedinak]

---

Beck45 wrote:

I think some variation of the feature would be useful.  One of  my current block diagrams (BD) is huge--maybe 4 screen areas!  But I find it completely easy to use, modify and come back to even after many months.  I have also used instrument drivers with 5 or 6 layers of subVI's that I highly frustrating to figure out, having to drill down to several different BD's, each of which has even more subVIs; you never get an overall picture.  Plus having 10 or 20 windows open isn't exactly convenient.  I'd much rather have one big well-organized diagram.

Doesn't it come down to logitstics?  You can't see more than 1 screen at once anyway.  Why is double-clicking and alt-tabbing better than scrolling?  Either one gets you the same information.  So, given the very same code, why woudn't it be better to have all "subVIs" neatly arranged in well defined areas, all on the same diagram so all data flow is immidiately available? 

One issue is, as stated above, it can be harder to understand at first, at a glance.  But then that's what an intelligent zoom function could do: zoom out all the sections into subvi's.  Another option would be hover your mouse over a subvi and it expands, flash-style.  

But what I did in my diagram is create a small "block diagram map" (a small image of the whole BD) where each section is highlighted and explained.  In fact it looks somewhat like a very small BD itself!  Isn't this the best of both worlds?  It seems to me we should separate bad coding practises (which I'm sure I'm guilty of as well) from subVI use/BD size--the latter seems entirely a matter of logistics IMO.  I've seen this in text programs as well.  Why is a longer main program a bad thing?  Continuously jumping around to functions that only have another 10 lines and are only used once, makes no sense, and is far harder to read.  True, because the function call has a descriptive name, the code becomes easy to read in that way; but that's what comments are for.  🙂  

Message Edited by Beck45 on 03-22-2010 12:20 PM

---

Monolithic code (one big diagram) is never easier to understand or maintain. In addition, you will never be able to reuse code. Well organized and modular code is by far easier to maintain, easier to understand and easier to work with. If you have good code you shouldn't need to dive deep into the subVIs to understand what is happening. At the higher levels of code you see a well documented, well named subVI that should tell you functionality what it does. Most of the time you shouldn't need to understand the details of what is happening inside the subVI. Think of your program as bookshelf. Would you be able to read and understand all the books if all the text were displayed at one time? The answer is absolutely not. You package up the information that belongs together and create the book. Now from the bookshelf level you can grab the book and read its abstract and name and have a pretty good idea of what you have. Granted, you don't execute a bookshelf and the books themselves don't build a system but the point I am trying to make still holds.

[nasaamesbob]

I'm new to labview so I don't understand why there's so much resistance to having the ability to zoom in on the block diagram.  Not all of us have the eyesight of 20 something year old programmers.  To my old eyes, the icons in labview are small and frustrating to connect to.  My cad applications have zoom, does that make for bad cad drawings?  Zoom in, connect your wires, zoom out again.  Zoom is a tool that I would find extremely useful.  If you don't want to use it, that's your choice.  I for one, would love it.

[SteveChandler]

I think the resistance is to zooming out. That is not necessary and if someone needs that then they are not doing it right. Zoom in on the other hand is a good idea but was unfortunately declined.

[Edit:] I usually set my super high resolution and expensive monitor to 1024x768 when developing LabVIEW code

[altenbach]

---

@nasaamesbob wrote:

I'm new to labview so I don't understand why there's so much resistance to having the ability to zoom in on the block diagram.  Not all of us have the eyesight of 20 something year old programmers.  To my old eyes, the icons in labview are small and frustrating to connect to ....

---

Part of the blame are these ultra high resolution screens now available. In the good old days, resolution and screen size was more predictable and there was little variation in dot pitch. There are now 17" laptops with 1080p resolution! I agree that applications need to get away from pixel based UIs..

In the meantime, you can use the magnifier tool (part of the accessibility features of windows).

[nasaamesbob]

LavVIEW needs zoom when working on block diagrams.  Resetting monitor resolution is not acceptable.  Let's face it, you are drawing when you are programming in LV.  Can't imagine working in AutoCAD or SolidWorks without the ability to zoom in and out.  Come on NI, this is a no-brainer.

[smercurio_fc]

If you want the functionality, then you should vote for the idea: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-zoom-function-yes-I-said-zoom-So-sue-me/idi-p/91...

And what you consider to be a "no brainer" may turn out to be more difficult than you may realize.

[SteveChandler]

---

@nasaamesbob wrote:

LavVIEW needs zoom when working on block diagrams.  Resetting monitor resolution is not acceptable.  Let's face it, you are drawing when you are programming in LV.  Can't imagine working in AutoCAD or SolidWorks without the ability to zoom in and out.  Come on NI, this is a no-brainer.

---

Are you wanting to zoom in? I think that could be useful. But if you are talking about zooming out then that is not a good idea. AutoCAD and SolidWorks are physical modeling tools and not software.

[nasaamesbob]

Of course, when you zoom in, you must be able to 'zoom' back out to the original size.  As for difficulty, it seems that much of labview is pixel based in it's representation vs vector based, so of course, this would be a major change.  The point being, labview is not resolution independent so on high density monitors, the icons get smaller and smaller. You can run in non-native resolutions but the result is usually a compromise as the increased resolution comes at the expense of sharpness.  More of a problem with flat screen displays than the old CRT's but who still uses those.  

Most of the time this question gets answered by labview experts and what I read is usually the same type response.  Why do you want to do that?  You should use sub vi's, your code must be too complicated, it should fit on one screen, etc...  They fail to see that the point I'm making is that I want to be able to zoom in on a dozen or so vi's so it's easier to make the connections and then zoom back out to 1:1 ratio.  I don't really want to zoom out to an even smaller block diagram.  

My hope is that by keeping this topic alive, someone at NI will decide to include 'zooming' in a future release.  Imagine the possibilities!

[SteveChandler]

---

@nasaamesbob wrote:

Of course, when you zoom in, you must be able to 'zoom' back out to the original size.

Indeed! It would be aweful if the function were not reversable!

Most of the time this question gets answered by labview experts and what I read is usually the same type response.  Why do you want to do that?  You should use sub vi's, your code must be too complicated, it should fit on one screen, etc...  

The reason is because most of the time this feature is requested by someone who has a huge block diagram and they want to zoom out in order to see it all.

They fail to see that the point I'm making is that I want to be able to zoom in on a dozen or so vi's so it's easier to make the connections and then zoom back out to 1:1 ratio.  I don't really want to zoom out to an even smaller block diagram.  

I totally agree. The minimum ratio should be 1:1. Maybe there just needs to be a "high resolution monitor" mode in which there are twice the pixels making up the elements.

My hope is that by keeping this topic alive, someone at NI will decide to include 'zooming' in a future release.  Imagine the possibilities!

---

Good luck with that. This idea was declined. If you have not already go ahead and click on it to see why.