Mehrere Slider: Summe der Werte soll gleich bleiben

Hallo,
mein Problem ist eigentlich ganz einfach, ich habe im Prinzip einfach nur 5 Slider, die Werte zwischen 0 und 20 annehmen können. Im Hintergrund sind die verschiedenen Sliderwerte an die Werte eines Dictionaries gebindet beispielsweise Slider A ist gebunden an meinTollesDictionary[A].
Jetzt möchte ich, dass die Summe aller Werte immer gleich 20 ist. Ich wurschtle mich von einer Lösung zur nächsten, aber so richtig zufriedenstellend ist keine. Und dabei ist das ja bestimmt kein außergewöhnliches Problem. Aber mit googeln bin ich bisher auch nicht weitergekommen.

Um das ganze erstmal zum laufen zu bringen, hab ich den letzten Slider disabled und den Wert davon quasi als Ausgleich verwendet, immer wenn man an einem anderen Slider war rumstellt, gleicht der letzte das aus. Das hat mir fürs Erste gereicht, aber das Problem liegt natürlich auf der Hand, das klappt für kleine Veränderungen, aber nicht für Extremwerte, wenn mein AusgleichsSlider schon auf 20 ist kann er nach oben nix mehr ausgleichen.
Jetzt hab ich angefangen für diese Fälle das Dictionary nach und nach zu durchlaufen und die anderen werte auch als Ausgleichswerte zu verwenden. Die Lösung funktioniert, ist aber eine riesige Sauerei, weil alles voller Ausgeleichsrechnungen und Ausnahmen. Ich glaube ich hab mich total verrannt.

Hat jemand sowas schonmal gemacht oder sonst irgend einen Ansatz, wie man das sauber umsetzten könnte? Bringt wpf sowas womöglich schon mit? So wie eine Gruppe RadioButtons ja auch voneinander abhängt könnte es sowas ja auch für slider geben. Wenn nicht, würde es vielleicht Sinn machen von dieser Seite ranzugehen und mir ein eigenes SliderGroupElement zu bauen?

Bei RadioButtons ist klar was passieren soll. Der gedrückte ist gedrückt, alle anderen nicht.
Wie soll in deinem Fall ausgeglichen werden? Man kann schon irgendwie rumrechnen, nur ob das dann auch den Sinn des Benutzers trifft?

Wenn du wirklich bei einem automatischen Ausgleich bleiben willst, so schlimm scheint mir der nicht zu sein. Geh alle Slieder durch die gerade nicht bewegt wurden und setze die der Reihe nach höher oder tiefer. Fang beim ersten an und setze ihn auf den maximal/minimal möglichen Wert. Wenns noch nicht reicht, nimm den nächsten.

Ich kenne den Hintergrund der Anwendung nicht, aber ich würde überlegen ob ich überhaupt Gedanken in eine Automatik stecke - oder es gleich ganz lasse.
Lass lieber den Benutzer zunächst irgendetwas einstellen, zeig ihm die Summe an und lasse ihn erst dann weitermachen wenn er selbst die Summe auf 20 korrigiert.
Stell dir vor du willst einen Slider ändern, weißt welchen anderen du dazu ebenfalls ändern musst, und dann kommt dein Programm in die Quere und verstellt den falschen. Das ko*** dich dann nur an.

hübsche Knobelaufgabe.
Eine denkbare Lösung wäre, dass bei jeder Änderung die Summe berechnet wird, und falls drüber wird der höchste Slider ausser des aktuellen gesucht und erniedrigt.
Falls das nicht ausreicht, nochmal: den (dann) höchsten suchen und erniedrigen usw..

Was die Sache unbedienbar macht, es soll ja nicht höchstens 20 herauskommen, da könnte man dann bei jedem Slider bei 0 anfangen und es müsste nichts korrigiert werden, sondern genau 20. Daher wird sich bei jeder Änderung ein anderer Slider (oder mehrere) bewegen. Das macht es unmöglich für den Bediener, eine bestimmte Kombination einzustellen ohne genau zu wissen was er zuerst und was er zuletzt einstellen muss.

Daher mein Tip, man kann die Logik zwar spaßeshalber überlegen, sollte sie dann aber nicht umsetzen. Das ist zum Beispiel wie bei numerischen Eingabefeldern die nur eine Zahl akzeptieren und alles andere ignorieren. Ich möchte nicht wissen wie viele Hotlines schon beschäftigt waren herauszufinden dass Capslock aktiv ist 😃

Mist, an dem Einwand ist leider was dran. Und wenn ich so überlege kann ich mich tatsächlich auch erinnern, dass mich das schon bei anderen Anwendungen aufgeregt hat, dass ich einen slider so einstelle wie ich ihn haben will und wenn ich beim nächsten weitermache, wird an meinem ersten (schon richtig eingestellten) Wert wieder rumkorrigiert. Da ich hauptsächlich mein eigener User bin, habe ich ein verstärktes Interesse daran, dass meine GUI den User nicht nervt. Schade eigentlich, es war so ein schönes Problem 😃 Für micht hat sich das Problem damit erledigt.

