Anguel,
Are you running into problems where multiple button clicks are being registered before the control disables? I'm unable to click twice anywhere near fast enough to beat the queue/dequeue operation. The infinitely quick double click may still register twice and relying on speed is not a good practice so from a conceptual standpoint you bring up a valid point and one we were aware of. As with any decision in programming there are trade-offs. We decided to disable controls in the consumer for one main reason.
The consumer loop is the keeper of state. If someone were to expand our templates or sample projects and wanted to handle events differently depending on the state then this logic would be in the consumer loop. The event structure's job is to catch that the event happened and delegate immediately. It's up to the consumer loop to decide what to do with that information.
e..g. the acquire button should be disabled when the acquisition is running, not when the acquisition is requested. If for some reason the application couldn't start (hasn't been configured yet, an error in initialization, the consumer loop has already exited, queue reference is bad) you don't want the UI to have automatically updated based on a hard coded assumption.
Another reason for doing it the way we did it is if there are multiple UIs (perhaps physical buttons, a remote control device, or an automated scheduler) that could request that the system start acquiring then we'd need to disable the local controls even though the event didn't fire.
We decided that these situations were more likely than someone being able to click fast enough to queue up multiple commands that would cause problems to the application. [On a related note I feel like relying on the disabled state of a control to ensure your program doesn't get into a bad state is not a best practice -- writing the Value (Signaling) property on a disable control will still fire the value changed event. If recieving the event out of turn is catestrophic you should discard the errant event rather than trying to prevent it.]
I'll admit we're often guilty of over-hyping things like the sample projects but they are expert created starting points rather than solutions. For any concrete application there are certain tradeoffs we made that may or not make sense in that situation and it's up to the programmer to change those things. Over time we'll get better at documenting which tradeoffs need to be considered in certain situations.
We feel giving everyone a passable starting point for a well designed application is better than making everyone start with a blank VI.
I hope we can continue to have conversations like these. Best practices aren't set in stone, they evolve over time and I hope the templates and sample projects we provide will evolve as the state of the LabVIEW art does.
And to Mike -- I wholeheartedly agree and apologize about the state of examples in Example Finder - we've tried to make inroads with that this year and you should see some progress in that regard come August.
