Button action monitored with progress bar

Question

Let's say you have a palette with a button that has to do some time-consuming task when clicked:

downloadMyMovie[] := Pause[10];
CreateWindow[
 PaletteNotebook[
  Button["Do heavy work", downloadMyMovie[]; MessageDialog["Done"]]
 ]
]

Note that the "Done" dialogue is never shown because preemptive evaluations have a shorter time-out than 10s. While I could use Method->"Queued" it would give the impression that the job is finished instantly, because the button does not stick. Then, out of the blue the finish dialogue would pop up.

Question: Is there a simple template code that one can use to show some kind of progress-bar when the task is running so that the user sees the job is still running?

Answer 1

OK, I guess I found something myself while trying to circumvent RunScheduledTask.

DynamicModule[{prog = False},
  Column[{
   Button[
     "Do heavy work", 
      prog = True; Pause[10]; prog = False, 
      Method -> "Queued"
   ],
   Dynamic@If[prog,
     ProgressIndicator[Appearance -> "Percolate"], 
     Invisible[ProgressIndicator[Appearance -> "Percolate"]]
   ]
  }]
]

This gives a very responsive and nice looking progress-bar. Here in its use case:

Answer 2

I'm not sure if this is exactly what you need but this is what I've recently done to inform the user about ongoing calculation.

Usage

withProgressIndicator[proc, delay]

Performs a proc, and when it lasts longer than delay (default 0), a progress indicator in dialog is created. It will be closed after finishing the proc.

• It should be run on Main Link, with "Queued" method but it should not matter.

• You can Abort proc too.

• From your question seems that you don't want to block FrontEnd from user before finishing the task so feel free to change "ModalDialog" to "ModelessDialog".

Examples

Button["GO", withProgressIndicator[While@True, 1], Method -> "Queued"]

withProgressIndicator[Pause[5]; Print[1], .2]

Code

SetAttributes[withProgressIndicator, HoldFirst];

withProgressIndicator[proc_, delay : _?NonNegative : 1] := 
 Module[{dialog, scheduledTask, dialogPrompt},
  dialogPrompt[] := (dialog = CreateDialog[
      Column[{
        Dynamic@ProgressIndicator[Appearance -> "Indeterminate"],
        Button["Abort", 
         FrontEndExecute[FrontEndToken["EvaluatorAbort"]]; 
         DialogReturn[];, Method -> "Preemptive"]
        }],
      WindowFrame -> "ModalDialog", WindowFrameElements -> None, 
      WindowTitle -> "Processing..."]);

  scheduledTask = RunScheduledTask[dialogPrompt[], {delay}];
  proc;
  RemoveScheduledTask@scheduledTask;
  NotebookClose[dialog];
  ]

Answer 3

Building on Kubas code here is an alternative which solves some (minor) problems: it will not leave behind scheduled tasks when the abort button is used, it works equaly well when the Alt+. shortcut is used to abort and it might work better when aborting preemptive evaluations. Here is the code:

SetAttributes[withProgressIndicator, HoldFirst];

withProgressIndicator[proc_, delay : _?NonNegative : 1] := 
  Module[{dialog, scheduledTask, dialogPrompt}, 
   dialogPrompt[] := (
      dialog = CreateDialog[
        Column[{
         Dynamic[ProgressIndicator[Appearance -> "Indeterminate"]],
         Button["Abort", FrontEndToken["EvaluatorAbort"],Evaluator -> None]
        }], 
        WindowFrame -> "ModalDialog", 
        WindowFrameElements -> None,
        WindowTitle -> "Processing..."
     ]
   );
   scheduledTask = RunScheduledTask[dialogPrompt[], {delay}];
   CheckAbort[proc, $Aborted];
   RemoveScheduledTask[scheduledTask];
   NotebookClose[dialog];
 ]

The main change is that I use CheckAbort to check for aborts, which ensures that the cleanup-part is done in any case. That will make it possible to remove the scheduled task even when the computation was aborted and to close the progress dialog in the main code, not the button callback. As the button callback now only does the abort, we don't need a kernel for that and can let the frontend handle the callback diretly using Evaluator->None. I think that will work in some corner cases where the preemptive kernel-callback might not, but don't know how relevant that is. If that would cause problems, one of course could stick with the preemptive kernel-callback and replace the FrontEndToken with a FrontEndTokenExecute...