Himmel hilf! Gestern Nachmittag wollte ich das ValueChanged()-Event eines DateTimePickers debuggen. Zwar sprang der Debugger am Breakpoint an, aber dann hängte sich Visual Studio auf. Und nicht nur das: auch sämtliche anderen Programme (Outlook, Lync, Explorer, die Windows-Taskleiste usw.) verweigerten die Mitarbeit und zwar genau so lange, bis ich VS hart abgeschossen hatte. Was ich jeweils 2x machen musste, weil auch das Fenster hier rechts eingefroren war.

Ich machte mich also auf die Suche und probierte diverse mehr oder weniger esoterische Lösungsvorschläge aus.

Stunden später.

Das Problem ist tatsächlich ein Problem des DateTimePickers:

Von Microsoft am
16.06.2015 um 16:39 bereitgestellt
Hi,

Thank you for your report. This is a very interesting bug. The DateTimePicker control installs a mouse hook as part of its functionality, but when the debugger has the WinForms application stopped on a breakpoint, it allows the possibility of a deadlock if VS happens to get a mouse message. For now, the deadlock is unfortunately a consequence of the DateTimePicker's design. The mouse hook is installed when the drop down is clicked to display the calendar. This means that breakpoints should not be sent in any event handlers which would be called while the calendar is active. We are currently investigating whether it is possible to address this issue and we will update this thread with further information if we are able to make a fix available.

Natürlich kam da nie eine Antwort geschweige denn ein Fix dazu. Wer debuggt schon ein ValueChanged-Event eines DateTimePickers? Nur daMax. Grmbl.

Zum Glück hat ein anderer gestresster findiger Coder einen Workaround gefunden:

Dies tritt nur auf, wenn als Zielplattform des Projekts „AnyCpu“ oder „64 Bit“ angegeben wurde. Sobald „32 Bit“ verwendet wurde kann der Debugger wie gewohnt verwendet werden.

In unserem Fall bedeutet das, dass wir für Debug-Session den 32-Bit-Modus verwenden, das Projekt aber nach wie vor mit AnyCpu bzw. 64-Bit ausliefern. Zufriedenstellend ist es nicht, aber es gibt keine andere Lösung.

A day wasted.

PS: warum ich das überhaupt Debuggen wollte, fragt ihr? Nun.

Ein DTP kann normalerweise nicht "leer" sein, hat also immer einen Wert. Nun haben wir hier aber den Fall, dass der DTP erstmal "leer" sein soll, so dass der Anwender gezwungen wird, aktiv einen Wert zu wählen. Das geht, indem man dem DTP ein einzelnes Space als CustomFormat verpasst:

If param.Value Is Nothing Then
dtp.CustomFormat = " "
Else
'something
End If

nun muss im ValueChanged-Event aber der "richtige" CustomFormat-String gesetzt werden, sonst bleibt der DTP immer leer:

Sub OnDTPValueChanged(sender As Object, e As EventArgs)
Dim dtp as DateTimePicker = DirectCast(sender, DateTimePicker)
dtp.CustomFormat = "yyyyMMdd"
End Sub


Naja, und da ich auch noch je nach Art des per DataBinding an den DTP gebundenen Objekts einen anderen CustomFormat-String einstellen wollte, wollte ich eben mal einen Breakpoint in diesem EventHandler haben um zu gucken, was ich da so machen könnte.

.net | visual studio | crash | freezes | hangs | hängt

| Abgelegt unter 1337, Coding, Windowswahnsinn
The views expressed by the author are personal.