Externes Feedback 1

haste ausprobiert obs daran lag? weil ich grad nich seh wie das das kaputt machen sollte... keyboardfokus is der trigger und der settet das "IsSelected"... und IsSelected müsste eigentlich die buttons einblenden sobald es aktiv is, das is ja wiederum der andere trigger....

nein leider bin ich grad auf der Arbeit. Dachte nur, dass vielleicht jemand anderes mal ausprobieren will;)

ich weiß nich ob seit heut nachmittag jemand was daran gemacht hat, aber das verhalten ist etwas anders als beschrieben.

1. starte programm
2. füge neue Zeile hinzu
-> Augenscheinlich liegt der fokus jetzt auf der 2. Zeile, die buttons werden dort angezeigt.

Nu wirds interessant in zwei szenarien
Szenario A:
3. Klicke in Zeile 1 in das Textfeld oder die combobox
-> Keine buttons, Fokus scheint auf der 2. Zeile zu bleiben
4. klicke in Zeile 1 irgendwo auf ein nicht-element (graue fläche)
-> Fokus wechselt zurück
5. klicke jetzt in Zeile 2 in das Textfeld/combobox/sonstwas interaktives
-> Wechsel
===> Schlussfolgerung: Der Bug tritt nur kurz nach erstellen der neuen Zeile auf. Offenbar liegt also hier irgendwo der Hase begraben.

Szenario B (angesetzt nach der erstellung der neuen Zeile)
3. Klicke auf ein völlig anderes Fenster (zB der Browser in den du gerade ne Analyse des Problems einträgst)
-> Der Fokus switcht sofort zurück zur ersten Zeile.



These: Ich bin mir technisch noch nicht darüber im klaren, wie die neue Textzeile automatisch ausgewählt wird, aber unsere TextEditorVM wird darüber nicht informiert ("Selected"-Property).
Das hat zurfolge dass im Hintergrund bei der Gebundenen Eigenschaft immernoch Zeile 1 den Fokus hat, was
A: beim klicken auf die Textfelder keine Änderung mit sich zieht, weshalb die UI nicht mit dem Trigger reagiert.
B: Beim verlieren des Fensterfokus die UI updated und Zeile 1 wieder in Fokus setzt.

Bitte einmal alle beteiligten darüber nachdenken, insbesondere einmal eine ausführliche erläuterung über das automatische auswählen der neuen Textzeile.


Edit: Offenbar wird die TextEditorVM doch informiert, aber irgendwie nich richtig, ich forsche weiter...
Edit2: Es funktioniert mit jeder Textzeile, außer der, von der aus man die Zeile erstellt hat.
Edit3:

Code:


                        <Trigger Property="IsKeyboardFocusWithin" Value="True">
                            <Setter Property="IsSelected" Value="True" />
                        </Trigger>

                        <Trigger Property="IsKeyboardFocusWithin" Value="False">
                            <Setter Property="IsSelected" Value="True" />
                        </Trigger>


Das is tatsächlich der übeltäter. Wenn der Keyboardfokus False ist, wird IsSelected auf True gesetzt. Das heißt (freie interpretation):
Wenn Keyboardfokus drin is, wird IsSelected auf true gesetzt, wenn nicht dann auch. Wir haben also scheinbar zwei selected items, und weil Zeile 1 noch den Keyboardfokus hat, ändert sich der wert nicht -> UI wird nicht anständig geupdated.

Edit4:
also wir köööönnten auf die trigger verzichten, ich kann das Selected beim erstellen der Textline im VM manuell setzen, das funktioniert auch.
Allerdings kommen die buttons dann wirklich IMMER nur, wenn man aufs graue klickt, nicht wenn man den Keyboardfokus ins textfeld setzt.

Was hier fehlt ist die möglichkeit manuell den Keyboardfokus von der alten in die Neue Textzeile zu setzen. Leider ist "IsKeyboardFocusWithin" keine setzbare eigenschaft (habs schon ausprobiert), sonst könnte man die einfach an IsSelected binden, bzw abhängig davon machen.

Dh: Wir müssen eine Möglichkeit finden den Keyboardfokus umzusetzen, das machen wir dann an der Stelle.