Es könnte aber für geringfügig andere Problemstellungen weiterhin interessant sein. Wenn ich jetzt keine int-Werte im Slider hätte, sondern double. Erstens kann ich es dem User dann nicht mehr zumuten, das bis auf die zwölfte Nachkommastelle selber auszugleichen. Zweitens wären dann wahrscheinlich die selbstkorrigierenden Slider nicht so schlimm, weil der User sowieso nicht exakt 2,37295034 da stehen haben will und nichts anderes. Aber, WANN würde ich diese Korrektur durchführen? Bei jeder noch so kleinen Kommastelle? Bekomme ich das überhaupt mit? Wann sagt mir die Oberfläche denn Bescheid, so oft sie es schafft oder gibt es da einen Genauigkeit, beispielsweise bei jedem Tausendstel Veränderung wird Bescheid gesagt?

Zweitens wären dann wahrscheinlich die selbstkorrigierenden Slider nicht so schlimm, weil der User sowieso nicht exakt 2,37295034 da stehen haben will und nichts anderes. Aber, WANN würde ich diese Korrektur durchführen? Bei jeder noch so kleinen Kommastelle? Bekomme ich das überhaupt mit? Wann sagt mir die Oberfläche denn Bescheid, so oft sie es schafft oder gibt es da einen Genauigkeit, beispielsweise bei jedem Tausendstel Veränderung wird Bescheid gesagt?

Da ist es vielleicht besser noch eine Textbox neben den Slider zu Packen in der der User eine Zahl eingeben kann. Zusätzlich könntest du dann noch einen Button daneben setzten. Der dann den dazugehörigen Slider anpasst. Da kann sich der User das Kopfrechnen Sparen.

Ich verstehe die Grundlogik irgendwie nicht.

• 5 Slider können die Werte 0-20 annehmen
• Die Summe aller Slider-Werte soll immer 20 ergeben

wenn mein AusgleichsSlider schon auf 20 ist kann er nach oben nix mehr ausgleichen.

Äh, dann müssten doch alle anderen Slider auf 0 stehen und nach oben gibt es nix auszugleichen.

Oder eben das mit dem MVVM besser verstehen und nicht an irgendwelche Model Daten binden sondern eben an ein entsprechendes Property des ViewModels.

Das kann dann gerundet, gefräst oder sonst wie bearbeitet werden, und natürlich die Werte im Dictionary setzen.

Ich hätte eine andere Idee mit nur einem Slider aber mehreren Werten.

Der komplette Slider erlaubt dann einen Bereich von 0 bis 20.
In diesem Slider gibt es mehrere Knöpfe pro Einzel-Wert zum verschieben.
Jeder Einzelwert ist dann der Abstand zum vorherigen Knopf oder 0.
Jeder der Knöpfe kann nur bis zum vorherigen bzw. nächsten Knopf verschoben werden.
Zusätzlich kann man ja noch einbauen, dass ein Knopf den Nächsten wegschieben kann.

Auf diese Weise passt sich das System selber ohne irgendeine Logik an bzw. der User sieht direkt, was sich wie anpasst und er versteht auch den Grund, weshalb es sich anpasst.

Der letzte Wert bekommt dann keinen eigenen Knopf zum Verstellen, da der immer auf Position 20 stehen müsste.

Beispiel:
Wert1: 5 | Position1: 5
Wert2: 7 | Position2: 12
Wert3: 3 | Position3: 15
Wert4: 2 | Position4: 17
Wert5: 3

Wird nun der zweite Knopf (Position 12) um 5 nach links verschoben, wird Wert2 auf 2 verringert und Wert 3 auf 8 erhöht.

Zusätzlich können darunter auch noch Textboxen pro Wert, wo man den Wert manuell eintragen kann.
Pro Textbox ist der Maximalwert immer der aktuelle Wert plus der folgende Wert.

Ich hoffe, ich hab's halbwegs verständlich beschrieben 😄

@Sir Rufo: du hast Recht, so rum ist es Unsinn. Wenn der Ausgleichsslider auf 0 ist, kann er nach unten nix mehr ausgleichen. Ich hab das ohne nachzudenken auch für den oberen Grenzwert behauptet.

@Palladin007:
Die Lösung gefällt mir echt gut. Ich werde das mal ausprobieren. Ist aber vermutlich schon eine Herrausforderung dem User das Prinzip optisch ganz klar zu vermitteln.

@FZelle:
Ich bin zwar kein Experte für MVVM, aber ganz so blöd, dass ich direkt an irgendwelche Daten binde, bin ich auch wieder nicht 😃. Ich wollte das Problem hier nur vereinfacht darstellen, da fand ich es nicht so wichtig, wo genau das alles passiert. Aber wenn es dich beruhigt: Das alles passiert schon im entsprechenden ViewModel und über Properties, die auf das Dictionary zugreifen. Das Dictionary hab ich nur deswegen auch im ViewModel, weil ich die Daten dauernd durchlaufen muss (und weil ich während so einer Rumprobier-Phase eben manchmal etwas Unordnung im Code hab). Allerdings hab ich ehrlich gesagt auch schon drüber nachgedacht, dass die Beschränkung auf 20 (in meinem Fall wenigstens) eigentlich eine Einschränkung der Logik ist. Und dann gehört es ja eigentlich in die Logik und nicht ins ViewModel. Andererseits der Ausgleich fällt dann doch wieder in den AufgabenBereich der GUI. Das sind aber alles Gedanken, mit denen ich klar komme und mit denen ich dich nicht belästigen würde, wenn du mir nicht unterstellt hättest, ich würde sie mir nicht machen.

Dann lies dir deine Erklärungen nochmal durch, und frage dich dann wieso ich auf so etwas komme.