Topic: Progress Bar

[CincyJeff]

I'm using DOSLib, specifically dos_getprogress, to display a progress bar to the user while blocks are being processed. Unfortunately, Windows keeps breaking in and adding "(Not Responding)" to the progress bar title and halting the bar even though the program is continuing to process. Does anyone know how to keep focus with the progress bar? Or another method?

[Lee Mac]

See here for an explanation of why this happens; as far as I am aware, the only way to avoid this is to obtain some form of user input whilst processing (e.g. include a grread call within your processing loop).

[CincyJeff]

Thanks Lee. That makes sense, but it is annoying. I'll try the dummy (grread) call.

[Lee Mac]

Thanks Lee. That makes sense, but it is annoying. I'll try the dummy (grread) call.

Just be aware that the user will need to move the mouse during processing for the program to continue - though, the slightest mouse movement will suffice.

FWIW, here's an example of this technique - the RUNCLOCK command works in this way.

[CincyJeff]

It's a no go. The (grread) seems to prevent the progress bar from progressing. It never updates even if the mouse is moved. Any other ideas?

[Lee Mac]

It's a no go. The (grread) seems to prevent the progress bar from progressing. It never updates even if the mouse is moved. Any other ideas?

Did you include the mouse-tracking argument?

(grread t)

[CincyJeff]

That I did not, however, when I did I found it unacceptable. I don't want to make the users move the mouse just for a progress bar and the program is halted if the mouse is not moved. It can take over a minute to process and it would be nice to inform the user how it is progressing. Thanks any way.

[Lee Mac]

That's the best I could suggest, unless you want to abandon AutoLISP for this task.

[kdub_nz]

I'm using DOSLib, specifically dos_getprogress, to display a progress bar to the user while blocks are being processed. Unfortunately, Windows keeps breaking in and adding "(Not Responding)" to the progress bar title and halting the bar even though the program is continuing to process. Does anyone know how to keep focus with the progress bar? Or another method?

Have you reported this to DosLib and provided sufficient information to allow the issue to be reproduced??
I'm sure Dale and co. would treat it with dispatch.

[MickD]

Progress bars can be difficult in any language as it is hard to measure progress on a running routine without interrupting it or getting some sort of feedback somehow.

What about using a GIF in a popup just to let the user know it's busy? You could also show the steps in text if you want to show a bit more information.

[hmspe]

I was never able to make progress bars work well so I went to reports on the command line with code similar to:

Code: [Select]

 
  (setq spin  0)

  ;;; get a selection set and convert to a list of enames

  (setq total (strcat " of " (itoa (length set1))))
  (foreach memb set1
 
    ;;; do stuff

    (setq spin (1+ spin))
    (if (= (rem spin 10) 0)
      (cond ( (< spin   100) (princ (strcat "\rProcessing     " (itoa spin) total)))
            ( (< spin  1000) (princ (strcat "\rProcessing    " (itoa spin) total)))
            ( (< spin 10000) (princ (strcat "\rProcessing   " (itoa spin) total)))
            (t               (princ (strcat "\rProcessing  " (itoa spin) total)))
      )
    )
  )
  (princ (strcat "\rTrimming " total " of " total))


[Lee Mac]

Regardless of the chosen display method however, AutoCAD will be rendered non-responsive after 5 seconds of continuous processing in AutoLISP.

FWIW, you can verify this using the following simple function -

Code - Auto/Visual Lisp: [Select]

1. (defun foo ( n / x )
2.     (setq x (getvar 'millisecs))
3.     (while (< (- (getvar 'millisecs) x) n))
4. )

Code - Auto/Visual Lisp: [Select]

1. (foo 2000) ;; no problem
2. (foo 6000) ;; non-responsive for 1s

[VovKa]

https://www.theswamp.org/index.php?topic=49381.msg544927#msg544927

[hmspe]

Lee,

I tested the routine I took the snippet from on a drawing with over 13000 applicable entities.  It ran to completion in about 96 seconds on Bricscad, and the command line was updated as expected.  I ran the same code in Autocad 2010 (after adding the functions necessary to emulate Bricscad's vle-functions) and it also ran to completion in about 4 minutes.  Not sure what I'm doing to avoid the timeout but it works for me.

[Lee Mac]

I tested the routine I took the snippet from on a drawing with over 13000 applicable entities.  It ran to completion in about 96 seconds on Bricscad, and the command line was updated as expected.  I ran the same code in Autocad 2010 (after adding the functions necessary to emulate Bricscad's vle-functions) and it also ran to completion in about 4 minutes.  Not sure what I'm doing to avoid the timeout but it works for me.

The program will still run to completion, but Windows will render the AutoCAD application as non-responsive after 5 seconds of processing; note that an application window being marked as non-responsive will not halt the processing, but is simply an automatic Windows response when not receiving any feedback from the application's GUI processor thread for 5 seconds.