FileReference.cancel

[Damon_Edwards]

The docs are confusing me a bit.  They say, "Calling this method does not dispatch the cancel event; that event is dispatched only when the user cancels the operation by dismissing the file upload or download dialog box."  Is the cancel event supposed to fire if you call fileref.cancel() after you've called fileref.upload()?  If it isn't, then what's a file upload dialog box?

[Colin Holgate]

The Method, Cancel, is what you use to cancel an upload or download. The Event, Cancel, is what is sent when the user clicks on Cancel in an upload or download dialog.

So, if you are downloading something already, and for some reason you need to cancel the download, you would use the Method. If your user clicks on something to do an upload or download, but then changes their mind, and clicks the Cancel button in the dialog, you can detect that event and maybe present an appropriate message.

This all relates more to desktop browser work, I don't know if you would get involed in this with mobile apps.

[Damon_Edwards]

The only dialog I picture in my head during the process is the file browse dialog, which makes sense if that fires when you hit Cancel in that.  I don't think I've seen modal Upload / Download dialog box before. 

"If your user clicks on something to do an upload or download, but then changes their mind, and clicks the Cancel button in the dialog, you can detect that event and maybe present an appropriate message."  What dialog???

[Colin Holgate]

Try this script in the timeline of a new FLA:

import flash.display.Sprite;

import flash.events.*;

import flash.net.FileReference;

import flash.net.URLRequest;

var downloadURL:URLRequest;

var fileName:String = "SomeFile.pdf";

var file:FileReference;

FileReference_event_cancel();

function FileReference_event_cancel() {

downloadURL = new URLRequest();

downloadURL.url = "http://www.[yourDomain].com/SomeFile.pdf";

file = new FileReference();

file.addEventListener(Event.CANCEL, cancelHandler);

file.download(downloadURL, fileName);

}

function cancelHandler(event:Event):void {

trace("cancelHandler: " + event);

}

Do a Test Movie. What appears? Does it look something like a dialog box? When you click Cancel, does something trace?

[Damon_Edwards]

So this is my situation - a user is in the middle of an upload (fileref.upload()) and hits my cancel button which calls fileref.cancel() on that file.  Well that cancel operation is blocking the UI from updating so there's a 3-4 second pause where you're thinking, 'huh, what's happening'.  What I want to do is present a message like 'cancelling' then remove that message when it's finished.  You see my problem in that calling cancel() doesn't fire the cancel event, but the docs are eluding to that it should if it's 'dismissing the file upload'.  What I don't understand is that's what I'm doing - and since I don't recall a modal upload dialog box I don't see when this event would ever fire.. 

[Damon_Edwards]

Ahh so it's talking about BEFORE the operation is executing.  I'm thinking during here

[Colin Holgate]

The Event version of Cancel would only happen before the transfer. The Method version of Cancel would only be called after the transfer has started. It does make it slightly confusing when the class has two things called exactly the same thing.

[Damon_Edwards]

Indeed it does. If it wasn't locking up the UI then I wouldn't even care, but now I need to know when the cancel operation is finished.  Back to the drawing board

[Joe ... Ward]

Since cancelling seems to be synchronous, wouldn't this work:

pseudo function

{

show "canceling" message

call cancel()

remove "canceling" message

}

[Colin Holgate]

Yes, what Joe said. The Method Canel isn't an event that has to work its way through the system, to sometime later actually do something. It's immediate.

[Damon_Edwards]

Sadly it doesn't work like that either. The method I call after calling

cancel() is called immediately even though it's not done cancelling. Watch

this video and keep the below code in mind [

http://www.youtube.com/watch?v=ZKX5VMPF2tM - sorry that's its sideways].

The notify method alpha tweens in, and doesn't happen before the cancel()

like it should - I'm guessing due to the tween which is being blocked by

cancel() - but the upload view is tweening out before the notify message is

showing, even though its after the cancel() call and it's also tweening. I

don't get it

private function cancelVideoUpload(e:UploadVideoViewEvent):void{

if(uploadVideoView.isUploading){

notify('Please wait while your upload cancels...');

videoDataFile.cancel();

clearUploadView();

} else {

clearUploadView();

}

}

private function clearUploadView():void{

TweenLite.to(uploadVideoView.uploadContainer, .5,

{y:-(uploadVideoView.height), ease:Expo.easeOut,

onComplete:removeUploadVideoView});

}

private function removeUploadVideoView():void{

_desktube.removeChild(uploadVideoView);

uploadVideoView = null;

}

[Colin Holgate]

Here, this helps:

http://xfiles.funnygarbage.com/~colinholgate/video/cancelvid.mov

I think there's something slow about your notify routine. The canceling seems to take place correctly.

[Colin Holgate]

By the way, do you get the same results with AIR 2.7 instead of AIR 3?

[Damon_Edwards]

Thanks for flippin that!  Here's the notify method, and here's the notification class http://dl.dropbox.com/u/1742552/Notification.as.  It seems like that's happening after because of the Tween - but what I don't get is why the uploadContainer is able to tween out but not remove itself before the no that happens

public function notify(str:String):void{

notification.width = stage.stageWidth / 2 > 400 ? 400 : stage.stageWidth / 2;

notification.field.text = str;

notification.redraw();

notification.x = int((stage.stageWidth / 2) - (notification.width / 2));

notification.y = int(stage.stageHeight - (notification.height / 2) - 100);

notification.alpha = 0;

_desktube.addChild(notification);

TweenLite.to(notification, 1, {alpha:1, ease:Expo.easeOut, onComplete:notificationOut});

}

I haven't tried this yet on the 2.7 SDK, but I will.

[Colin Holgate]

There are cases wher eFlash can leave junk on the screen. Maybe the upload thing was remvoed, but just has some dirt on the screen. Try putting a message into a visible textfield, so you can see at what moment the removechild happens.

It could be an AIR 3 graphical issue.

[Damon_Edwards]

I added a 1 second delay to the cancel() call and it's working smooth now.

Not the cleanest thing in the world but it'll do!