WPF - Aléatoire suspendu avec comportement attaché navigateur de fichiers

Question

J'ai un comportement attaché défini thusly, ..

    public static class FileBrowserBehaviour
{


    public static bool GetBrowsesOnClick(DependencyObject obj)
    {
        return (bool)obj.GetValue(BrowsesOnClickProperty);
    }

    public static void SetBrowsesOnClick(DependencyObject obj, bool value)
    {
        obj.SetValue(BrowsesOnClickProperty, value);
    }

    // Using a DependencyProperty as the backing store for BrowsesOnClick.  This enables animation, styling, binding, etc...
    public static readonly DependencyProperty BrowsesOnClickProperty =
        DependencyProperty.RegisterAttached("BrowsesOnClick", typeof(bool), typeof(FileBrowserBehaviour), new FrameworkPropertyMetadata(false, new PropertyChangedCallback(BrowsesOnClickChanged)));


    public static void BrowsesOnClickChanged(DependencyObject obj, DependencyPropertyChangedEventArgs args)
    {
        FrameworkElement fe = obj as FrameworkElement;

        if ((bool)args.NewValue)
        {
            fe.PreviewMouseLeftButtonDown += new MouseButtonEventHandler(OpenFileBrowser);
        }
        else
        {
            fe.PreviewMouseLeftButtonDown -= new MouseButtonEventHandler(OpenFileBrowser);
        }
    }

    static void OpenFileBrowser(object sender, MouseButtonEventArgs e)
    {
        var tb = sender as TextBox;
        if (tb.Text.Length < 1 || tb.Text=="Click to browse..")
        {
            OpenFileDialog ofd = new OpenFileDialog();
                ofd.Filter = "Executables | *.exe";
                if (ofd.ShowDialog() == true)
                {
                    Debug.WriteLine("Setting textbox text-" + ofd.FileName);
                    tb.Text = ofd.FileName;
                    Debug.WriteLine("Set textbox text");
                }
        }
    }
}

Il est un comportement attaché de simple et agréable qui apparaît une ouverture OpenFileDialog lorsque vous cliquez sur une zone de texte et met le nom de fichier dans la boîte lorsque vous avez terminé.

Il fonctionne peut-être 40% du temps, mais le reste du temps, l'application se bloque tout. La pile d'appel à ce point ressemble à ceci -

[Managed to Native Transition]  

  

