I have a progress bar that I use to indicate saving a file.
My app files are very small and save in a split second. So I decided to just show a progress bar that says “Saving…” just as an acknowledgement - it’s more of a mental thing that I personally like. It’s a small modal window that does its thing using a timer for approx. 1 second, then closes.
This all works perfectly in Win7, but testing recently in Win8.1 the progress bar doesn’t work the same. The progress bar in Win7 starts at zero and goes to the end (max) but in Win8.1 the progress bar starts at zero but finishes around 60% through.
There is no detrimental issue caused to the running app, but it just doesn’t look good. It looks as though the file starts saving, then had a problem part way through possibly leaving the user unsure. (or maybe it’s just me.)
In the open event of the progress bar window:
[code] // Set the timer update period
TimerProgressSAVE.Period = 20
// Set the current start value to 0
ProgressBarSAVE.Value = 0
// Set the maximum value: small number = faster, large number = slower
ProgressBarSAVE.Maximum = 80
// Run the timer to move the progress indicator
TimerProgressSAVE.Mode = 2[/code]
In the Timer Action Event:
[code] // Add 2 to the value
ProgressBarSAVE.Value = ProgressBarSAVE.Value + 2
// If we’ve reached the end
If ProgressBarSAVE.Value > ProgressBarSAVE.Maximum Then
// turn the timer off
Me.Mode = 0
WindowProgressSave.Close //close out
There’s not really much to it.
My logic says it should work fine - hopefully there is something I’ve missed. Any alternate solutions would be good.
Based on this, the progress bar value has nothing to do with the actual progress?
Its just ‘number of times the timer managed to fire before the job was complete’?
Better would be to monitor the actual progress if possible… eg if you are copying 200 files then the progress bar should be showing bar.maximum * copiedfiles/totalfiles
You can set that value as a global property while you work, then have the timer just change the bars value to whatever the global value is.
(The ‘indeterminate’ progress bar used to be good for this sort of thing - a Barber’s pole rotating on OSX
I dont think it works any more, however)
You could always manually set the progress bar value to ‘maximum’ when your work ends, wait a second or so, then close the window. At least they would then see a full bar before it went away
Yes, the progress bar has nothing to do with the actual progress. The saved files are so small that if I did do it based on file size or time, there would be nothing to indicate the file was saved. What I’m doing in a “mock” save indicator.
In fact, the file has already been saved before the user actually sees the progress indicator. Like I said, it’s a mental “confirmation”, nothing more, nothing less. If I press CTRL+S in a windows app, I feel more confident that the file is saved if I see a progress indicator.
The progress bar only needs to appear for approx. 1 second and progress from start to finish.
I can’t get it working with Win8.1 (ie. it doesn’t behave the same as Win7).
Is there any difference is you add:
ProgressBarSAVE.Value = ProgressBarSAVE.Maximum
Me.Mode = 0
If not, then you can add the following (wasting) code between the previous 2 lines before WindowProgressSave.Close:
// This method just wastes some CPU time to simulate an actual method
// that may be performing a lengthy process.
Dim waitUntil As Integer = Ticks + 15
While Ticks < waitUntil
- code from Xojo’s example: Desktop - UpdateUIFromThread - UIThreadingWithTimer
Starting with Windows 8 there is a change with progress bars where it has an animation system built in. This means you can set the bar to 100 and it will draw a nice scrolling bar from 0 to 100 instead of just instantly setting it to 100.
There is obviously a delay with this as it takes time to get to where it needs to be and as you’re causing so many alterations to the value a backlog of these scrolling systems are backing up and they continue to run after you set the value to max.
So, you need to wait a moment before closing the window for those systems to “play out” and finish the animation of the scrollbar as its lagging behind what you’ve set the value to, as when you close the window its still playing the scrolling animation for the 60-70 region.
To work around this just replace:
WindowProgressSave.Close //close out
Xojo.Core.Timer.CallLater(600, AddressOf WindowProgressSave.Close)
You can see this perfectly by putting a progress bar on the window and setting it to 100 with a button, you see the bar progress with a nice animation, the problem is that its instantly at 100 and you’d technically close the window even before it moved.
Its nothing you’ve done wrong, you just need to code around the new feature.
Something to look forward to trying when I get home (this evening) from my day job.
Thanks Julian (and the rest) - this works perfectly and thanks also for the good explanation.
I guess it’s something I need to keep in mind for the future.
This is a good opportunity to stick the boot into the Window 8 operating system.
I don’t know who the developers were, but they all should be rounded up (if they haven’t been already) and sent off to a purpose-built re-education facility and severely . . . ummm . . . severely “re-educated”.
It should also be ascertained what powerful drugs they were on (obviously very powerful indeed) when the concept was conceived. Then make sure that drug is never never ever accidentally released into the wider population.