Walter,
Thanks a lot for your ideas. I think, we have to enhance our progress bar class using these ideas. I actually wanted to do it long time ago, but there are two problems, which don't allow me to proceed:
1) We have a Guardian of all our common code and classes, and she and only she can make changes there. I was beaten several times already, when I wanted to improve our classes or common code and instead of gratitudes, received furious messages from my colleagues.
2) When I proposed the similar change while ago, my manager told me, that it's a nice idea, but now for now.
I guess, I have to wait :(
>Nadya,
>
>I think you should reconsider Ed's message (After all he did use my proposal to speed up DOEVENTS ;-) )
>
>
IF CHRSAW() OR MDOWN()
> DOEVENTS
>ENDIF
>
>Seriously, You can use this mechanism in a progressbarclass to check if the cancel button is actived (Either by its howkey, Enter or Mouseclick). If it is, set a Processcanceled property to .t., hide the progresbar and check for Processcanceled in the calling routine and abort it of neccesary.
>
>Besides it gives the user the ability to click (because users want to click everything by nature) for cancel, it has some other interesting side effects:
>
>1. You can move the progresbar during the process, like in many other (multi threaded ?) windows programs
>2. During this long process, you can even start other (smaller) routines, forms, activating menubars etc, giving your application a bit of a multitasking look.
>
>Walter,
If it's not broken, fix it until it is.
My Blog