WindowsBase.dll! MS.Win32.UnsafeNativeMethods.GetMessageW (ref System.Windows.Interop.MSG msg, System.Runtime.InteropServices.HandleRef hWnd, int uMsgFilterMin, int uMsgFilterMax) + 0x15 octets
      WindowsBase.dll! System.Windows.Threading.Dispatcher.GetMessage (ref System.Windows.Interop.MSG msg, System.IntPtr hwnd, int minMessage, int maxMessage) + 0x48 octets       WindowsBase.dll! System.Windows.Threading.Dispatcher.PushFrameImpl (cadre System.Windows.Threading.DispatcherFrame = {} System.Windows.Threading.DispatcherFrame) + 0x8b octets       WindowsBase.dll! System.Windows.Threading.Dispatcher.PushFrame (cadre de System.Windows.Threading.DispatcherFrame) + 0x49 octets
      WindowsBase.dll! System.Windows.Threading.Dispatcher.Run () + 0x4c octets
      PresentationFramework.dll! System.Windows.Application.RunDispatcher (objet ignorer) + 0x1E octets
      PresentationFramework.dll! System.Windows.Application.RunInternal (fenêtre System.Windows.Window) + 0x6f octets       PresentationFramework.dll! System.Windows.Application.Run (System.Windows.Window fenêtre) + 0x26 octets       PresentationFramework.dll! System.Windows.Application.Run () + 0x19 octets       Debugatron.exe! Debugatron.App.Main () + 0x5E octets C #       [Originaire de transition gérée]
      [Réussi à la transition autochtone]
      mscorlib.dll! System.AppDomain.nExecuteAssembly (assemblée System.Reflection.Assembly, string [] args) + 0x19 octets       MSCorLib.dll! System.Runtime.Hosting.ManifestRunner.Run (bool checkAptModel) + 0x6E octets       mscorlib.dll! System.Runtime.Hosting.ManifestRunner.ExecuteAsAssembly () + 0x84 octets       mscorlib.dll! System.Runtime.Hosting.ApplicationActivator.CreateInstance (System.ActivationContext ActivationContext, string [] activationCustomData) + 0x65 octets       mscorlib.dll! System.Runtime.Hosting.ApplicationActivator.CreateInstance (System.ActivationContext ActivationContext) + 0xa octets       mscorlib.dll! System.Activator.CreateInstance (System.ActivationContext ActivationContext) + 0x3E octets
      Microsoft.VisualStudio.HostingProcess.Utilities.dll! Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssemblyDebugInZone () + 0x23 octets
      mscorlib.dll! System.Threading.ThreadHelper.ThreadStart_Context (état d'objet) + 0x66 octets
      mscorlib.dll! System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext ExecutionContext, rappel System.Threading.ContextCallback, état de l'objet) + 0x6f octets
      mscorlib.dll! System.Threading.ThreadHelper.ThreadStart () + 0x44 octets

Maintenant, je l'ai vu ce genre de chose avant quand faire des choses asynchrones, mais il n'y a rien de tout cela se passe à ce moment-là. Le seul fil est vivant le fil de l'interface utilisateur! En outre, I toujours obtenir cette dernière déclaration de débogage quand il ne se bloque.

Quelqu'un peut-il me diriger dans la bonne direction? Celui-ci me rend fou!

Answer 1

J'ai une application WPF très simple qui utilise le contrôle WebBrowser WPF dans une application WPF. J ai exactement le même problème. Le contrôle WebBrowser WPF (avec Google Earth a lancé en utilisant JavaScript) bloque environ 75% du temps quand je redimensionnez la fenêtre horizontalement. Je reçois la décharge exacte même pile comme indiqué ci-dessus. Lorsque je copie / exécuter l'exécutable sur un autre PC (tous en cours d'exécution XP SP3), il fonctionne très bien et ne se bloque. J'ai aussi une application plus complexe qui est multi-thread qui pend également avec une décharge de pile similaire (également en attente d'un message dans la bibliothèque Threading) sur ce PC, mais pas un autre PC. L'application de contrôle WebBrowser WPF a le même problème si elle est prévue pour 3,5 ou 4,0 .Net. Je NETfx_Setupverifier pour vérifier les installations .net sont correctes, mais je pense toujours qu'il ya un problème avec soit .net ou d'un utilitaire COM qui est à l'origine du .NET - COM Interop instable. Il est également je pense que mon application est en attente sur un événement non géré / message qui arrive jamais à cause d'un problème avec l'Interop. J'ai écrit aussi la même application simple en utilisant WinForms / WinForm WebBrowser contrôle et que l'application se bloque jamais sur le même PC.

Quelqu'un at-il des suggestions sur la façon de traquer la cause? Je pense à désinstaller complètement / réinstaller les cadres .NET même si elles ont été vérifiées correctement. Je ne sais même pas où chercher des anomalies sur le côté COM.

Answer 2

va ici quelques faits presque aléatoires et questions, qui pourraient vous aider.

Tout d'abord, je ne pouvais pas reproduire votre problème. Peu importe combien j'ai essayé. Il a toujours travaillé.

Trace de la pile semble également bon pour moi: il maintient la boucle de traitement des messages. Qu'est-ce que vous embrouille exactement? Réussi à transition natif?

Vous ne pouvez pas avoir un fil dans l'application WPF. Qu'est-ce que vous voyez dans la fenêtre de discussion dans VS Debugger?

Quand je frappe briser tout ce que je vois l'appel à ofd.ShowDialog () dans la principale trace de la pile de fil, et un thread de travail nommé .NET reste SystemEvents dans WindowThreadProc (), en attente sur un objet de synchronisation. Que voyez-vous?

On dirait que vous êtes entré dans une impasse en quelque sorte.

Essayez wrap contenu OpenFileBrowser() dans try... catch{}. Y a-t-il des erreurs?