Vista animated progress bar is slow

[Richard Robertson]

Today while working on something I found that the Vista animated progress bar is rather slow to update. I had my window close as soon as the actual progress was 100% finished, but the bar itself was only about 80% filled. I ran a couple tests and found it at least 600 milliseconds behind which created a clearly visible lag.

Does anyone know a solution to this?

[wraithdu]

I've seen it too in NSIS installers that complete really quickly. The 'Finish' button shows up before the progress bar is full. It happens on Win7 as well.

[Nutster]

What about doing a Sleep(1) to give it a chance to update?

ProgressSet($I) ; Do some GUI update here.
Sleep(1) ; Millisecond delay will give the display a chance to refresh, without putting a huge delay, nor huge demand on the processor.

Edited September 25, 2009 by Nutster
speeling mistake

[Richard Robertson]

Sleep of one millisecond isn't long enough, as I said I counted up to 600 milliseconds before it finished updating. (Also, I'm not writing in AutoIt. That's why it's in this forum not AutoIt support.)

The problem is that I wanted the progress bar to indicate when the window would close. So it was supposed to line up exactly.

I ended up using a different indicator for the closing time. It's owner drawn but I think my way is a little more interesting too.

Edited September 24, 2009 by Richard Robertson

[jvanegmond]

Richard, I have tested the WPF and Silverlight progress bars and they are very accurate. Maybe you can use the WPF progress bar as an alternative, but that means replacing the rest of your GUI too.

[Richard Robertson]

Richard, I have tested the WPF and Silverlight progress bars and they are very accurate. Maybe you can use the WPF progress bar as an alternative, but that means replacing the rest of your GUI too.

I'll play with WPF and see what I can do. As you already know, I haven't taken too well to WPF.

[jvanegmond]

You know where to find me. Report back if you get it working or if you have any questions.

[eukalyptus]

Hi

I found a workaround:

GuiCtrlSetData($hProgress, $iPercent + 1)
GuiCtrlSetData($hProgress, $iPercent) ;Vista and Win7 animated progressbars jumps back immediately

[wraithdu]

Interesting hack... the only problem is trying to set 100% :/

[GEOSoft]

I've found that anything using a loop is slow in Win 7.

[Richard Robertson]

I've found that anything using a loop is slow in Win 7.

What program doesn't use a loop?

[GEOSoft]

What program doesn't use a loop?

I was refering in particular to Compiled AutoIt Scripts. One of my scripts has a series of nested loops and it will never be fast on any machine at any time but if I run it against a very large script in XP it takes probably 10 seconds to complete. It takes at least 50% longer in Win 7 when run against the same script. And no I can't give you exact figures at the moment. I still have to reinstall both of those OSs so I'm relegated to Vista at the moment and I won't even look at running it in Vista.

[Jon]

The only thing that should be slower is GUI related stuff. Anything else and it's a bug.

[GEOSoft]

The only thing that should be slower is GUI related stuff. Anything else and it's a bug.

That could be related Jon. It's the progress bar that I'm looking at but it fills a treeview after it completes the function and that still happens after the progress gets to 100%. I've been accusing MS for it as usual. You know the story, if it's slow, tedious, feature rich or downright annoying then it's written by MS. Someday there will be a viable alternative.