Question

I am developing a wpf application using the prism framework [.net 4.0]. I have implemented a popup window using the RegionPopupBehavior from the StockTrader RI. Now when I close the main window either using the close button in upper right of window title bar [main window], or using

Application.Current.Shutdown() 

call in a button click, I get a win32 exception with the message “Invalid Window Handle” and the stack trace is all interop calls back to the app Run() call.

I have search google and SO for answer to no avail. I have set break during close and checked the Windows collection but it only shows the main window as active [if popup is hidden]. Note that I get the error whether the popup window is open or not when I hit close.

Here is the stack trace:

at MS.Win32.HwndWrapper.DestroyWindow(Object args)
   at MS.Win32.HwndWrapper.Dispose(Boolean disposing, Boolean isHwndBeingDestroyed)
   at MS.Win32.HwndWrapper.Dispose()
   at System.Windows.Interop.HwndSource.Dispose(Boolean disposing)
   at System.Windows.Interop.HwndSource.WeakEventDispatcherShutdown.OnShutdownFinished(Object sender, EventArgs e)
   at System.EventHandler.Invoke(Object sender, EventArgs e)
   at System.Windows.Threading.Dispatcher.ShutdownImplInSecurityContext(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Windows.Threading.Dispatcher.ShutdownImpl()
   at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
   at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
   at System.Windows.Threading.Dispatcher.Run()
   at System.Windows.Application.RunDispatcher(Object ignore)
   at System.Windows.Application.RunInternal(Window window)
   at System.Windows.Application.Run(Window window)
   at System.Windows.Application.Run()
   at RNDGroup.App.App.Main() in c:\Users\jgilliland\Projects\Common\Source\Prism GUI\RNDGroup.App\obj\x86\Release\App.g.cs:line 0
   at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
   at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
   at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

my question is either how do I fix this if anyone has seen it before in similar circumstances, or how do I go about debugging this win32 exception further? Thanks, j

Answer 1

The technical lead on my team found the problem and removed this error. The popup region is being used to show/hide or rather activate/deactivate the VirtualKeyboardView in its own window. The occurrence of the “invalid window handle” win32 exception began when I switched from showing the keyboard when the user clicked a button, to showing the keyboard whenever a textbox gets focus.

The focus events are a little funny, I was seeing what amounted to multiple focus events for the same click/focus by the user. Anyways, the end of the story is that I realized the issue was repeated focus events but I could not find the source of the problem. My teammate was able to track down an issue of recursion that arose from these seemingly repeated focus events for the textbox. The solution was to track the last textbox element that caused the keyboard to be shown and essentially ignore the repeated focus events. This removed the win32 exception for invalid window handle.

I know that this was an odd question and an even odder answer, but it is the very first time I have posted a question in a forum like this and I obviously need to learn how to better ask the question in the first place. But, thanks to my wonderfully helpful team lead, I was able to get rid of the error and move on with the implementation of this virtual keyboard in wpf in a secondary popup region. It has been a learning experience all the way around.

Here is some code that might help clarify the answer. This is from the VirtualKeyboardService that manages showing and hiding the keyboard view.

/// <summary>
/// Opens the keyboard.
/// </summary>
public void OpenKeyboard()
{
    lock (_lock)
    {
        // allow for ignoring a refocus one time
        if (_ignoreOnce)
        {
            _ignoreOnce = false;
            return;
        }
        // open keyboard if not already open
        if (!_isKeyboardOpen)
        {
            var viewName = typeof(VirtualKeyboardView).FullName;
            _regionManager.RequestNavigate(RegionNames.PopupRegion, new Uri(viewName, UriKind.Relative));
            _isKeyboardOpen = true;
            _lastImpression = null;
        }
    }
}

And this is the method that closes the virtual keyboard, this is called from the keyboard’s view model when the user clicks a close button, or when they hit the enter, tab, or esc key. It is also called from an event handler for the MainWindow’s Activated event.
///
/// Closes the keyboard.
///
/// if set to true [revert text].
public void CloseKeyboard(bool revertText = false)
{
lock (_lock)
{
// close the keyboard view
var view = _regionManager.Regions[RegionNames.PopupRegion].ActiveViews.FirstOrDefault();

        if (view != null)
        {
            _regionManager.Regions[RegionNames.PopupRegion].Deactivate(view);
            _isKeyboardOpen = false;
            _lastImpression = CurrentTarget;
        }

        // revert text if needed
        if (revertText && CurrentTarget != null)
        {
            CurrentTarget.Text = CurrentText;
        }
    }
}

That was tricky too, that is where the ignore once comes into play. I had to be able to close the keyboard view when the user clicked “away” which activates the mainwindow, which is likely focused on a textbox, which caused the keyboard view to reappear. Ignore once option allows breaking out of that loop. There were a lot of different use cases involved in automatically showing a virtual keyboard. I learned a lot about using behaviors and composite commands in wpf…