Default setting for Event Structure shouldn't be to Lock Front Panel

[SpaceX Trip]

I've never really understood why the default for new events in an event structure is to lock the front panel.  In my applications it's a scary thing to have the front panel lock at all.  I think this should be turned off as a default, and if you really want it for a specific use case you can turn it on yourself.

[X.]

In general it is a good thing, as it prevents users from hammering their keyboard or mouse if the PC reaction is less than immediate (piling up repeated occurences of the same event in the event queue). If you are systematically unchecking this option, you might expose yourself to a lot of unsuspected troubles... At least that the rationale described in the help for the Event Structure, if I recall correctly. You may also want to read this piece of wisdom on "Locking the Panel".

Your software architecture is maybe not parallel enough yet? As stated in the link above, if you use your event structure as a means to send tasks to parallel loops or VIs, your UI should never feel "locked" even if the panel is "locked" by default.

My 2 cts.

[smercurio_fc]

I would agree with that assessment. I am curious as to why your applications need to have the off by default. It sounds like you're piling all your code inside the event case (which is, of course, BAD design).

[SpaceX Trip]

No, I'm not putting all, or even slow, code inside event cases.  There are plenty of parallel threads running, I just don't like the setting and in my opinion I think it shouldn't default to locking.  It's not so much a result of design, I just disagree with it being the default setting.

The "why" is simply - I don't even want the front panels of my vi's to lock for any reason.

[SpaceX Trip]

I guess I should also say I personally think it's bad practice to have front panels lock, in my experience it only frightens users to see front panels lock, and as a progammer if I were to tell a user that I have code that "freezes" their GUIs it would not instill confidence in that user.

[smercurio_fc]

I can understand your reasonings, but can you also see the flip-side? If a program is not capable of determining what it's supposed to do because things have changed on it when it was busy doing what you told it to do about 0.25 seconds ago, is that any better? Example: You have an event case that handles a button press. In that event case you perform an action that uses the value of another control. If the front panel is not locked and the user somehow is able to change the control's value before the event cases access it, which value is it supposed to use? The value when the button was pressed, or the value that the user changed it to? There are cases when the front panel should be locked, and there are cases when it should not be locked. I agree with the assessment that in the majority of cases the front panel should be locked.

[SpaceX Trip]

Certainly, there are all kinds of different ways to use this feature, and it's not that I don't see that - I just disagree with that point of view, and I don't mean to imply that it's not an invalid way to look at things, I just think that if you want to lock the panel, you should have to explicitly state it, not the other way around.

[dthor]

How about just a toggle somewhere in the options? Something that gets transferred over when upgrading LV versions, of course.

[SpaceX Trip]

Like you could globally set the default inside your development environment?  It's tempting, but I can just imagine that it would be easy to forget to set it when you setup a new machine, or add a new developer to your team. ("hey <insert new programmer name> we turn this one option off by default")

There was another idea exchange regarding this checkbox, to just have it displayed on the BD.   That might be a better approach to working around this problem.

[Darren]

Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.