Zoom function in Block Diagram?

[pRoFiT]

I love this topic. I too sometimes wish I could zoom IN a little while working on my triple 24inch screens.

Maybe, just maybe to satisfy all. A ZOOM IN feature could be implemented And ZOOM OUT would only go back to the original 1:1 Labview size. So we don't have developers creating huge code.

And I wanted to comment on zoom out And huge code that is hard to read. Why do You care What other people code? Not having zoom out doesn't stop bad design. You may as well limit the number of wires allowed in one VI, that will make people code better.

On that note: I work with a developer that started around the same time as me. One of his first programs is done inside a really long sequence (before our knowledge of state machines And such). But that super long unreadable code works. And saves our production lines a lot of time, by automating What used to take minutes, down to seconds. We joke about that code all the time. We show the code And tell other developers, DON'T DO THIS. I doubt He will ever go back And make It look nice. He has no need to make It look nice. It works. And You don't fix What already works.

And if You think LabView is the only software development that has unreadable code, check out this link http://en.wikipedia.org/wiki/Obfuscated_code There are people out there that are making code impossible to read on purpose.

As a hacker i see this question a lot: Why do You want to do that?

Because I do. What more do You need.

[altenbach]

---

@pRoFiT wrote:

And if You think LabView is the only software development that has unreadable code, check out this link http://en.wikipedia.org/wiki/Obfuscated_code There are people out there that are making code impossible to read on purpose.

---

Our own obfuscated code thread is almost 7 year old. Time flies! 😄

[MadScientist]

I know they keep declining the zoom feature request, but I read the NI response and I want to add some ideas.

Mac OSX 10.6 (and probably earlier versions) has a zoom feature using Ctrl and 2-fingers up or down, which keeps the same underlying resolution, but expands the pixels in software, this would help in Labview to wire subVI's without making errors. Windows has the magnifier accessibility tool, which is very similar. Why can't Labview use these existing OS functions in their software? This would meet the basic requirements of zoom, and then they wouldn't have to recode everything. 

Another Idea that some guy on a training course suggested was Google Earth style zooming, what he meant by this was the ability to zoom into subvi's to see the underlying code, and zoom out to the main block diagram, then zoom out further to the application(?) block diagram.

[tst]

---

@MadScientist wrote:
Why can't Labview use these existing OS functions in their software?

---

Maybe because it's not that simple to do this?

---

MadScientist wrote:

Another Idea that some guy on a training course suggested was Google Earth style zooming, what he meant by this was the ability to zoom into subvi's to see the underlying code, and zoom out to the main block diagram, then zoom out further to the application(?) block diagram.

---

NI already demonstrated such a concept several years ago, where you can basically do a single zoom from the "system diagram", which shows everything, including different hardware devices, to the subVIs. That said, I have no idea how close that is to an actual working product.

[altenbach]

---

@tst wrote:
NI already demonstrated such a concept several years ago, 

---

There is a LabVIEW version that supports full zoom on the diagram and front panel and it is available to all: the LabVIEW web UI builder.

Check it out for free! It only costs to build standalone deployed applications if I remember right. 😄

[NIquist]

I agree that some sort of well integrated zoom-in feature would be NIce but I doubt we'll SEE it soon.  In the meantime if you have a big monitor and your eyes are getting old you can just do what I did...  Buy some glasses.

[Mark_Yedinak]

---

@pRoFiT wrote:

I love this topic. I too sometimes wish I could zoom IN a little while working on my triple 24inch screens.

Maybe, just maybe to satisfy all. A ZOOM IN feature could be implemented And ZOOM OUT would only go back to the original 1:1 Labview size. So we don't have developers creating huge code.

And I wanted to comment on zoom out And huge code that is hard to read. Why do You care What other people code? Not having zoom out doesn't stop bad design. You may as well limit the number of wires allowed in one VI, that will make people code better.

On that note: I work with a developer that started around the same time as me. One of his first programs is done inside a really long sequence (before our knowledge of state machines And such). But that super long unreadable code works. And saves our production lines a lot of time, by automating What used to take minutes, down to seconds. We joke about that code all the time. We show the code And tell other developers, DON'T DO THIS. I doubt He will ever go back And make It look nice. He has no need to make It look nice. It works. And You don't fix What already works.

And if You think LabView is the only software development that has unreadable code, check out this link http://en.wikipedia.org/wiki/Obfuscated_code There are people out there that are making code impossible to read on purpose.

As a hacker i see this question a lot: Why do You want to do that?

Because I do. What more do You need.

---

One reason is to discourage bad coding from the onset. LabVIEW is often labeled a bad development area because of the bad code people write. Since LabVIEW has been marketed as a tool that anyone can program in it suffers from lots of non-programmers writing terrible code. This reflects negatively on LabVIEW and can dramatically affect sales. Managers will hear some horror stories about how a LabVIEW application failed miserably and then abandon use of it in the future. LabVIEW is unfairly blamed for these failures.

I see graphical programming as the next big leap in programming in general. Yes, it exists today but it is not as widely used. Text based programming will be around for years to come but given how widely things are moving to the graphical realm it is only natural programming will move in that direction too.

[smercurio_fc]

---

@Mark Yedinak wrote:

I see graphical programming as the next big leap in programming in general. Yes, it exists today but it is not as widely used. Text based programming will be around for years to come but given how widely things are moving to the graphical realm it is only natural programming will move in that direction too.

---

Microsoft seems to agree with you.