locked
Blocking the UI thread before returning to a background thread RRS feed

  • Question

  • So I have a VM running in the background of my SL app. Everything works fine so far. I use Dispatcher to update the UI and that works great.

    Now I have an event fired from the VM into the SL App that requires user interaction before returning. It's basically a Save Game event.

            void engine_SaveRequested(object sender, SaveRestoreEventArgs e) {
                SaveWindow.InputBoxControl = InputBox;
                Dispatcher.BeginInvoke(() =>
                {
                    SaveWindow.Visibility = Visibility.Visible;
                    SaveWindow.CloseButton.Focus();
                    InputBox.Visibility = Visibility.Collapsed;
                });
                // TO DO - need to block execution until SaveWindow is done...
                //e.Stream = new System.IO.IsolatedStorage.IsolatedStorageFileStream(SaveWindow.FilePath,
                                           FileMode.CreateNew,     System.IO.IsolatedStorage.IsolatedStorageFile.GetUserStoreForSite());
            }

    I have a SaveWindow control that gets displayed (works fine) and when the user clicks OK, execution should continue by sending an Isolated Storage stream back to the background thread for it to complete the save game process.

    Problem is...I don't know how to block the execution until the user clicks OK.

    Any ideas?

    David C.

    Monday, August 4, 2008 3:56 PM

Answers

  • You are basically asking for a form of procedural modality within the UI which Silverlight does not have (ie. the equivalent of Win32 MessageBox where it "waits" for input and then continues execution). The workaround approach is that the Click event on the close button must fire an event handler, and the event handler does the Isolated Storage operations. You essentially split the work in two - the first half to set up the UI, the second half to respond to the user's click.

    If the background thread needs to block, on the other hand, you can simply use something like an AutoResetEvent (or various other Waitable objects), and when you "send back" to the background thread, you might store eg. a member variable somewhere, and then "set" the AutoResetEvent to "wake up" the waiting background thread.

    Monday, August 4, 2008 5:44 PM

All replies

  • And just to note...I'm aware that I'm probably crossing threads (crossing the streams!) here and it may be that we have to alter our VM engine to do saves differently. I was just hoping there was some way to avoid altering the VM since I have it working in WPF, WinForms, and Mono WinForms as-is with only a few minor changes for SL.

    David C.

    Monday, August 4, 2008 4:11 PM
  • You are basically asking for a form of procedural modality within the UI which Silverlight does not have (ie. the equivalent of Win32 MessageBox where it "waits" for input and then continues execution). The workaround approach is that the Click event on the close button must fire an event handler, and the event handler does the Isolated Storage operations. You essentially split the work in two - the first half to set up the UI, the second half to respond to the user's click.

    If the background thread needs to block, on the other hand, you can simply use something like an AutoResetEvent (or various other Waitable objects), and when you "send back" to the background thread, you might store eg. a member variable somewhere, and then "set" the AutoResetEvent to "wake up" the waiting background thread.

    Monday, August 4, 2008 5:44 PM