A general "progress function"

[c4s]

There are several functions that could take a while to complete. Especially those from the FileSystem library, but others as well. A few examples:

• Cipher: OpenCryptRandom(), CRC32FileFingerprint(), MD5FileFingerprint(), SHA1FileFingerprint()
• FileSystem: CopyDirectory(), CopyFile(), DeleteDirectory(), RenameFile()
• Ftp: ReceiveFTPFile(), SendFTPFile()
• Http: ReceiveHTTPFile()
• Image: LoadImage(), SaveImage()
• Mail: SendMail()
• Network: SendNetworkFile()

So I'd really like to have a general progress function, which returns the progress (between 0.0 and 1.0) for the function I've previously attached it to.

[STARGÅTE]

+1

• Sound: LoadSound()
• Sprite: LoadSprite(), SaveSprite()

or add some callback like: PackerCallback(@Procedure())
with ProgressCallback(Position, Length)

[moogle]

I prefer callback rather than the function as you can control it.
But for some of the functions it's really like asking the PB team to do your programming for you. You could well make your own functions to get a progress in the meantime.
Ie CopyFile could be done via a custom function using ReadFile(), then using that function you could make a copydirectory one.

FTP and HTTP with network functions and SendNetworkFile isn't really used anymore is it? Just use SendNetworkData and your own procedure. There's a code on the forum for fast buffered file transfer via SendNetworkData that you can adapt and use.

For the sprites and images and mail though yes it would be nice to have such a thing.

CRCFingerPrint has a sort of method built in to do a progress of a big file using it.

"The optional InitialValue parameter can be used to pass the checksum of a previous buffer. The result will then be the checksum of both buffers, as if it were calculated from one continuous buffer. This way calculating the checksum of large data can be broken down into a number of calculations on smaller buffers."

[USCode]

I prefer callback rather than the function as you can control it. ..."

Aren't callbacks Windows-only? Any new PB function needs to be cross-platform, that is one of PB's strongest attributes IMHO.

[STARGÅTE]

>> Aren't callbacks Windows-only?

No, a callback is just some like this (Prototype):

Code: Select all

Prototype.i AnyCallback(State.i)

Procedure MyCallback(State.i)
	Debug State.i
EndProcedure

Procedure AnyLongProzess(Callback.AnyCallback, Ticks.i, Delay.i)
	Protected I.i
	For I = 1 To Ticks
		Callback(I)
		Delay(Delay)
	Next
EndProcedure

AnyLongProzess(@MyCallback(), 8, 500)

[ts-soft]

Aren't callbacks Windows-only? Any new PB function needs to be cross-platform, that is one of PB's strongest attributes IMHO.

Callbacks are crossplattform, see for example the scintillagadget!

[USCode]

Ah, right - thanks. I guess I was only thinking of SetWindowCallback() ...

[Danilo]

How long does it take for you to load bitmaps using
LoadImage() and LoadSprite()?

I just loaded an JPEG picture, 4272x2848, 6.04MB
and it took between 400 and 500ms.

Why would somebody want a progress callback for that?
Wouldnt it be enough for you to update a progressbar yourself
after loading each image/sprite?
Or load the image as little blocks to memory and use CatchImage then?

[STARGÅTE]

Or load the image as little blocks to memory and use CatchImage then?

The loading of images and sounds in the memory is not the slow, slow is the decode of eg PNG and OGG.
And especially OGG sound (of several minutes) need a few seconds, if you do not use streaming.

[DarkDragon]

I like the idea of a general progress information.

[...] and it took between 400 and 500ms. [...]

Thats at the maximum! It should never be higher than 500ms, or the users will think more about what they do and get slower and slower. I don't know if I am allowed to quote something out of the source of this information (course at the university, but the presentation slides are not public, only for students), that's why I won't do it. There are several books about the cognitive psychology based usability engineering and human computer interaction.

Slow response time (> 0.5s) => user forgets his goals => user is more careful with next actions => user gets slower

[Derren]

OT:
Interesting Dark Dragon.
But how does that apply to a loading screen?

If the user manually selects something, for example a file to check its MD5 checksum, he anticipates a waiting time. He won't take more time to select the next file except the selected thw wrong file.
In this case the slowing down is due to the mistake.
I find if the computer takes too long to do something I act even quicker, not slower.

Behaviourism is just as an exact science as wheather forecasting. "We can observe everything, yet we can predict nothing"

/OT

+1 for the callback idea

[DarkDragon]

OT:
Interesting Dark Dragon.
But how does that apply to a loading screen?

If the user manually selects something, for example a file to check its MD5 checksum, he anticipates a waiting time. He won't take more time to select the next file except the selected thw wrong file.
In this case the slowing down is due to the mistake.
I find if the computer takes too long to do something I act even quicker, not slower.

Well, most of the time it won't be just a loading screen, but you can definately connect my statement with loading screens: the user might forget what he wanted to do after loading has finished. A progress bar helps a lot to keep the goals in mind, but it shouldn't stay still over a long timeperiod and move smoothly to 100%. Otherwise the user starts thinking about whether the program crashed or not. I sometimes even start a computer game, wait until loading has finished, all intros were skipped and then I don't know anymore on which server I wanted to play, or on which map and I shut the game down again.

[Derren]

But the 500ms rule can't be applied to a progress bar.
There's no way you can differentiate if a tick happens faster or slower than twice per second.
Especially since nobody watches a progress bar from start to end^^

If you want the MD5 checksum of one single file you don't care if it appears after 400ms or after 1200ms on your screen.
If you're expecting immediate response like when you select text and it doesn't highlight immediately (far less then 500ms) you'll get aggressive and not distracted or slow.

btw, I doubt that it makes much difference if you have a progress bar that continuously and with constant speed approaches its end over a period of 60 seconds, or if you don't have progress bar at all, or one that moves slowly and then "jumps", to you and your remembering the server you wanted to visit

[DarkDragon]

Then tell it the whole human computer interaction scene, if you don't believe them. I've heared the course about this topic and that's what you can get out of it.