WPF - Aléatoire accroché avec le navigateur de fichiers de comportement attaché

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"); 
       } 
     } 
    } 
} 

C'est un comportement attaché de simple et agréable qui ouvre automatiquement un OpenFileDialog lorsque vous cliquez sur une zone de texte et met le nom de fichier dans la boîte lorsque vous avez terminé.

Cela fonctionne peut-être 40% du temps, mais le reste du temps l'application entière se bloque. 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 (réf System.Windows.Interop.MSG msg, System.IntPtr hwnd, int minMessage, int maxMessage) + 0x48 octets WindowsBase.dll! System.Windows.Threading.Dispatcher.PushFrameImpl (System.Windows.Threading.DispatcherFrame frame = {System.Windows.Threading.DispatcherFrame}) + 0x8b octets WindowsBase.dll! System.Windows .Threading.Dispatcher.PushFrame (cadre System.Windows.Threading.DispatcherFrame) + 0x49 octets
WindowsBase.dll! System.Windows.Threading.Dispatcher.Run() + 0x4c octets
PresentationFramework.dll! System.Windows.Application .RunDispatcher (objet ignoré) + 0x1e octets
PresentationFramework.dll! System.Windows.Application.RunInternal (fenêtre System.Windows.Window) + 0x6f octets PresentationFramework.dll! System.Windows.Application.Run (System.Windows. fenêtre de fenêtre) + 0x26 octets PresentationFramework.dll! System.Windows.Application.Run() + 0x19 octets Debugatron.exe! Debugatron.App.Main() + 0x5E octets C# [native transition Managed]
[Managed to Native Transition]
mscorlib.dll! System.AppDomain.nExecuteAssembly (Assemblage System.Reflection.Assembly, chaîne [] args) + 0x19 octets mscorlib.dll! System.Runtime.Hosting.ManifestRunner.Run (booléen) checkAptModel) + 0x6e octets mscorlib.dll! System.Runtime.Hosting.ManifestRunner.ExecuteAsAssembly() + 0x84 octets mscorlib.dll! System.Runtime.Hosting.ApplicationActivator.CreateInstance (System.ActivationContext activationContext, chaîne [] 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
Mic rosoft.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, j'ai vu ce genre de chose avant de faire des choses asynchrones mais il n'y a rien de cela à ce stade. Le seul thread vivant est le fil de l'interface utilisateur! En outre, je toujours obtenir cette dernière instruction de débogage lorsqu'il 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 WPF WebBrowser dans une application WPF. J ai exactement le même problème. Le contrôle WPF WebBrowser (avec Google Earth lancé à l'aide de JavaScript) gèle environ 75% du temps lorsque je redimensionne la fenêtre horizontalement. Je reçois le même vidage de pile que celui indiqué ci-dessus. Quand je copie/exécute l'exécutable sur un PC différent (exécutant tous XP SP3) il fonctionne bien et ne se bloque jamais. J'ai aussi une application plus complexe qui est multi-threadée qui se bloque également avec un vidage de pile similaire (également en attente sur un message à l'intérieur de la bibliothèque Threading) sur ce PC mais pas sur un autre PC. L'application de contrôle WPF WebBrowser a le même problème si elle est ciblée pour .Net 3.5 ou 4.0. J'ai utilisé NETfx_Setupverifier pour vérifier que les installations .net sont correctes, mais je suspecte toujours qu'il y ait un problème avec .net ou un utilitaire COM qui provoque l'interopérabilité du .NET - COM interop. Il est également à mon avis que mon application attend un événement/message non géré qui n'arrive jamais à cause d'un problème d'interopérabilité. J'ai également écrit la même application simple en utilisant WinForms/WinForm WebBrowser Control et cette application ne se bloque jamais sur le même PC.

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

Answer 2

Voici quelques faits et questions presque aléatoires qui pourraient vous aider.

Tout d'abord, je n'ai pas pu reproduire votre problème. Peu importe combien j'ai essayé. Ça a toujours marché. La trace de pile me semble également bonne: elle continue de traiter les messages en boucle. Qu'est-ce qui vous trouble? Géré à la transition native?

Vous ne pouvez pas avoir un thread dans l'application WPF. Que voyez-vous dans la fenêtre Threads dans VS Debugger? Lorsque je clique sur break tout, je vois l'appel à ofd.ShowDialog() dans la trace de la pile de threads principale, et un thread de travail nommé .NET SystemEvents reste dans WindowThreadProc(), en attente d'un objet de synchronisation. Que vois-tu?

On dirait que vous êtes dans une impasse en quelque sorte. Essayez le retour à OpenFileBrowser() contenu dans try... catch{}. Y a-t-il des erreurs?