[ Home ] [ zurück ] [ Seitenende ]

 

 

 

micro:bit-Programmieren, Teil 2

 

Antworten auf die gestellten Fragen

 

Bekanntlich gibt es ja keine dumme Fragen, sondern nur dumme Antworten. Denn wer fragt, macht sich ja konkret Gedanken zu und über einen bestimmten Sachverhalt, hinterfragt diesen kritisch. Wer also nicht fragt, hat schon verloren, weil er sich nicht wirklich für bestimmte Dinge des Lebens interessiert. -

 

Frage 1

 

Starten Sie zu diesem Zweck das Programm microbit_teil_02_prog_32.hex mit dem Quellkode microbit_teil_02_prog_32.js, und finden Sie heraus, ob, wann und wie die Deklaration

 

new starteKlasse_1("2.) Klasse 1 aufgerufen!")

 

im Hauptprogramm von diesem beim Starten des Programms aufgerufen und ausgeführt wird!

 

Klären Sie diesbezüglich auch weshalb der Textstring „2. Klasse 1 - gestartet!“ beim Aufruf der Deklaration

 

new starteKlasse_1("2.) Klasse 1 aufgerufen!")

 

zwar mit übergeben und bei der Anzeige im Konstrukt

 

„constructor(lies_parameter_ein: string)“

 

auch angezeigt wird, wider Erwarten aber nicht in der Klassenvariablen showStringVar abgespeichert wird:

 

basic.showString("Ende Quelltext!" + objektvar_starteKlasse_1.showStringVar, 100)

 

Antwort zu Frage 1

 

Da wir noch nicht so viel Erfahrung mit der „JavaScript“-Programmierung und der Programmierung von Funktionen, Methoden und Klassen haben, muss sich das bisher erlernte Wissen erst noch verfestigen. Hilfreich ist dabei, wenn wir uns immer wieder klar darüber werden, was, wie und warum funktioniert oder eben nicht funktioniert.

 

Wir wissen, dass sich in einer innerhalb des Programmblocks einer Klasse (siehe Bild „microbit_teil_02_bild_25.jpg“) direkt keine Statements programmieren lassen! Statements in Form von Quelltext lassen sich innerhalb der Klasse „starteKlasse_1“ nur im Konstrukt „constructor(lies_parameter_ein: string)“ programmieren!

 

Wir wissen ferner, dass eine Klasse immer nur dann beim Programmstart des Hauptprogramms oder beim Aufruf von anderer Stelle aus immer nur dann ausgeführt wird, wenn man diese mittels einer Objektvariablen und dem neuen Verweis auf die Klasse z.B. wie folgt aufruft:

 

var objektvar_starteKlasse_1 = new starteKlasse_1("1.) Klasse 1 aufgerufen!")

 

Dabei wird nicht nur die Klasse „new starteKlasse_1("1.) Klasse 1 aufgerufen!") eingerichtet, d.h. deklariert, sondern durch die Zuweisung/Bindung an die Objektvariable „objektvar_starteKlasse_1 auch initialisiert (siehe Bild „microbit_teil_02_bild_26.jpg“)!

 

Da sich das Statement

 

var objektvar_starteKlasse_1 = new starteKlasse_1("1.) Klasse 1 aufgerufen!")

 

also aus zwei Teilen zusammensetzt, nämlich der Deklaration

 

new starteKlasse_1("1.) Klasse 1 aufgerufen!")

 

und der Initialisierung

 

var objektvar_starteKlasse_1 = …,

 

hindert uns niemand daran, die Deklaration

 

new starteKlasse_1("2.) Klasse 1 aufgerufen!")

 

ein weiteres Mal vorzunehmen! Dieses mal aber mit dem

 

Übergabetext "2.) Klasse 1 aufgerufen!".

 

Wann und wie aber lässt sich die Deklaration

 

new starteKlasse_1("2.) Klasse 1 aufgerufen!")

 

aufrufen, wie verhält sich diese und mit welcher Reaktion muss man rechnen? Wird der

 

Übergabetext "2.) Klasse 1 aufgerufen!"

 

tatsächlich in der Objektvariablen objektvar_starteKlasse_1.showStringVar abgespeichert? Ja, aber nur, wenn wir dies durch das Programmieren der Statements

 

let tempStrVar: string = "2.) Klasse 1 - aufgerufen!"

 

new starteKlasse_1(tempStrVar)

objektvar_starteKlasse_1.showStringVar = tempStrVar

 

extra veranlassen! Und zwar im Hauptprogramm!

 

Wenn man das neue und abgeänderte Programm microbit_teil_02_prog_32c.hex mit dem Quellkode microbit_teil_02_prog_32c.js startet, dann wird als erstes das Statement

 

var objektvar_starteKlasse_1 = new starteKlasse_1("1.) Klasse 1 aufgerufen!")

 

ausgeführt. Als Zweites wird dann das Statement

 

new starteKlasse_1("2.) Klasse 1 aufgerufen!"),

 

aber erst nachdem die Menüauswahl durch Berühren des Sensors „Pin P0“ verlassen wurde und man sich wieder im Hauptprogramm befindet!

 

Wer aber meint, dass mit dem Aufruf des Statement

 

new starteKlasse_1("2.) Klasse 1 aufgerufen!"),

 

