Aktualisieren der Werte in Eingabefeldern

Der eingetippte Wert ist einfach noch nicht übernommen worden. Man muss die Eingabe mit Return abschließen oder woanders hinklicken.

Man sieht es recht deutlich ... der Wert im Algebra-Fenster ist unverändert!

Eventuell müsste man versuchen, den Knopf zu verstecken, bis sich der Wert verändert hat. Das funktioniert dann wieder nicht, wenn man den gleichen Wert noch mal addieren will.

Also wat tun?

Birgit

Hallo

Meiner Meinung nach ist das ein dicker, fetter BUG, der so rasch als möglich behoben werden sollte.

Sobald der Kursor das Eingabe-Feld verlässt, muss zwingend und als Erstes das Uebertragen des

Wertes geschehen UND der Script ablaufen (natürlich auch nach Enter).

Eine saubere Umgehungslösung, die in jedem Fall funktioniert (zB auch dann, wenn mehrere Buttons zur Verfügung

stehen), habe ich nicht gefunden.

Anstelle des Buttons könnte man ein Textfeld verwenden, das beim Anklicken die Aktion ausführt.

Allerdings reagiert es nach einer Aenderung im Eingabe-Feld erst beim zweiten Anklicken, was ein

weiterer Bug ist, da ansonsten der Benutzer bezüglich der Anzahl, die geklickt werden muss,

verwirrt wird.

Raymond

Hallo

Nicht nur ich, auch andere erhalten zu selten einen Feedback

der Entwickler im Bug-Forum, aber ich nehme mal an, dass diese

Beiträge, wenn auch möglicherweise nicht geschätzt, doch mindestens

zur Kenntnis genommen werden.

http://www.geogebra.org/for...

Raymond

Hmm ... tja ...

da kommt mir das alte Problem "Bug oder Feature" in den Sinn. Wenn die Entwickler der Meinung sind, dass es so gehört, werden sie es nicht als Fehler ansehen. Eventuell muss da ein wenig ausholen und argumentieren und/oder direkt den Entwickler anschreiben, der das entwickelt hat ... wobei ich bei den Knöpfen nicht so sicher bin, wer das gemacht hat.

Und dann gibt es natürlich noch die "Fehler" die man nicht gelöst bekommt, weil es programmiertechnisch nicht so einfach klappt :wink: . Auch hier heißt es, etwas Durchhaltevermögen zu beweisen.

Auch ich habe da so ein Bug ... ich würde ihn so bezeichnen ... der bei mir immer wieder auftaucht. Allerdings spielt er nur bei der Eingabe eine Rolle und lässt sich korrigieren. Trotzt wiederholter Nachfrage noch nicht gelöst :cry: .

Da müsste man programmieren können ...

Na ja...

Da bin ich weit weniger konziliant (als ehemaliger Entwickler und federführend in Grossprojekten).

Und zwar nicht weil ich GGB schlecht finde, im Gegenteil.

Und gerade weil ich GGB als eines der mehr besseren Programme beurteile, fände ich es schade, wenn vor lauter gut gemeinten Features und Featurechens das Wichtigste vergessen würde:

Fehlefreiheit und Stabilität.

Wenn die stimmen würde, dann könnte man sogar darüber hinwegsehen, dass so unmathematische und programmtechnisch uninteressante Dinge wie die Schriftgrösse, die höchstens für die "simplen" Benutzer, die sich nicht mit LaTex herumschlagen wollen, von Interesse ist, weit weit hinten in der Prioritätenliste steht.

Ich hätte noch 100 weitere Ideeen, was man auch noch realisieren könnte und welche Sprachelemente, wie und besser gestaltet würden. Das ist alles irrelevant so lange das Programm nicht stabil und fehlerfrei läuft. Und es gibt sehr sehr viel zu tun, wenn man sich die Open-Item-Liste anschaut, die noch nicht einmal vollständig ist, weil die Rückmeldungen der Benutzer grobfahrlässig unprofessionell, ja geradezu lieblos gehandhabt werden, sodass die Motivation einen Fehler zu überprüfen und nachvollziehbar zu dokumentieren, nach Umgehungslösungen zu suchen und schlussendlich noch (mehr oder weniger gut) ins Englische zu übersetzen (alles zusammen: Stunden nicht Minuten!) so ziemlich auf 0 sinkt.

Und ich meine Fehler und nicht mögliche Fehler und schon gar nicht Features. Die Diskussion um Fehler oder Feature ist sowieso sinnlos und wird von den Entwicklern (aber auch den Benutzern) oft dazu missbraucht um die Prioritäten-Diskussion nicht ernsthaft betreiben zu müssen. Gefragt wären hier eindeutige, nachvollziehbare Kriterien wie: Inhalt zerstört, Weiterarbeit verunmöglicht, inkonsistent zu andern Sachverhalten, Benutzung (eines Features) beeinträchtigt ein anderes, essentiell für alle Anwender (zB Schriftgrösse) da .... (Begründung: zB wichtig für die Attraktivität eines Arbeitsblattes) und und und.....

Es bringt nichts, wenn man Fehler schön redetet. Sie kommen garantiert wieder und vergraulen eine Klientel, die das Tool primär als Arbeitswerkzeug benutzen, tag täglich in der Schule und vor den Schülern. Und die durchaus auf den Gedanken kommen können mit einem stabilerem Tool, das zwar nicht so vielseitig ist, vielleicht glücklicher zu werden (selbst wenn es, gemessen an MS-Betriebssystem und der Hardware, eine Kleinigkeit kostet).

Ja es gibt Fehler, die kann man ohne grundlegende Aenderung an der Architektur nicht beheben. Vielleicht gibt es Umgehungslöungen oder es können solche bereit gestellt werden. Aber mindestens sollten diese systemimmanenten Fehler nach Aussen dokumentiert sein. Uebrigens, dieser Fehler (hier in diesem Tread) tritt im Zusammenhang mit Text-Feldern, die man als Button verwendet, in einer sehr stark gemilderten Form auf, also wird es sich vermutlich kaum um einen System-Design-Fehler handeln.

Und dieser hier dokumentierte Fehler ist genau einer jener, der den (auch von Dir bemängelten) mageren Sprachschatz bezüglich Interaktivität noch zusätzlich einschränkt. Also kein Feature sondern ein Fehler mit hoher Priorität. Punkt.

Im Uebrigen bin ich der Meinung, dass nicht die Anwender die Entwickler bei Laune halten müssen, das wären sowieso ungeeignete Entwickler.

Nichts für ungut

Raymond