Wir können übrigens auch folgendes beobachten:
1. starten von tool
2. add answer
3. tabulator mehrfach drücken
-> wir sehen wie die Elemente von Zeile 1 durchgeswitched werden, obwohl das ausgewählte element Zeile 2 sein sollte.

Edit 5:
ein bisschen magie für zwischendurch (experimente im listbox style)

Code:


 <Trigger Property="IsKeyboardFocusWithin" Value="True">
                            <Setter Property="IsSelected" Value="True" />
                        </Trigger>

                        <Trigger Property="IsSelected" Value="True">

                            <Setter TargetName="ItemBorder" Property="BorderBrush" Value="Red"/>
                            <!--<Setter Property="Visibility" Value="Visible"/>-->

                        </Trigger>
                        <Trigger Property="IsSelected" Value="False">
                            <Setter Property="Focusable" Value="False"/>
                           
                           
                            <!--<Setter Property="Visibility" Value="Visible"/>-->

                        </Trigger>


hab ich mal grad ausprobiert. Damit setzen wir nichtselektierte listbox items auf nicht "Focusable", dadurch verlieren sie den fokus und die fähigkeit gefocust zu werden.

Das funktioniert dann wunderbar, bis auf die kleinigkeit: Wir können sie nicht mehr auswählen indem wir auf den grauen bereich klicken, sondern NUR NOCH durch klicken auf textfeld oder combobox....

vielleicht fällt uns etwas ein, wie wir das alles zusammenführen und in den griff kriegen.

so genug edits, der post is schon zu lang...

ich hab jetz in dem trigger fürs mouseover

Code:

                        <Trigger Property="IsMouseOver" Value="True">
<Setter Property="Focusable" Value="True"/>



focusable wieder auf true gesetzt. das heißt: Wo wir mit der maus drübergehen, können wir auch fokusen. Das funktioniert jetzt fast gut, bis auf eine weitere kleinigkeit:

