Unload event...?

I hae a UserControl that is used to put data in the db. When the user loads this pge/form/control a entry is created in the db to get the primary key for the data. While they use the page and upload picture the primary key is put in the pictures table. When they cancel everything is deleted and we are happy. BUT, if they close with the X close button on the browser everything gets screwed up. Unload fires every postback.

Does anyone know how to catch the actual closeing of the browser window...? This is a real problem I can't think of anyway to handle it except by putting a close this window and I'll delete your account message on there... of course I would be bluffing since I have no idea when the window is closed.

Thanks

You can put a BODY unload attribute and run javascript. That's about the best you can do..

My opinion: Since the web is disconnected, you should rethink that part of your application, because you can't count on Javascript to be running (user could always turn it off before they close the browser window)...

1) GUIDs can go a long way to resolving any possible conflict....

2) Until they hit save, picture entries are stored in a table passed around in viewstate.

2) You will have to check for erroneous picture files uploaded to the server at some other frequently called part of your application (logon perhaps), or make use of the system's temp folder and give ASPNET write access to that folder.

I broke the form into two parts the actual data saving and then the uploading of images. This works but I don't like it because the rest of my form that use images work fine with the upload being on the page before the data is saved. But, what can you do?

I'm suprised MS didn't add something for cases like this. I'm thinking that if the form submits to itself there could be an event that doesn't fire because it is post back but it fires when the user closes or navigates away from the page. I dunno.....

Well, MS can only work within the limits of the basic nature of HTTP, which of course, doesn't allow for rich functionality such as this.

Depending upon your project requirements or restrictions, it is of course possible to have the user install a component you supply when they request that page. Most projects restrict such activity basing it on the fact most users cringe when they see their browser asking if its ok to download and install something.

I may write a module or an extintion of the page class that does this. I have some ideas of how to handle it.

As long as you understand you can't catch a client-side browser close (body unload) without javascript.

I do. My thinking right now is that I am going to look into the page class and try to find where it decides that the form has been submitted to it's self and sets IsPostBack and see what I could do from there.... but I don't know. My mind says there is a way.

I got to say though I'm tired of hearing people say things like since I'm using dot net I don't want to use any javascript or you can't count on javascript.

The @#$% framework does everything it does through javascript........... except you know the serverside code but without the javascript your server code will never run.......

Ontop of that the javascript is pretty IE only. it does a little netscape check but that is it.

you should read the validation .js and smartnav.js sometime.....

javascript:__doPostBack(target,argument)

Client-side classes need javascript yes...

but the framework does not...

you can render perfectly operational pages in .net without the enable of javascript.

Certain classes such as linkbuttons of course require javascript to operate... but linkbutton use is not mandatory.

I iterate javascript may not be enabled, because you can open a gaping security hole if you don't keep that in mind.