der Übergabetext "2.) Klasse 1 aufgerufen!" in die Objektvariable objektvar_starteKlasse_1.showStringVar übernommen und abgespeichert wird, der befindet sich auf dem Holzweg:

 

 

(Zum Vergrößern bitte auf das Bild klicken!)

 

Da es sich beim dem Statement

 

new starteKlasse_1("2.) Klasse 1 aufgerufen!")

 

nur um eine Deklaration der Klasse starteKlasse_1 handelt, wird die Objektvariable objektvar_starteKlasse_1.showStringVar nicht angesprochen, nicht initialisiert, sodass der Übergabetext "2.) Klasse 1 aufgerufen!" eben nicht im Objekt, sondern nur in der Klasse starteKlasse_1 abgespeichert wird! – [ zurück ]

 

[ Video 14 ]

 

Frage 2

 

Erklären und begründen Sie, weshalb man im Hauptmenü des Hauptprogramms ebenfalls den Menüschalter mit der Variablen „menueswitch = false“ programmieren muss (siehe roter Kosten im obenstehenden Bild).

 

Antwort zu Frage 2

 

Wie wir bereits wissen, wird mit dem Statement

 

basic.forever(() => { … })

 

engl. „for ever“, d.h. quasi für immer das Hintergrundprogramm „for ever“ gestartet. Und zwar so lange bis der Strom ausfällt bzw. das Programm durch Drücken des rückwärtigen „Reset“-Tasters neu gestartet wird.

 

Demzufolge lauscht das „embedded Linux“-Betriebssystem des kleinen micro:bit“-Rechners permanent an einem bestimmten Port nebst entsprechendem Interrupt, ob eventuell im laufenden Programm einer der Taster A, B oder AB oder Pins P0 bis P2 betätigt bzw. angesteuert wurden. Sollte dies der Fall sein, wird sofort das (Haupt-) Programm gestoppt und in das Hintergrundprogramm „for ever“ verzeigt, um dieses auszuführen. Im vorliegenden Fall wäre das also unser Hauptmenü im Hauptprogramm.

 

So schön und praktisch das Hintergrundprogramm „for ever“ auch sein mag, so wissen wir im Moment trotzdem noch nicht, wie man dieses wieder deaktiviert oder verlässt, da sich z.B. der „break“-Befehl zum Verlassen einer Schleife dabei nicht anwenden lässt!

 

Für uns erschwerend kommt noch hinzu, dass sich der, engl. event handler, d.h. Ereignis-Handhaber die Tastendrücke wie z.B. auf einen der Taster A oder B merkt.

 

Und zwar mit der für uns unangenehmen Folge, dass der zuvor ausgelöste Tastendruck wegen der Zwischenspeicherung des „event handler“ nun auch auf das neu aufgerufene (Haupt-) Menü angewendet wird, obwohl wir weiter noch gar keine Taste gedrückt haben!

 

Damit sich der zuvor gespeicherte Tastendruck auf einen der Taster A oder B wider Erwarten nicht noch ein weiteres Mal auswirkt, wird beim Drücken der Taster A&B der Menüschalter „menueswitch“ auf engl. „false“, d.h. falsch, nicht zutreffend gesetzt:

 

 

(Zum Vergrößern bitte auf das Bild klicken!)

 

Da wir im Moment zum „forever“-Hintergrundprogramm keine Einzelheiten z.B. zur Wirkungsweise wissen, wurde bei der Programmierung der Untermenüs in den Klassen „starteKlasse_1“ und „starteKlasse_2“ auf den „forever“-Einsatz bewusst verzichtet:

 

 

(Zum Vergrößern bitte auf das Bild klicken!)

 

Der Knackpunkt beim „forever“-Hintergrundprogramm ist nämlich der, dass wir noch nicht wissen, ob sich das Programm auch mehrfach im Hintergrund wie z.B. in der Klasse „starteKlasse_1“ und „starteKlasse_2“ starten und ausführen lässt und zwar mit der Maßgabe, dass diese beim Hintergrundbetrieb auch tatsächlich funktionell auseinander gehalten werden, also funktional getrennt voneinander arbeiten! Aber genau das wissen wir nicht, müssten wir experimentell selbst herausfinden! Dazu muss man wissen, dass jedem Aufruf des „forever“-Hintergrundprogramms ein eigener Speicherbereich im Arbeitsspeicher zugewiesen werden muss, da sich nur so, die separat ablaufenden Prozesse einzeln verwalten und auseinander halten lassen! Technisch nennt man das übrigens „threading“. [ Video 15 ]

 

Bei einem modernen Browser (wie z.B. Vivaldi) wird jeder neue Tab in einem eigenen Thread geöffnet. Wenn also z.B. eine Webseite eines Webservers, die in einem Tab geöffnet wurde, wider Erwarten nicht antwortet und damit den Browser normaler Weise zum Abstürzen bringt, so ist das beim „threading“ nicht möglich, weil jede Webseite in einem eigenen Thread (= eigener Speicherbereich im Arbeitsspeicher) läuft und deshalb den Browser als Ganzes eben nicht zum Abstürzen bringen kann! – [ zurück ]

 

 

 

[ Home ] [ zurück ] [ Seitenanfang ]