[WPF] ProgressBar + GridSplitter, ProgressBar wird grösser aber nicht mehr kleiner
-
@CSL,
Probier den Code bitte zuerst mal aus.Ich mach dir mal eine Bilderreihe. Wir starten:
http://www.dracopien.ch/temp/wpf/state01.pngSchieben den Splitter nach rechts, alles wunderbar:
http://www.dracopien.ch/temp/wpf/state02.pngNun schieben wir den Splitter wieder zurück. Immer noch alles wunderbar!
http://www.dracopien.ch/temp/wpf/state03.pngUnd dann auf einmal, wir die ProgressBar abgeschnitten! Es erscheint noch kein Scrollbalken!
http://www.dracopien.ch/temp/wpf/state04.pngUnd erst wenn wir dann weiter nach links gehen, erscheint endlich der Scrollbalken:
http://www.dracopien.ch/temp/wpf/state05.pngDu willst mir doch nicht sagen, dass du dieses Verhalten als intuitiv ansiehst?
Grüssli
-
Okay, grad ma geschaut.
Die ScrollBar wird angezeigt sobald der bereich in auf dem Value stößt. Das ist tatsächlich ein Bug, siehe http://social.msdn.microsoft.com/forums/en-US/wpf/thread/2fc8c523-21f4-48d6-a06b-12fd76ff5791/
Scheinbar wir der Platzbedarf falsch berechnet.
Das Problem kannst du (Leider nur Teilweise wegen der falschen Berechnung) mit
<ListBox HorizontalContentAlignment="Stretch" ScrollViewer.HorizontalScrollBarVisibility="Disabled">
beheben.Ändert aber nichts an meiner vorherigen aussage, das die ScrollBar kommt ist ja normal, der Bug der hier vorliegt ist das diese zu spät kommt, die müsste sofort beim verkleinern erscheinen, nicht erst beim erreichen des Value Punktes.
-
Genau so sieht meine Erfahrung mit WPF aus
Kleinste einfache Dinge und dann geht es nicht, weil WPF nicht geht :pZum Rest kann ich nur sagen: Empfinde ich nicht als intuitiv. Klar ist es logisch mit den gegebenen Standardwerten, aber diese sind definitiv nicht intuitiv. Deshalb muss man zuerst eine Menge an Erfahrung sammeln, bis man alle diese nicht intuitiven Standardwerte kennt und darauf reagieren kann. Sowas hast du eben in WinForms deutlich weniger. WinForms verhält sich deutlich öfter so, wie man es auf anhieb vermuten würde.
Aber naja, dazu können wir im anderen Thread weiterdiskutieren und hat sicher auch eine subjektive Komponente dabei
Grüssli
-
Es "geht" nicht weil ein Bug in der Komponente vor liegt, und das kann man nie ausschließen, auch in Forms nicht. Als Forms noch neuer war, lagen solche Fehler bestimmt auch vor
Es ist wie gesagt nicht unintuitiv sondern einfach nur ein Bug.
-
CSL schrieb:
Es "geht" nicht weil ein Bug in der Komponente vor liegt, und das kann man nie ausschließen, auch in Forms nicht. Als Forms noch neuer war, lagen solche Fehler bestimmt auch vor
Es ist wie gesagt nicht unintuitiv sondern einfach nur ein Bug.Nein, kein Bug, das ist BLÖDSINN!!
-
CSL schrieb:
Es "geht" nicht weil ein Bug in der Komponente vor liegt, und das kann man nie ausschließen, auch in Forms nicht. Als Forms noch neuer war, lagen solche Fehler bestimmt auch vor
Es ist wie gesagt nicht unintuitiv sondern einfach nur ein Bug.Schon klar, ich hätte wohl noch ein Smilie hinmachen sollen
Grüssli
-
Aber ein UI-Lib mit Layout-Manager und Resize-Bugs, ist das seriös?
-
Es ist kein Resize Bug, es ist ein Arrange/Measurement Bug in der ProgressBar Komponente.
In dem Augenblick wenn der DockPanel seine Childs nach die Größe fragt, child.DesiredSize, gibt die ProgressBar scheinbar einen falschen wert, nicht die Eigene Width sondern die Width bis wo Value gezeichnet wird.
-
CSL schrieb:
Es ist kein Resize Bug, es ist ein Arrange/Measurement Bug in der ProgressBar Komponente.
In dem Augenblick wenn der DockPanel seine Childs nach die Größe fragt, child.DesiredSize, gibt die ProgressBar scheinbar einen falschen wert, nicht die Eigene Width sondern die Width bis wo Value gezeichnet wird.Du laberst hochgradigen Dünnschiss!!
-
Dann klär mich auf.
-
CSL schrieb:
Dann klär mich auf.
sinnlos!
