locked
SubmitChanges Synchronously? RRS feed

  • Question

  • Can you call SubmitChanges Synchronously?

    Heres the story, in javascript body onunload,  I'm opening a javascript confirm asking 'Set Status to Log off', if yes I'm firing a silverlight method which updates an entity property and calls SubmitChanges. It gets to SubmitChanges, but the message never reaches the server and the database is not updated. I suspect that if I could call SubmitChanges synchronously it would wait and not close out the app before all is good. However it doesn't appear that this is possible, is it? Has anyone been able to solve this type of closing browser action a different way?

    Thanks!

    Tuesday, February 22, 2011 6:02 PM

Answers

  • 1) No, you cannot submit synchronously
    2) Once the browser starts to close the network stack is disabled cutting off the DomainContext. You need to cancel the unload (if possible, not sure on the javascript side), and then save.

    Tuesday, February 22, 2011 6:15 PM

All replies

  • 1) No, you cannot submit synchronously
    2) Once the browser starts to close the network stack is disabled cutting off the DomainContext. You need to cancel the unload (if possible, not sure on the javascript side), and then save.

    Tuesday, February 22, 2011 6:15 PM
  • Thanks Colin, I'm pretty sure its not possible to cancel a browser close in javascript only prompt them to confirm they want to close, and I don't think it lets you take any other action, otherwise you could keep users from ever closing a browser right?, not cool. Can any javascript gurus confirm this? I guess I should ask in a javascript forum.

    Tuesday, February 22, 2011 6:20 PM
  • Hi. Like Colin says you can integrate with the JavaScript unload event and ask the user if they really want to close the browser window when you have unsaved changes. They can then choose to cancel and keep the window open. Mark wrote an article on that.

    Edit:


    only prompt them to confirm they want to close

    Yes, exactly that. Unfortunately that's all we got, but it's probably better than losing all changes without any warning.


    Tuesday, February 22, 2011 6:23 PM