Wenn man auf add answer klickt, und dann sofort mit der maus ein stück hochgeht (um mit der maus in der gleichen textline zu bleiben)
verhält sich das alles so wie vorher (klicken ins textfeld bringt uns kein "IsSelected"

Wenn man die Maus stillhält, gehts aber, weil die textline mindestens für einen kurzen moment nicht-focusable ist (verliert keyboardfokus). Beim erneuten mouseover ists dann wieder focusable...


Ich hab jetz nich mehr so viel ahnung aber ich hab da unten einen Multitrigger gesehen, wo man wohl mehrere Bedingungen verknüpfen kann. Meine grobe Idee (muss noch zuende gedacht werden):

1. Ein item das selektiert ist, ist focusable (wobei das dann glaub ich schon egal is)
2. ein nichtselektiertes item ist nicht focusable
3. ein item mit mouseover ist focusable, wenn es nicht den keyboardfokus hat.
4. ein item mit mouseover ist nicht focusable wenn es den keyboardfokus hat

-> nach 4. würde das item den keyboard focus verlieren, dann würde es nach 3. wieder focusable sein (hoffentlich aber dann ohne den keyboardfokus wiederzuerlangen)


Das könnte funktioniern is aber sehr reingehackt. vielleicht fällt uns noch was eleganteres ein, ich muss jetz aber erstmal schlafen gehn, mir fallen gleich die augen zu

Noch ein einfall den ich gerade hatte...

Rein hypothetisch:
Wenn wir das Anzeigen der Buttons nicht an die Selektion des Listboxitems, sondern an die Mouseover eigenschaft binden können... das würde das Problem zumindest reduzieren. Dann wären die Buttons immer dort zu finden wo die Maus hinwandert (bin grad etwas unsicher ob es für den user verständlich genug wäre). Das einzige problem das bei dem bug auftreten würde wäre, dass die Box keinen roten rahmen kriegt in diesem spezialfall...

Hallo, ich habe heute auch getestet. Die meisten Sachen wurden ja schon erwähnt, aber mir sind auch noch ein paar Dinge aufgefallen (keine Ahnung ob das schon irgendwo erwähnt wurde oder inwieweit da sowieso dran gearbeitet wird):

1. Wenn man einen neuen Charakter erstellt und auf das Namensfeld klickt um diesen zu ändern, wäre es benutzerfreundlicher wenn das "Unnamed Character" entweder markiert wird oder automatisch verschwindet. (ist natürlich eher eine Feinheit und nichts dringendes)
2. Wenn man einen neuen Dialog erstellt und die erste Zeile löscht, gibt es keine Möglichkeit eine neue zu erstellen, man muss also einen ganz neuen Dialog erstellen um die Anfangszeile zu bekommen.
3. Mir ist noch nicht ganz klar wofür der rote Button neben dem "To:" ist, der bekommt wahrscheinlich noch eine Funktion?
4. Man kann zwar mit der Tab-Taste navigieren, kommt damit aber nicht auf "Add Answer" oder "Add Option", d.h. der Autor muss jedes mal die Maus benutzen.

@ Arne:
sorry...leider blicke ich bei dir jetzt nicht mehr durch, was wir konkret umsetzen sollen:P
Also du meinst wahrscheinlich, dass etwas bei den Styles der Listbox verändert werden muss. Ich verstehe auch in etwa das beschriebene Problem. Aber welcher Code muss da jetzt rein?

ich hab leider auch etwas den überblick verloren, gerade weil sich das problem überschnitten hat mit ein paar sachen die wir
hier besprochen hatten.

Kurzfassung ist, wir wollen programmatisch den keyboard fokus bestimmen können, wenn eine textzeile ausgewählt wird (so die grundidee). In wechselwirkung mit deinen Style triggern, die bei änderung des keyboardfokus "IsSelected" auf true setzen, heißt das aber dass nicht mehr automatisch das neue element ausgewählt würde.

1. Das Selektieren des neuen elementes mach ich jetz im TexteditorVM wenn es hinzugefügt wird. (setzen der "Selected" property)
2. da dann beim klicken das selektierte element den keyboardfokus auf das textfeld gesetzt kriegen würde, wäre der keyboardfokus im alten element und der keyboardfocus trigger der listbox setzt isSelected wieder darauf
3. ohne die keyboardfocus trigger in der listbox wird ein element nicht selektiert, wenn direkt in sein textfeld/combobox/etc geklickt wird
4. wenn wir für combobox und textfelder die "focusable" property von dem "IsSelected" des listbox items abhängig machen, funktionierts wieder

a) ich habs ausprobiert indem ich im IsSelected Trigger des datatemplates diese properties manuell per setter gesetzt habe.
b) ich denke es wäre u.U. eleganter, einfach die focusable eigenschaft der textfelder/combobox per binding an die "Selected" eigenschaft des VM zu binden (weniger unübersichtlicher code, wäre aber zu überprüfen ob es 100% so funktioniert)

Erklärung für die funktionsweise beim anklicken:
- Die einzigen fokussierbaren TextLine elemente befinden sich innerhalb der ausgewählten textzeile
- Die Elemente der inaktiven textlines sind nicht fokussierbar.
- beim anklicken eines elementes in einer inaktiven textline geht der fokus NICHT auf das Element über, stattdessen geht der klick sozusagen auf das gesamte Listbox Item, welches dadurch "IsSelected" auf True gesetzt bekommt (die andere zeile wird dadurch "IsSelected" auf False gesetzt).
- das wiederum setzt die Selected Property der VM, was dann nach b) die Elemente innerhalb dieser TextLine fokussierbar macht.
- Der im anderen thread beschriebene trigger würde dann automatisch den fokus auf die Textline setzen.

Schattenseite:
Beobachtbar wäre dann vermutlich, dass - egal wo ich in eine inaktive textline klicke - der cursor im textfeld landet. Ich persönlich fände das nich ganz so schlimm, allerdings kann es sein dass der User - der ja nicht die fokussierbarkeit sieht, sondern nur dass da ein element ist - irritiert ist, warum das textfeld den fokus erhält, obwohl er doch auf die combobox geklickt hat.
Dahingehend war meine idee, die elemente in inaktiven zeilen durch textblocks zu ersetzen, die optisch nicht editierbar aussehen, und somit nicht suggerieren direkt editiert werden zu können. Der user würde sie also anklicken -> die textzeile wird selektiert -> die elemente werden "editierbar" und die textline erhält den fokus -> der user kann editieren was er will, weil alle elemente editierbar sind.

Wie gesagt ist nur meine idee dafür.

