Glitched block diagram - adding local variables is faulty and scrollbars are wrong. Corrupt vi file?

[altenbach]

---

@Mark_Yedinak wrote:

---

@JonnyOhJonny wrote:

It is stupid, yes. Makes it even more embarrassing that LabView can do this to itself, without even notifying.

---

I am sure you can mess with any compiler if you throw extremely bad code at it. 

---

I though we were talking about the block diagram cleanup tool that can take a gigantic messy VI (that still fits nicely into the limits!) and turn it into something that exceeds the boundaries and thus corrupts the diagram.

[billko]

I wish you could delete posts.

[billko]

---

@altenbach wrote:

---

@Mark_Yedinak wrote:

---

@JonnyOhJonny wrote:

It is stupid, yes. Makes it even more embarrassing that LabView can do this to itself, without even notifying.

---

I am sure you can mess with any compiler if you throw extremely bad code at it. 

---

I though we were talking about the block diagram cleanup tool that can take a gigantic messy VI (that still fits nicely into the limits!) and turn it into something that exceeds the boundaries and thus corrupts the diagram.

---

That wasn't my take on it, but that is a valid gripe that I didn't think about.  It takes my mantra to an extreme.  I always say, "If using the cleanup tool makes your code look better, then you should re-think your coding practices."  Given the right combination of stuff on the block diagram, I've seen my compact, one-screen, subVI-rich code expand to a couple of screens when using the cleanup button.  (Which is why I never do it except for very simple subVIs that I created from some inline code.)

But then again if a "clean up formatting" tool in a text-based programming IDE caused you to exceed a maximum line or character limit because you put everything in one file, is that the IDE's fault?

[JonnyOhJonny]

---

@altenbach wrote:

---

@Mark_Yedinak wrote:

---

@JonnyOhJonny wrote:

It is stupid, yes. Makes it even more embarrassing that LabView can do this to itself, without even notifying.

---

I am sure you can mess with any compiler if you throw extremely bad code at it. 

---

I though we were talking about the block diagram cleanup tool that can take a gigantic messy VI (that still fits nicely into the limits!) and turn it into something that exceeds the boundaries and thus corrupts the diagram.

---

Exactly. And not only the clean-up tool, but part of the glitch happened by copying some local variables with ctrl-c and pasting with ctrl-v - then LabView created new front panel elements outside its own boundaries. I'd call this behavior a bug.

[Mark_Yedinak]

---

@JonnyOhJonny wrote:

---

@altenbach wrote:

---

@Mark_Yedinak wrote:

---

@JonnyOhJonny wrote:

It is stupid, yes. Makes it even more embarrassing that LabView can do this to itself, without even notifying.

---

I am sure you can mess with any compiler if you throw extremely bad code at it. 

---

I though we were talking about the block diagram cleanup tool that can take a gigantic messy VI (that still fits nicely into the limits!) and turn it into something that exceeds the boundaries and thus corrupts the diagram.

---

Exactly. And not only the clean-up tool, but the glitch happened by copying some local variables with ctrl-c and pasting with ctrl-v - then LabView created new front panel elements outside its own boundaries. I'd call this behavior a bug.

---

Bad behavior yes. However, copying local variables has always copied the control/indicator. Placing them outside of the boundaries should be caught however I suspect the reason they were placed there in the first place was because the block diagram was already exceedingly large. I guarantee that if you use good programming practices you would never encounter this bug. Should you blame the hammer if a carpenter builds a crappy house that falls apart or do you blame the carpenter for building a shoddy house.