[Bug?] Why does locking the panel also lock the diagram?

[altenbach]

Sometimes events have very quick code that will take ages under execution highlighting.

If the event is set to lock the panel (default) and execution highlighting is enabled, the diagram is completely locked while the event executes!

• The diagram window cannot be brought to the front
• probes cannot be placed
• execution highlighting cannot be turned off to speed things up
• etc.

I understand the the front panel will be locked, but why the diagram????

[Christina_R]

Thanks for the feedback! I agree that we shouldn't be locking diagram editing operations like this. I've created Bug 1467984.

[altenbach]

Thanks, Christina. It probably took me way over 10 years to final put 2+2 together and realize that the inability to interact with the debugging tools is related to the event lock settings. Always thought that things are just generally busy and a bit slow.

I rarely lock the panel anymore so I don't see it much with my own code. (Here's a great VI analyzer test!)

Just recently I bumped into it again with some forum code and finally (!!) realized that it had to do with the events. 😮

(So the question still remains why most events lock by default and if this is reasonable or not.)

[sth]

---

@altenbach wrote:

(So the question still remains why most events lock by default and if this is reasonable or not.)

---

Because many peoples code is written badly that an event frame takes noticeable time.  Thus the user doesn't see a response and then clicks the button several times in frustration leading to bad results.  I think it is a case of having the seating as sort of a seat belt for bad coding.  At least that is all I can figure.