Falls wir den fokus NICHT jedes mal auf die textbox legen wollen, wird ein wesentlich komplexerer trigger nötig sein, bei dem wir dann evtl abfangen müssten ob ein anderes element innerhalb dieser textline bereits den keyboard fokus erhalten hat. Wäre denkbar aber die grundfrage ist wann wo was wie genau unter welchen umständen reagieren muss, bevor wir anfangen da noch mehr zu basteln.


Bitte ergänzt, wenn ihr bedenken wegen irgendwas habt was das hier angeht.

an sich halte ich die idee für gut, dass nicht selektierte lines auch nicht weiter editierbar wirken, allerdings habe ich dennoch bedenken wie der arbeitsfluss ist dadurch beeinträchtigt wird, da ich ja dann immer wieder auf die Combobox klicken muss um einen char auszuwählen.

wie wäre es damit, bzw ist es sehr unmständlich es so zu iplementieren:

a) schreibe lin 1 und klicke auf add answer, bzw shortcut --> füge neue line 2 hinzu und fokussiere combobox

b) das selbe für add option

c) unselektierte lines werden so dargestellt wie du oben beschrieben hast, also nicht editierbar --> wenn eine line angeklickt wird, also irgendwo im linegrid, wird die textbox fokussiert...

das müsste doch an sich leicht abzufragen sein (mal ganz naiv behauptet, ohne den code wirklich zu kennen)

also
a) bei add answer die combobox zu fokussieren ok,
b) bei add option macht das keinen sinn, da eine Option ja im normalfall denselben charakter betrifft (is ja auch so implementiert dass der charakter übernommen wird)
c) das nicht editierbar machen is durchaus möglich...

Problem: Wie differenzieren wird beim IsSelected Trigger zwischen den fällen a, b und c?

und: wäre es nicht einfacher, überall immer die textline als hauptfokus zu benutzen, und einfach den charakterwechsel zB durch shortcut einfacher
umzusetzen?

dann könnte ich zB shortcut benutzen für add answer, die textzeile hat den fokus und kann direkt erstmal den text schreiben und danach oder auch davor per shortcut den "nächsten" charakter wählen.

könnte mir zB vorstellen dass folgende Tastenfolge den 2. Charakter mit "Hallo" antworten lassen könnte:

[1. Zeile wird geschrieben.....]
Strg+Enter (neue Zeile wird erstellt)
Strg+Shift+C ("nächster charakter" -> Charakter 1 in Liste ausgewählt)
Strg+Shift+C ("nächster charakter" -> Charakter 2 in Liste ausgewählt)
Hallo (Texteingabe)

Ich kann mir gut vorstellen, dass man sich dann in einem Dialog mit 2-3 personen sehr schnell orientieren kann, wie oft man für welchen Charakter wie oft Strg+Shift+C drücken muss, das könnte super fix gehen. Mit einem umfangreichen Set von Textline-shortcuts könnte man einen ziemlich schnellen ablauf erzielen

Strg+Shift+C ("nächster charakter" -> Charakter 1 in Liste ausgewählt)
Strg+Shift+C ("nächster charakter" -> Charakter 2 in Liste ausgewählt)
Hallo fremder (Texteingabe)
Strg+Enter (neue Zeile wird erstellt)
Strg+Shift+C ("nächster charakter" -> Charakter 1 in Liste ausgewählt)
Ebenfalls hallo, werter Herr (Texteingabe)
Strg+Shift+N (Notizfeld)
Charakter soll verunsichert klingen (Notizanmerkung)
Enter (Option wird hinzugefügt, selber Charakter ist bereits ausgewählt)
Wie war das? (Texteingabe)
Strg+Shift+N (Notizfeld)
Starke verwunderung in der Stimme
Strg+Shift+T (To Feld fokussieren)
1 (Rückkehr zu Zeile 1 festlegen)

... das würde meines erachtens nach sogar noch Zeit sparen gegenüber der "mit tab durchswitch" methode.

b) bei add option macht das keinen sinn, da eine Option ja im normalfall denselben charakter betrifft (is ja auch so implementiert dass der charakter übernommen wird)

--->sry, hatte ich nciht aufm schirm dass es schon so implementiert ist, wäre dannnatürlich auch mein nächster vorschlag gewesen


