In all fairness, the people at Xamarin did a tremendous job in porting C#/.NET to Android. Still, there are (so many) bugs that are sometimes/often annoying.
So, here’s a link to my bug report of the day:
Today’s bug comes with ToirtoiseHg:
Not just a visual bug. Clicking on Cancel had no effect. Dialog had to be closed with the window’s close button.
This new daily (*cough*) post category will document me being frustrated about the software I use. I have the feeling that I encounter a new bug everyday in some software that I use. Let’s see whether this holds true.
First entry:
VMWare Fusion has encountered an error and has shut down the virtual machine.
Solved it by disabling “Accelerate 3D graphics” for the machine.
Manchmal nervt Programmieren einfach. Da hat man folgende Zeile in C++ (bääääh):
PathOption test = mQ1Settings->WorldDir;
Versucht man diese mit Visual C++ 2010 zu kompilieren, stürtzt der Compiler ab. WTF?
Ok, kann ja mal passieren. Also danach gegoogelt. Zu dem Problem gibt es auch schon einen Bug-Report bei Microsoft. Allerdings meint der Verantwortliche dazu:
I can confirm that this is a bug in our compiler. This crash is unfortunate, but … blablabla …, we believe that this is not critical to fix in the next release.
Ein Compiler-Fehler ist “not critical”???
Nach diesem Statement folgt dann noch:
We will keep this bug in our database and will reconsider it for future releases.
Aja. Deshalb hat der Bug-Report auch den Status “Geschlossenes als nicht lösbar”. Klingt natürlich total danach, dass man sich damit später noch mal befasst.
Na gut. Zum Glück gibt es ja die Möglichkeit, seinen eigenen Senf zu dem Bug-Report abzugeben. Dafür muss man sich zwar registrieren, aber einen Account bei Microsoft’s Bug-Tracker könnte man ja evtl. häufiger gebrauchen
Also schnell auf “Registrieren” geklickt, irgendwelchen AGBs zugestimmt, und dann das:
WTF? Das ganze noch zwei Mal probiert, mit dem gleichen Ergebnis.
Schon sichtlich genervt, gebe ich der Sache noch eine Chance. Zum Glück kann man ja Microsoft “hierüber einen Fehlerbericht” senden. Also klicke ich auf den Link, mit der Erwartung, dass Microsoft jetzt über diesen Fehler benachrichtigt wurde. Aber Pustekuchen!
Ich lande in einem MSDN-Forum (mit dem viel-sagendenden Namen “MSDN, TechNet, and Expression Profile and Recognition System Discussions”).
Jetzt reicht’s mir. Wie oft will mich Microsoft denn noch auf eine andere Seite weiterleiten?? Ich wette, ich kann mich auch im MSDN-Forum nicht registrieren (hab ich allerdings nicht probiert). Dann darf ich am Ende einen Bug-Report (Forum) über einen Bug-Report (Microsoft’s Bug-Tracker) über einen Bug-Report (C++ Compiler) schreiben? Nein Danke!
Und dabei wollte ich doch einfach nur programmieren. Danke, Microsoft!
Update (22.6.2011): Das Problem besteht immer noch. Und ich habe inzwischen das Forum ausprobiert; wie erwartet tritt der Fehler hier auch auf, d.h. ich kann nicht mal einen Fehlerbericht im Forum schreiben. Das ist echt ne schwache Leistung, Microsoft!
So, I’m working on my WPF application and everything runs fine, but when I close it, I get this error message (together with this doesn’t-say-me-anything stacktrace):
[System.ComponentModel.Win32Exception] {"Invalid window handle"}
WindowsBase.dll!MS.Win32.HwndWrapper.DestroyWindow(object args) + 0x11a bytes
WindowsBase.dll!MS.Win32.HwndWrapper.Dispose(bool disposing, bool isHwndBeingDestroyed) + 0x8c bytes
WindowsBase.dll!MS.Win32.HwndWrapper.Dispose() + 0x14 bytes
PresentationCore.dll!System.Windows.Interop.HwndSource.Dispose(bool disposing) + 0x1f6 bytes
PresentationCore.dll!System.Windows.Interop.HwndSource.WeakEventDispatcherShutdown.OnShutdownFinished(object sender, System.EventArgs e) + 0x33 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.ShutdownImplInSecurityContext(object state) + 0x49 bytes
mscorlib.dll!System.Threading.ExecutionContext.runTryCode(object userData) + 0x51 bytes
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x6a bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool ignoreSyncCtx) + 0x7e bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x2c bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.ShutdownImpl() + 0x72 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame frame) + 0xe1 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.PushFrame(System.Windows.Threading.DispatcherFrame frame) + 0x49 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.Run() + 0x4c bytes
PresentationFramework.dll!System.Windows.Application.RunDispatcher(object ignore) + 0x17 bytes
PresentationFramework.dll!System.Windows.Application.RunInternal(System.Windows.Window window) + 0x6f bytes
PresentationFramework.dll!System.Windows.Application.Run(System.Windows.Window window) + 0x26 bytes
PresentationFramework.dll!System.Windows.Application.Run() + 0x1b bytes
GuideDock.exe!GuideDock.App.Main() + 0x94 bytes
mscoreei.dll!__CorExeMain@0() + 0x38 bytes
mscoree.dll!748c7f16()
[Frames below may be incorrect and/or missing, no symbols loaded for mscoree.dll]
mscoree.dll!748c4de3()
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes
This problem seemed to appear only randomly until I figured it out today. The problem can be reproduce by this XAML/C# code (together with a WPF window):
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); this.m_touchCanvas.MouseLeave += (s, e) => CrashAppOnClose(); } private void CrashAppOnClose() { Window wnd = Window.GetWindow(this.m_touchCanvas); // This line throws a Win32Exception with "Ivalid window handle". wnd.PointToScreen(new Point()); } } |
Now, when the user closes the window (without using the mouse; eg. with Alt+F4) while the mouse is still in the window, the call to wnd.PointToScreen() (line 11) results in the Win32Exception above. Unfortunately, the doesn’t seem to be any way to check whether this exception will be thrown – I already tried Window.IsLoaded as suggested here with no luck.
What’s more annoying is that the call to PointToScreen() does not appear in the stacktrace. I can’t even imaging how this is possible. That’s why it took me ages to figure this one out.
Btw: I’d like to send a bug report to Microsoft but they haven’t got my account working in three months.
Updates:
Win32Exception can’t be caught in a try ... catch block. Both PointToScreen() and the point where the exception is thrown are on the same thread.I’ve managed to create a bug report for this problem.
Solution/Workaround:
Given the 32-bit error message – which reads “This Visual is not connected to a PresentationSource.” – I found a way to circumvent this problem. You need to use PresentationSource.FromVisual like this:
private void CrashAppOnClose() { Window wnd = Window.GetWindow(this.m_touchCanvas); if (PresentationSource.FromVisual(wnd) != null) { wnd.PointToScreen(new Point()); } }