Busy cursor for the event

[andrej]

In Edit event dialog new option for busy cursor (with disable click option). Cursor is set busy immediately after the event is triggered and unset busy after the event is completed.

It would be very useful when there are several time consuming events, like data processing etc.

[X.]

I'd say if you encounter this situation (of an event processing hijacking youtr CPU), you probably need to consider a producer-consumer design, where event processing is performed in a parallel loop. There you will be able to use the cursor busy VIs if you want to, or more user-friendly, display some sort of message/progress bar indicating to the user that resources are being used. I don't think your idea would encourage sound programming...

My 2  cts.

[dthor]

I think the reason behind the idea is a bit poor, as X. pointed out. If you have something that takes a long time, perhaps there's something wrong with your code? At the very least you should have some form of indication to the user what is going on.

However, I do actually like the Idea itself. I see it doing two things:

1. It removes the need for Set Busy and Unset Busy cursor VIs in each event case that you want the cursor to change for. Saves space and saves coding time. I like it.
2. Disable Click prevents LabVIEW from queuing up events while a given event is running. I think this can be useful in it's own right. As it stands right now, to accomplish this goal you need to use dynamic event registration and disable/re-enable the dynamic events before and after the special event is fired. Keep in mind this is different from "Lock Front Panel until this event case completes" as, in this case, events are not queueud up while the event is running.

Thus, I give my Kudos.

[X.]

I think it is pretty much the same as "Lock Front Panel" but with a busy cursor twist... When the front panel is locked, you cannot activate or use any controls on a FP, so there is by definition no FP-generated events added to the event queue. However, I suppose (but I haven't tested it) that dynamically generated events can still be queued (say from a subVI or another panel). Therefore to me, the idea would make sense if instead of all these additional check boxes in the event dialog window, you would have nothing additional but instead a general option (in the options dialog) where you would set the cursor to look busy (or not) when the FP is locked. This, because for consistency, you probably want all your FPs to behave the same.

Maybe I misunderstood the idea. But I think a lot of programmers on this board will agree than an unresponsive UI sucks. An unresponsive UI with no busy cursor sucks even more, hence my comment about trying to avoid it at all costs...

My 2 cts.

[AristosQueue (NI)]

I think I'm with X. on this one. The current requirement that you explicitly add the lock/unlock VI calls into your event case is relatively easy for those times when it is necessary behavior but is also enough of a burden to encourage alternate aproaches to event handling in the general case.

andrej: Do you agree with my sense that the relative frequency of events that trigger locking is few compared to events that do not trigger locking?

[andrej]

I agree with was written in previous comments. I also use "Lock front panel" in most cases and progress bar where necessary.

But on the other hand, I write a lot of small applications that are used by one or two users and for me it would be very useful if busy cursor appears during event execution.

Or maybe "Lock front panel" could have option to set busy cursor during event execution.

[vitoi]

Every check slows things down somewhat. As other's have said it's easy to use the cursor busy VIs. Also, as others have said, an event needs to be handled quickly or delegated to a consumer. You want your front panel to be responsive to user input. If an event takes (or can take) more than 50 ms, it's too long (20 ms is a better target).