Zoom in on Block Diagram

[Yamaeda]

---

@Dennis_Knutson wrote:
Since a block diagram should never be larger than one screen, no need to zoom out.

---

Especially when someone has developed on 2550x1440 and you open the VI on a test station with 800x600, right?

[tedt2]

The ignorance of the LabView developers is extremely frustrating.

I would abandon LabView, but must use it for external customers.

[billko]

---

@tedt2 wrote:

The ignorance of the LabView developers is extremely frustrating.

I would abandon LabView, but must use it for external customers.

---

They are NOT ignorant.  They know this is one of the most requested features of all time.  They just haven't found a solution yet.  Why don't you give it a try, as you are apparently NOT so ignorant.

[crossrulz]

---

@tedt2 wrote:

The ignorance of the LabView developers is extremely frustrating.

I would abandon LabView, but must use it for external customers.

---

Such harsh words are not going to get anything done any time soon.  I know NI knows this is an issue.  But there is also almost 30 years worth of code base that they have to go through in order to actually make it happen.  This has been discussed many many times on these boards.  It is the really old code that is at the core of LabVIEW that will have to be changed in order for this to happen.  And yes, that code was written well before anybody even thought of having a zoom feature for any program out there.  There is a an effort to work on some of this core, but it will be over many many years.

As was suggested to you in other boards, use a smaller resolution and/or the Windows zoom program.

[EdDickens]

---

@tedt2 wrote:

The ignorance of the LabView developers is extremely frustrating.

I would abandon LabView, but must use it for external customers.

---

Another way to go would be to use a decent application architecture. Then there's really no need for a zoom function.

State machines, Actor Framework, Plug-in architecture all work wonders to keep your code manageable. 

[Yamaeda]

---

@EdDickens wrote:

---

@tedt2 wrote:

The ignorance of the LabView developers is extremely frustrating.

I would abandon LabView, but must use it for external customers.

---

Another way to go would be to use a decent application architecture. Then there's really no need for a zoom function.

State machines, Actor Framework, Plug-in architecture all work wonders to keep your code manageable. 

---

I havn't tried working with LV on a 4k monitor, but i'm sure i'll miss a zoom function the most. 😉

It's not a case of good or bad code design, but simply the fact that if it were text based code - we'd be locked at 10 pixel fonts.

/Y

[Norbert_B]

---

@Yamaeda wrote:

---

[...] but simply the fact that if it were text based code - we'd be locked at 10 pixel fonts.

/Y

---

That somehow lacks the comparison. It would be more about automatic word wrapping. Imagine to implement for a C compiler but the editor simply displays your lines without wrappings.

You would have to scroll on the horizontal scrollbar to view the lines or to shrink text size (read: zoom out) to see all code.

I learned textual languages with the recommendation: take care of line feeds and layout.....

So this is a case of "best practises".

And for LV, it is "best practise" to keep the code of a single VI to match a screen size without the need of scrolling.

Using SubVIs and other stuff (like Ed mentioned) is the key to keep readable code.

If developers decide to disregard this best practise, they shouldn't blame the tool if their work becomes a nightmare for maintainance.

The only valid situation for this request is: receiving inherited code. And for this use case, NI introduced the navigation window, which is already mentioned in this discussion thread.

just my 5 cents,

Norbert

[crossrulz]

---

@Norbert_B wrote:

---

@Yamaeda wrote:

---

[...] but simply the fact that if it were text based code - we'd be locked at 10 pixel fonts.

/Y

---

That somehow lacks the comparison. It would be more about automatic word wrapping. Imagine to implement for a C compiler but the editor simply displays your lines without wrappings.

You would have to scroll on the horizontal scrollbar to view the lines or to shrink text size (read: zoom out) to see all code.

I learned textual languages with the recommendation: take care of line feeds and layout.....

So this is a case of "best practises".

And for LV, it is "best practise" to keep the code of a single VI to match a screen size without the need of scrolling.

Using SubVIs and other stuff (like Ed mentioned) is the key to keep readable code.

If developers decide to disregard this best practise, they shouldn't blame the tool if their work becomes a nightmare for maintainance.

The only valid situation for this request is: receiving inherited code. And for this use case, NI introduced the navigation window, which is already mentioned in this discussion thread.

just my 5 cents,

Norbert

---

That is an argument against a zoom OUT (which I am completely against) and a zoom IN (which I could understand).  This person is complaining they can't read the text in a subVI block. For that, they would like a zoom in.

[billko]

To be honest, I really didn't even think of the zoom/zoom out feature to look at huge BDs.  I'm a firm believer that if you can't describe your VI in a paragraph or two, it's probably too big and needs to be broken down into subVIs - and yes, that goes for the main VI, too!  For me, it would be all about using a huge monitor and having trouble seeing the little tiny icons on the screen.  😉

I know you can change screen resolution but it's inconvenient

Changing DPI messes up the free labels (maybe more, but that's the most obvious one).

Still, it's not enough to go on a rant and declare that I'd abandon LV if it weren't for my customers.

[Norbert_B]

Well, yes, my remark is obviously biased.

Of course, no one can predict the future (at least as far as we know!), but i doubt that ZOOM OUT does any good for LV. I fear that zoom OUT would lead for unskilled developers to mash everything in a single VI, then wondering why things break and calling for help. Nobody of course can grant effective help in that situation without a significant amount of time invested in code analysis.....

A ZOOM IN on the other hand can become handy if wiring up subVIs with many parameters. So no rant against this option.

Norbert

PS: Sorry if i mistook your post, Yamaeda....