Wie beheben Sie WPF UI Probleme?

Question

Ich arbeite an einer WPF-Anwendung, die manchmal seltsame Probleme aufweist und erscheint hängen in der Benutzeroberfläche. Es ist inkonsequent, es geschieht in verschiedenen Seiten, aber es passiert oft genug, dass es ein großes Problem ist. Ich sollte erwähnen, dass es nicht um eine echte hang ist, wie unten beschrieben.

war mein erster Gedanke, dass die Animationen einiger Tasten, um das Problem waren, da sie auf den meisten Seiten verwendet werden, aber sie die hängen immer noch auftreten, obwohl scheinbar ein bisschen weniger oft nach dem Entfernen. Ich habe versucht, in den Debugger zu brechen, wenn der Hang auftritt; jedoch gibt es nie einen Code anzuzeigen. Kein Code von mir ausgeführt wird. Ich habe auch bemerkt, dass die „hängen“ ist nicht vollständig. Ich habe Code, den ich das Formular läßt ziehen um (es keine Grenze oder Titel hat), die weiter zu arbeiten. Ich habe auch meine gewonnene Schließen-Schaltfläche, die funktioniert, wenn ich es klicken. Durch Klicken auf Tasten scheint tatsächlich zu funktionieren, wie mein Code ausgeführt wird, aber die UI einfach aktualisiert nie eine neue Seite zu zeigen.

Ich bin für jeden Rat suchen, Werkzeuge oder Techniken dieses seltsame Problem auf die Spur zu kommen, also, wenn Sie irgendwelche Gedanken haben, werde ich sehr zu schätzen es.

EDIT: Es ist einfach passiert wieder, so dass diese Zeit, als ich in den Debugger zu brechen versuchte ich zu „zeigen Demontage“ gewählt haben. Es bringt mich zu MS.Win32.UnsafeNativeMethods.GetMessageW. Das Stack-Trace folgt:

[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 Bytes
      WindowsBase.dll! System.Windows.Threading.Dispatcher.GetMessage (ref System.Windows.Interop.MSG msg, System.IntPtr hwnd, int MinMessage, int MaxMessage) + 0x48 Bytes       WindowsBase.dll! System.Windows.Threading.Dispatcher.PushFrameImpl (System.Windows.Threading.DispatcherFrame frame = {System.Windows.Threading.DispatcherFrame}) + 0x8B Bytes       WindowsBase.dll! System.Windows.Threading.Dispatcher.PushFrame (System.Windows.Threading.DispatcherFrame Rahmen) + 0x49 Bytes
      WindowsBase.dll! System.Windows.Threading.Dispatcher.Run () + 0x4C Bytes
      PresentationFramework.dll! System.Windows.Application.RunDispatcher (Objekt ignorieren) + 0x1e Bytes
      PresentationFramework.dll! System.Windows.Application.RunInternal (System.Windows.Window Fenster) + 0x6F Bytes       PresentationFramework.dll! System.Windows.Application.Run (System.Windows.Window Fenster) + 0x26 Bytes       PresentationFramework.dll! System.Windows.Application.Run () + 0x19 Bytes       WinterGreen.exe! WinterGreen.App.Main () + 0x5e Bytes C #       [Native nach Managed Transition]
      [Managed auf einheitlichen Übergang]
      mscorlib.dll! System.AppDomain.nExecuteAssembly (System.Reflection.Assembly Montage, string [] args) + 0x19 Bytes       Mscorlib.dll! System.Runtime.Hosting.ManifestRunner.Run (bool checkAptModel) + 0x6E Bytes       mscorlib.dll! System.Runtime.Hosting.ManifestRunner.ExecuteAsAssembly () + 0x84 Bytes       mscorlib.dll! System.Runtime.Hosting.ApplicationActivator.CreateInstance (System.ActivationContext Activa, string [] activationCustomData) + 0x65 Bytes       mscorlib.dll! System.Runtime.Hosting.ApplicationActivator.CreateInstance (System.ActivationContext Activa) + 0xa Bytes       mscorlib.dll! System.Activator.CreateInstance (System.ActivationContext Activa) + 0x3E Bytes
      Microsoft.VisualStudio.HostingProcess.Utilities.dll! Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssemblyDebugInZone () + 0x23 Bytes
      mscorlib.dll! System.Threading.ThreadHelper.ThreadStart_Context (Objektzustand) + 0x66 Bytes
      mscorlib.dll! System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext ExecutionContext, System.Threading.ContextCallback Rückruf, Objektzustand) + 0x6F Bytes
      mscorlib.dll! System.Threading.ThreadHelper.ThreadStart () + 0x44 Bytes

Answer 1

Versuchen Sie das randlose Verhalten des Fensters zu entfernen und sehen, ob das hilft. Auch Sie sind BeginInvoke () ing oder Invoke () 'ing keinen langen laufenden Betrieb?

Eine andere Sache, zu betrachten: Wenn Sie in Ihren Code zu brechen, versuchen, auf Threads suchen anders als Ihre Haupt-Thread. Einer von ihnen kann den UI-Thread blockiert.

Answer 2

Ihre WPF-Anwendung aufgrund von Leistungsproblemen hängen könnte. Versuchen Sie es mit Perforator , um zu sehen, wenn Sie irgendwelche Teile, die Software gerendert werden oder wenn Sie app zu viel Video-rAM verwendet wird.

Answer 3

Ein großes Werkzeug Snoop . Wirklich nett für das Betrachten, was WPF Objekte auf der visuellen Struktur zu einem bestimmten Zeitpunkt angezeigt werden. Ich bin nicht sicher, wie viel es helfen, aber es ist möglich, dass Sie mit vielen zusätzlichen Dingen, den UI-Thread sind Jamming es zu tun hat. Snoop kann in der Lage sein, Sie nach unten helfen zu verfolgen, was auf dem Bildschirm ist es, Ihnen eine Idee zu geben, was zu suchen.

Answer 4

Ich habe das randlose Verhalten entfernt, wie durch Bob King vorgeschlagen. Bis heute scheint, dass losgeworden des Problems zu haben.

Nun ist die Frage, warum und wie kann ich das Problem beheben? Das Produkt ist keine Grenze mit einigen abgerundeten Ecken und transparenten Teilen haben.

Answer 5

Hurra, ... es scheint, dass das Problem nicht auf randlose Fenster (zumindest in meinem Fall) verwendet ist.

Es gibt eine große Leistungseinbußen, wenn Sie AllowsTransparency auf true gesetzt. So viel von einem Hit so scheint es, dass die ganze Sache den UI-Thread hängen. Sehr seltsames Verhalten. Könnte im Zusammenhang mit diesem Ticket