Verwendung von Eingabefeldern in Version 4
Liebe Geogebra-Gemeinde,
meine Anfrage richtet sich an erfahrene Nutzer der Version 4. Ich verwende Geogebra3.2 hauptsächlich zu Demonstrationszwecken, aber auch als Lernumgebung für Schüler. Ich bereite also Geogebra-Dateien mit Aufgaben vor, die die Schüler lösen sollen und für die sie von der Datei sofort eine Rückmeldung zur Richtigkeit und ggf. Korrekturhinweise bekommen. Problematisch war bisher die Eingabe der Schülerantworten. Beispielsweise waren für die Frage "welcher Bruch ist das?" bisher meist zwei Schieberegler notwendig, mit denen man je einen Wert für Zähler und Nenner einstellen konnte.
Zusätzlich mussten noch Vorrichtungen getroffen werden, dass die Schüler nicht einfach so lange an den Reglern rumspielten, bis die Antwort "Richtig" auftauchte.
Deshalb setzte ich große Hoffnungen in die bevorstehenden Eingabefelder der Version 4. Jetzt sind sie da - und ich kann nichts damit anfangen.
Es würde mir schon reichen, wenn mir jemand eine Lösung zu folgenden zwei beispielhaften Aufgaben nennen könnte:
Aufgabe 1)
Im Koordinatensystem sind Punkte gegeben, und der Schüler soll in ein Eingabefeld neben einem Punkt dessen Koordinaten angeben. Die Reaktion des Programms bestehe in den Antworttexten "richtig" bzw. "falsch". Wie geht das?
Was ich schon weiß: Ich darf auf keinen Fall das Textfeld mit dem entsprechenden Punkt verbinden. Eine Eingabe wie "(1,5)" bewirkt dann nämlich nur, dass der Punkt seinen Ort verändert und plötzlich bei (1,5) auftaucht.
Aufgabe 2)
Auf dem Zahlenstrahl (z.B. bei x=0,8) liegt ein Punkt, und die Schüler sollen eingeben, dass das der Bruch 4/5 ist. Meine Vorstellung: Zwei Eingabefelder übereinander, ein Strich als Bruchstrich dazwischen, und bei Eingabe von 4 (oben) und 5 (unten) (oder bei 8 und 10...) erscheint ein Text "richtig".
Auch hier: wie geht das?
In diesem Zusammenhang habe ich schon ein weiteres Problem festgestellt. Es ist nicht möglich (?), ein Texteingabefeld an eine bestimmte Koordinatenposition zu bilden (wie es bei anderen Objekten über Eigenschaften ... Position möglich ist). Man kann es zwar fixieren, aber dann kann es nicht flexibel mit "seinem" Objekt mitgehen, wenn gezoomt wird.
Wenn man nicht fixiert und nicht zoomt, kann man die Felder trotzdem von Hand verschieben. (Schüler machen ja häufig, was sie nicht sollen. Der Nenner steht dann irgendwo im Nirvana, aber nicht unter den Zähler.)
Wer kann helfen?
Gruß Abakus
Einfach nur Lösungen ... tss ... wo gibst denn sowas?
Wie du ja mitbekommen hast, will ich das Schreiben eines Tutorials zum Scripting anschubsen. Bis zu den Eingabefeldern dauert es aber noch ein wenig.
Schau dir bitte deshalb mal die Seite mit den ReleaseNotes an: http://www.geogebra.org/en/...
und suche dort nach dem Abschnitt Scripting. Dort findest du ein paar Infos zu Text-Feld.
Es wäre nett, wenn du deine Datei (Link zu GGTube) als Beispiel mit einer Beschreibung, wie es funktioniert, auf der Seite einfügen könntest: http://wiki.geogebra.org/de...
Zum zweiten Beispiel: Die Position ist nicht bestimmbar. Aber Zoomen macht ja nichts. Am besten links oben in die Ecke stecken (bei jeder Auflösung vorhanden) oder in das zweite Grafik-Fenster.
Es gibt ja dann noch die Option "Anklickbar" ... hilft dir die? Eigentlich könnten die Schüler ja auch den Bruch 3/4 angeben, aber dann würde die Eingabe 0.75 vermutlich auch richtig sein. Wenn du den eingegebenen Text mehr auseinander nehmen willst, wirst du auf JavaScript zurückgreifen müssen. Oder eben zwei Eingabefelder nutzen (Zähler und Nenner statt den Strich hinkritzeln).
Grüße, Birgit
Du meinst das?
When you type some text into a textfield and press <Enter>, the text is passed to a script as %0, so you can have commands such as:
text = "%0"
Text[%0,(3,4)]
Ich habe also ein Eingabefeld erzeugt und hineingeschrieben "Ich mag Version 4" (war leider geschwindelt). Dann drückte ich Enter.
Und nun? Wenn ich jetzt unten in der Eingabezeile
Text[%0,(3,4)]
schreibe, bekomme ich eine Fehlermeldung (Ungültige Eingabe).
Oder was ist gemeint mit "so you can have commands ..."?
Hallo abakus,
So 100% sicher bin ich auch noch nicht mit den Eingabefeldern.
Inzwischen habe ich mir folgendes Modell zusammengereimt:
Das Eingabefeld ist insofern mit einem Schieberegler vergleichbar als
- Eine freie Variable am Bildschirm auf eine bestimmte Art und Weise präsentiert wird
- Eine Interaktion am Bildschirm sich auf die freie Variable auswirkt.
Der Unterschied liegt darin dass
- Die freie Variable eines Eingabefeldes unterschiedliche Typen haben kann
(zB Zahl, Punkt, Funktion, Text usw)
- Die Eingabe nicht mit der Maus sondern mit der Tastatur erfolgt
- Die Definition der freien Variablen bereits erfolgt sein muss, bevor man
das Eingabefeld mit dieser freien Variablen verknüpft.
- Eine Eingabe im Eingabefeld der Typenprüfung unterworfen wird
(zB in einer Funktion ist x möglich für eine Zahl aber nicht)
Um die freie Variable zu definieren muss man ihr einen beliebigen Wert zuweisen.
"0" aber auch "?" (undefiniert) oder leerer String sind denkbar. Dieser Initalwert
erscheint dann auch im Eingabefeld.
Nachdem die freie Variable definiert wurde kann das Eingabeld definiert werden.
Bei der Plausibilisierung muss dieser Initialwert jeweils als weiterer möglicher Zustand
(nebst richtig/falsch) mitberücksichtigt werden.
In Deinem Anwendungsfall (Prüfen der Schülereingaben) kann die Reaktion aufgrund
von Texten, die in den Erweiterungen eine Kondition haben, erfolgen (siehe Beispiele).
Eine weitere (nicht unbedingt empfehlenswerte) Möglichkeit besteht darin, dass
die Eingabe mittels eines Scripts im Eingabefeld abgefangen wird und der Script
die Weiteren Aktionen (prozedural) bestimmt. Die Steuerung kann aber unübersichtlich
werden.
Eingabefelder ohne Verbindung zu einer Variablen sind möglich machen aber
nach meinem Verständnis keinen Sinn, da der Inhalt des Eingabefeldes auch nicht per
GG-Script einsehbar ist (%0 ???).
Scripte können einen Sinn machen wenn eine Antwort vorab umgeformt werden soll
- zB Brüche
- zB Text in Funktion
- zB Text in Zahl oder Bruch
In diesen Fällen muss die umgewandelte Antwort durch den Script in einer (zusätzlichen)
freien Variable mit SetzeWert[] abgespeichert werden, sodass dass "normal", zustandsorientierte
GeoGebra damit weiter arbeiten kann (zB für die Antwort)
Der Vorteil von Text als verknüpfte freie Variable zum Eingabefeld besteht darin, dass der
Initialwert durch den Schüler nicht vorab gelöscht werden muss, wenn er eine Antwort eintippen will.
Ein Script wird mit Vorteil der freien Variablen, die vom Eingabefeld referenziert wird zugeordnet
(OnUpdate).
Zum Thema Script und Eingabefeld gibt es einen Tread:
http://www.geogebra.org/forum/viewtopic.php?f=20&t=23946
Deine Fragen sollten mit den Beispielen beantwortet sein.
Bleibt noch die Frage bezüglich der Platzierung der Felder:
Leider kann man Eingabefelder keinem Punkt zuordnen. Eine Alternative zur
Absicherung unbeabsichtigter Verschiebungen kann mit "Nicht Selektierbar"
erreicht werden.
Ich hoffe ich habe nicht weitere Unklarheiten geschaffen.
Raymond
Zu Deinen weitern Fragen:
https://ggbm.at/551617
Das
Text[%0,(3,4)]
musst du im Skript-Bereich des Textfeldes eintragen. Dieses Skript wird dann ausgeführt, wenn du RETURN drückst.
Wegen der Version 4.0 ... nebenbei, ich liebe sie :wink: ... für unsere Rheinland-Pfälzische GeoGebra-Initiative bin ich gerade dabei in unserem Wiki eine Zusammenfassung zu schreiben. Bisher sind es eher Informationen, aber ich denke, es kommen noch Beispiel-Aufgaben dazu, zu denen es konkrete Anleitungen gibt.
Siehe: http://wikis.zum.de/geogebr...
Zum Skripting habe ich den Handbuch-Text http://wiki.geogebra.org/de... etwas modifiziert und werden demnächst mehr auf der Seite http://wiki.geogebra.org/de... schreiben. Ähnlich der englischen Seite http://wiki.geogebra.org/en...
Grüße, Birgit
Hallo Raymond,
herzlichen Dank für die umfangreiche Antwort und die Mühe, die du dir mit deiner Beispieldatei gemacht hast.
Langsam sehe ich klarer.
Viele Grüße
Lutz
Das werde ich gleich ausprobieren.
Herzlichen Dank!
Hallo abakus, Birgit,
Jetzt hat das %0 bei mir auch geklingelt.
Damit ist es möglich Eingabefelder zu definieren deren Typ nicht vorbestimmt ist.
- Definiere ein Objekt: A=0
- Definiere ein nicht verknüpftes Eingabefeld
- erstelle im Eingabefeld einen Script: A=KopiereFreiesObjekt[%0]
nun kann man beliebige Objekte eingeben
zB
true false
(1,1)
"nein"
x^2
Kreis[(0,0),1]
Bleibt noch der Schönheitsfehler, dass das Eingabefeld nicht initialisiert werden kann (?)
Raymond
Was meist du denn mit "initialisieren"?
Bzw. was klappt nicht?
Hallo Birgit,
in seiner Beispieldatei hat er mir u.a. ein Eingabefeld konstruiert, in das der Term einer Funktion eingegeben werden sollte (deren Graph angezeigt war).
In dem Feld stand bereits voreingestellt (=initialisiert?) der Term
x
drin (und dahinter der Text "falsch").
Der Nutzer konnte diese Vorlage "x" ändern in z.B. 3x+5 u.ä., bis "richtig" erschien.
Wenn das Eingabefeld komplett leer gewesen wäre, hätten Nutzer vielleicht etwas länger gerätselt, was sie da eintragen sollen.
Wenn der Datentyp vorher nicht klar ist, ist es auch unmöglich, vorher einen schon voreingestellten "Vorlagewert" einzugeben.
Ich vermute, dass das die Erklärung für das ist, was Rami meint.
Da habe ich aber auch an dich noch eine Frage:
Nimmt man immer "%0", oder kommt auch "%1", "%2" usw. zum Einsatz (z.B. bei der Verwendung mehrerer Felder)?
Übrigens: Es ist doppelt schade, dass man Eingabefeldern keine eigene Koordinatenposition zuweisen kann. Ich konnte mit dem Folge[]-Befehl eine Folge von Eingabefeldern erzeugen. Leider liegen die alle auf einem Fleck übereinander in der linken oberen Ecke...
Gruß Abakus
Man kann eine Beschriftung für das Textfeld eingeben, damit klar ist, was da rein soll.
Hallo abakus, Birgit
Aufgrund der Zeitverschiebung (GMT+8) wurde es bei mir sehr sehr spät, sodass ich
erst "heute" Antworte :(
Als Beilage ein komplexeres Beispiel.
Es gibt eine Lineare Zufalls-Funktion in grafischer Form vor und erwartet die
entsprechende Funktion als Eingabe.
Die Eingabe wird mit einem Text (richtig, falsch) quittiert.
Diese beiden Texte sind auf 2 Knöpfe verteilt, die beim anklicken
das Feld initialisieren (Inhalt löschen) und bei "richtig" eine
neue Aufgabe stellen.
Nicht unerheblich scheint mir, dass die gesamte Steuerung zustandsorientiert bleibt.
Die Scripts verändern nur Feldinhalte, die Logik (Farbe, Anzeigen usw) bleibt bei den
Objekten selbst.
Das Eingabefeld ist mit einem Textfeld verknüpft. Das hat den Vorteil, dass ein leeres
Eingabefeld angezeigt werden kann. Die Umformung des Textes in eine Funktion
geschieht im Script des Eingabefeldes. Dies mit dem Befehl "Ausführen", der den
String als Input hat und ihn dann (in diesem Beispiel in eine Funktion) umwandelt.
Dies wiederum sorgt dafür dass zB die Eingabe +5+x*3 gleich wie 3x+5 behandelt
wird. Alternativ hätte auch der Befehl VerwandleInFunktion[] verwendet werden können.
Ich denke aber dass Ausfüren[] genereller eingesetzt werden kann.
Die Felder sind nicht fixiert und alle Felder sind selektierbar. Dies damit der Code
eingesehen werden kann. In der Schülerversion ist dies geändert.
http://www.geogebratube.org/material/show/id/1534
Raymond
Beilage GG40
PS1:
Nach dem Testen der Beispiel-Datei aus dem ersten Beitrag (EingabeFelder01.ggb) habe ich
vergessen die Felder mit ? zu initialisieren. Dann wären keine richtig/falsch Kommentare erschienen.
Ich habs zwar rasch korrigiert aber doch nicht rasch genug, dass Du abakus die richtige Version erwischt
hättest. Dadurch hast Du teilweise falsche Schlüsse gezogen (logischerweise). Sorry.
PS2:
für den künftigen Erfolg von GeoGebra scheint mir wichtig, dass GG von den Schülern
interaktiv eingesetzt werden kann. Sei es als Zeichen-Werkzeug oder als
Uebungsprogramm oder für das Erkunden von Sachverhalten. Die dazu notwendigen
Funktionen sind in Relase 4.0 meiner Meinung nach etwas zu kurz gekommen. Es
besteht das Risiko, dass mit den neuen Funktionen eher der Spieltrieb der Lehrer
befriedigt wird (was auch sein muss), die dann ihren Schülern tolle Animationen vorführen.
Dabei bleibt der Schüler aber eher passiv. Ich hoffe, dass nach der Bug-Bereinigung diesem
Thema mehr Gewicht beigemessen wird.
https://ggbm.at/551631
Hallo Raymond ...
dein Arbeitsblatt sieht wirklich gut aus. Werde es mir mal genauer anschauen ...
Wenn dir noch Funktionen fehlen, dann frage doch nach. Ich persönlich bin schon ziemlich zufrieden mit GeoGebra 4.0. Nenn doch mal ein paar Beispiele, wie du GeoGebra gerne einsetzen möchstest. Mehr Köpfe finden vielleicht eher eine Lösung ;-)
So ... die Schule ruft dann doch mal ...
Grüße, Birgit
Hallo Birgit,
Zunächst einmal scheint es mir wichtiger, dass 4.0 wirklich stabil läuft. Wenn dann die Entwickler frei sind könnten sie sich zB. um folgende neuen Features kümmern:
Die Folgenden Befehle sollen die Maus als Interaktions-Instrument ermöglichen.
- script: KlickObjekt[<Objekt>] fordert den Benutzer auf ein Objekt anzuklicken, das Resultat steht in Objekt. sofern auf den Hintergrund geklickt wurde werden die Koordinaten zurück gegeben ansonsten den Objektnamen als String.
- script: GewählteObjekte[<Liste>] (ist das Pendant zu WähleObjekt[]). Es wird eine Liste aller gewählten ObjekteNamen (als String) zurückgeliefert.
Die folgenden Befehle werden gebraucht, wenn man die Konstruktion oder Teilkonstruktion
des Schülers begleiten will. Beispiel:
Konstruiere auf der Vorlage den Ort aller Punkte die von A und B dieselbe Entfernung haben.
- Konstruktionsschritt[<n>] liefert eine liste aller Atribute eines Konstruktionsschrittes. Als wichtigstes den Namen als String. Bei "Container-Objekten" (Beispiel Polygon) werden die Teil-Objekte als Subliste ebenfalls geliefert.
- VerrgebeneNamen[<Objekttyp>] liefert eine Liste der Namen (als String) aller Objekte mit dem vorgegebenen Objekttyp. Ohne Objekttyp: alle Namen.
- ObjektTyp[<Objekt>] liefert den Typ eines bestimmten Objektes
- NamensVergabe[<Liste>] eine Liste, die GG anweist für die kommenden Konstruktionsschritte nur
die Namen aus der Liste zu vergeben. Sind die Namen aufgebraucht, so wird ein spezieller Script gestartet. Die Liste hat den Aufbau {{Name,Typ,indexVon, IndexBis}.......}. Ist der Befehl aktiv so verhindert GG dass Objekte eines nicht aufgeführten Typs erzeugt werden. Der Index-Range erzeugt
Objketnamen in der Form Name_index. Der Range gibt an wieviel solcher Objekte erzeugt werden können. NamensVergabe[] hebt die NamensVergabe (vorzeitig) auf.
Die Namensvergabe könnte als ein spezieller Knopf realisiert werden der auch den Container für den
"speziellen Script" der nach dem Aufbrauchen des NamensRaumes gestartet werden soll, enthält.
Soweit einige Beispiele. Sie sind nicht gründlich durchdacht. Im Wesentlichen geht es darum, dass
auch die Maus als interaktives Eingabe-Instrument verwendet werden kann und dass Konstruktionsschritte interaktiv begleitet, kommentiert und kontrolliert werden könnten.
Ein weiteres grosses Thema (weniger im Zusammenhang mit Interaktion) sind die Makros.
Diese waren seit Anbeginn bezüglich Atributen und Objekttypen sehr einschränkend bis Fehlerhaft.
Die neuen Möglichkeiten der Scripts können sowieso nicht genutzt werden.
Eventuell wäre es möglich die Macros auf lange Frist sterben zu lassen und sie durch spezielle "Werkzeugscripts" zu ersetzen. Dazu wäre ein Set weiterer Script-Befehle notwendig zB SetzeOnUpdate[]
Ramond
Hallo,
Zurück zum eigentlichen Thema: Eingabefelder.
Hier eine weitere Version eines interaktiven Arbeit-Blattes.
Es geht um das Trainieren von einfachen Gleichungen mit einer Unbekannten.
Das besondere daran sind die Gleichungs-Pattern. Diese erlauben, abhängig
vom Trainingserfolg, den Schwierigkeitsgrad zu erhöhen.
Als Schülerversion ist das AB hier eingestellt:
http://www.geogebratube.org/material/show/id/1698
Im Anhang findet sich die "Entwickler-Version", in der alle Teile
eingesehen werden können.
Raymond
Nachtrag 1:
Sobald man die Einträge in der Tabelle ändert funktioniert das Programm nicht mehr.
Die Bezüge zu den Zellen sind falsch, obwohl die entsprechenden Befehle nach wie vor
richtig sind.
Ich vermute (einen bösen) GG-Fehler und gehe der Sache auf den Grund.
Bug Report plaziert: http://www.geogebra.org/forum/viewtopic.php?f=8&t=24539
Nachtrag 2:
Ich habe eine Umgehungslösung gefunden. Wenn die Tabellenfelder vorab in eine Liste
übertragen werden, dann funktioniert das Ganze. Die neue Version hat nun keine
Restriktionen.
Beilage GG40
https://ggbm.at/551717
Comments have been locked on this page!