Fix for FLUID-1947

[Eli Cochran]

It took me a long time to get my head around FLUID-1947 but finally I  
figured out that what was happening was because we insert a delay  
between each file progress event. We do this to simulate what would  
happen during and actual upload, and give the user a chance to respond  
to the behavior of the component in a simulated upload.

What was happening was that between the moment that we queued up the  
next progress and the time that the progress actually happened, the  
user could click the Stop Upload button thus firing a bunch of other  
events. Depending on the timing of the click, different odd things  
would happen.

So instead of doing:

	check if we can progress
		set next progress on the timer
			timer fires next progress
				next progress
				

We need to

	check if we can progress
		set next progress on the timer
			timer fires next progress
				check if we can progress
					next progress

I also removed the delay on finishUploading because this was another  
place where the user could slip an event in, and it wasn't really  
necessary for the simulation.  At the point that the finishUpload  
fires, we should not wait but start in immediately into the next file.

And I switched the code to use that.queue.isUploading instead of  
that.demoState.shouldPause which meant that pauseDemo could be  
simplified a little bit and we're using a consistent variable to  
checking the state of the upload.

Obviously this needs a very detailed review.

- Eli


-------------- next part --------------
A non-text attachment was scrubbed...
Name: FLUID-1947.b.patch
Type: application/octet-stream
Size: 4524 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20081212/ac628493/attachment.obj>
-------------- next part --------------


. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley