Sticky Button Down State

You have several "real world" issues here and, as usual, they complicate code that looks very simple until you start adding the stuff to handle them. As I see it, you have four main issues: 1. How to stop a block of code being executed a number of times concurrently if someone repeatedly presses the button. This is important as REBOL can crash if someone tries this; 2. How to allow the user to cancel a long-running operation; 3. How to change a button state to show "in-progess" or some such; 4. How to show a progress bar. The last two are relatively trivial, so I'll leave them up to you. The first two need some extra code. In the rewrite of your code below, I've added: -- two extra "state variables" so we can track if a process is underway, and we can request a termination; -- A cancel button so the user can request the termination; -- wait 0 in the action loop -- important as otherwise the cancel action will be deferred until the main process is complete -- not what you want. ===== Cancel-requested: false in-process: false sites: [ http://www.rebol.com http://www.rebol.org http://www.reboltech.com http://www.rebolforces.com ] unview/all view layout [ button "Start Scan" [ if in-process [return true] in-process: true cancel-requested: false foreach site sites [ wait 0 if cancel-requested [in-process: false return true] print read site ] ;; for in-process: false ] ;; action button "Cancel" red [ cancel-requested: true ] ;; action ] ;; layout ===== [In the real, real world, you'd want to surround some of this with a 'try block so that the extra variables get set correctly in the event of an error -- otherwise, higher level recovery and restart code may leave the variables incorrectly set....If in-process is accidentally left true for any reason, the button becomes effectively disabled. Error-recover code can seem endless :-) ] Sunanda

Very true. Program hardening is not avoided in any development.

I don't do much View programming now, but when I do it would be great to see examples or a How-to. ^_^

Sounds complex... Thinking further about Anton's (Gabriele's) trick: Maybe the following could work: - Set button text to gray - Set feel to none at beginning of action block - Process actions - Reset feel to accept button clicks - Reset button text to original color Maybe this would not stop events from building in queue though. ~D

DN> Sounds complex... The complexity is there already. State machines help to *manage* it by making things explicit. Most programs contain an informal state machine of some kind. As soon as you need to disallow events, or handle them differently based on what the app is doing, you've got a state machine. The only difference in what I'm talking about is that you design them explicitly rather than setting flags here and there, disabling event triggers, and using nested SWITCH statements. Designing the state machine for your program forces you to identify all the possible states it could be in, what events can occur, and what you do for each event in each state. All that information is going to be expressed implicitly in your program anyway. What makes the "normal" way seem simpler is that we tend to ignore a lot of the things that can actually happen, so we're handling only a portion of all the possible cases. This is a great way to keep complexity at bay, but not a great way to build mission critical software. It is always best to express things as simply and directly as possible. Sometimes the only way to find the best solution is to try all the ways you can think of and compare them. :) -- Gregg

It only works if you return to the event handling system. To kill events you can use one of functions in eat.r: http://www.reboltech.com/library/scripts/eat.r see it in http://www.reboltech.com/library/html/eat.html --- Ciao Romano