und: wäre es nicht einfacher, überall immer die textline als hauptfokus zu benutzen, und einfach den charakterwechsel zB durch shortcut einfacher
umzusetzen?
---->nicht als zwang(aber als möglichkeit), falls (ja ist nur theoretisch) mehr als sagen wir 5 chars, dann ist das zu viel klickerei anstatt einmal auf dropdown und einmal auf den gewünschten char, naja umso mehr chars, desto umständlicher, man muss diese möglichkeit ja mit einbeziehen, also als Möglichkeit okay, aber nicht als zwang...

Sonst ne sehr gute idee, das kann dann echt flott gehen mitm arbeiten

vergiss nich dass das immernoch ne option ist. wir deaktivieren ja nich die klickbarkeit. du hast die wahl

neue zeile erstellen
klick auf dropdown
charakter auswählen

neue Zeile erstellen
X mal Strg+Shift+C


bei dem umständlichen Weg mit dem fokus auf der combobox haste nur den vorteil, dass du statt strg+shift+C mit pfeiltaste oben/unten drauf kannst. Dafür musste hinterher noch per tabulator durch die elemente bis du bei der textzeile bist.

nebenbei erwähnt: wie siehts eigentlich aus mit der tastennavigation zwischen den Textlines. Was wäre mit Strg+Pfeiltaste oben/unten? sonst haben wir schwierigkeiten zwischen den Zeilen zu navigieren ohne Maus.

schreib ich mir als mein nächstes to do auf, muss ich mich weiter in den code einlesen, damit ich die jeweiligen funktionen finde... hab den code ja nicht geschrieben, mache ich aber gerne

also mal alle punkte kurz gefasst:
mit viel triggerbasteln könnten wir u.U. hinkriegen dass bei add answer die combobox den fokus kriegt, allerdings glaube ich dass der Aufwand im verhältnis zum gewinn zu groß ist. Wir müssten gucken ob wir der textline dann nen bool geben, der sagt ob die combobox den fokus kriegen soll oder ned (oder vllt direkt n string der dann n kürzel für die elemente kriegt)... den könntn wir bei addanswer setzen, im trigger auslesen und beim ersten deselektieren löschen. Bin mir da aber auch ned sicher ob das das nonplusultra ist. ich bin eher für die andere tastencombosache, das hält die systematik für die fokussachen simpler...

Also noch mal für mich. Soll ich die Trigger für MouseOver und Focus im Style der ListBox zunächst mal löschen? Oder den Code durch etwas ersetzen?

da will ich jetz keine Antwort drauf geben weil ich schon wieder nich ganz in der materie stecke und ich denke, dass sich das konkret morgen entscheiden wird, wenn wir dann auch genau wissen, was sich wann wie verhalten muss....

Vllt kannst du nochmal ne zusammenfassung machen, welche von den triggern genau für welche Funktionalität verantwortlich sind, damit wir nebeneffekte abschätzen können....
(zB glaub ich der IsKeyboardFocusWithin Trigger True sorgt dafür dass du beim klicken ins textfeld das listboxitem auf IsSelected=True stellst damit es rot gerahmt wird.... macht der noch was anderes? was machen die anderen trigger?)

ok, ich bin ja morgen nicht da, daher habe ich einfach mal kommentare in den style eingefügt

Hm, neuerdings überlappen sich texteditor mit der leiste zum horizontalen kleiner/größermachen des char/dia-Bereichs...

schon wieder? hatten wir das nich schonmal?

jep, als der walter vor 2 oder einer wochen sein feedback gegeben hat

hatte ich letztens erst korrigiert gehabt. da muss irgendwo ein Margin mit Minuszahl sein (das wars zumindest das letzte mal)

ich neige manchmal dazu beim auswählen die sachen zu verschieben (wenn ich rumprobiere)... bin mir aber fast sicher dass ich genau deswegen gestern extra nochmal reverted hatte vor meinem checkin...

Mir ist gerade aufgefallen, wenn man mehrere Charaktere hat und bei einem das Kreuz für PC macht oder weg macht, erscheint oder verschwindet es bei allen anderen Charakteren auch.

Wenn man einen Charakter löscht, bleibt der Name trotzdem links oben in der Charakterliste stehen.