Multiple Choice Test programmieren - Full Screen - Anfänger

[MichiS]

Hallo!
Ich bin Anfänger und möchte einen Test im Full-Screen-Modus programmieren. Vom Kenntnisstand bin ich etwa so weit, dass ich das ganze über die Konsole und über Zahleneingabe programmieren kann. Nun möchte ich das aber im Full-Screen-Modus machen.
Das sollte dann in etwa so aussehen:

leerer Bildschirm, dann Frage z.B. "Wieviele Staaten gehören zur EU?" in die Mitte des Bildschirms, dann 3 Möglichkeiten, die Schaltflächen mit Zahlen sind, mit der Maus sollte beantwortet werden können, bei richtigen Antworten soll sich eine Variable um den Wert 1 erhöhen, und dann der Bildschirm wieder leer werden und dann die nächste Frage kommen, zum Schluss soll ein Textfile generiert werden, dass die erreichten Punkte enthält.

Was ich z.B nicht weiß, ist, ob man direkt im Full-Screen-Modus schreiben kann oder ob man da Bilder mit enhaltenem Text reinsetzen muss. Und wie das funktioniert, dass bei einem Mausklick auf die richtige Schaltfläche die nächste Frage kommt.

Vielleicht kennt jemand ein ähnliches Programm, wo ich mir etwas Code anschauen könnte?

Ich wäre auch sehr dankbar für eine Hilfe, ich weiß auch derzeit nicht, nach welchen Stichwörtern ich suchen soll.

[Kaeru Gaman]

Erstmal Willkommen im PureBoard!


okay, dein Problem hat mehrere Abstufungen.

erstmal allgemein zum screen:

du hast dort nativ keine Objektunterstützung, d.h. du musst die clicks
und die Mauskoordinaten selber auswerten und selber schauen,
ob da z.B. ein knopf drunter ist oder nicht.

natürlich kannst du auf einen Screen direkt Text ausgeben,
du kannst auch ne menge andere Sachen direkt draufzeichnen,
schau dir am besten in der Help mal das Kapitel 2D Drawing an.

Auf einem Screen wird 30 - 200 mal in der Sekunde neu gezeichnet.
du musst also solange dieselbe Frage angezeigt wird, dieselben dinge immer wieder ausgeben,
und du musst dann, wenn die nächste Frage kommen soll, die Inhalte wechseln,
und die neuen dann auch wieder immer wieder ausgeben.
Eben im Gegensatz zu der Console, wo du einmal deinen Text hinschreibst,
und der nach oben wegscrollt wenn du was neues ausgibst.
du musst also unter der Haube schon mal ganz anders organisieren.


weitergehend musst du dann natürlich schauen, wie du die Daten in deinem Test organisierst.
da wäre es wahrscheinlich nützlich, Fragen und Antworten in eine Textdatei auszulagern,
die zum Programmstart in eine Liste eingelesen wird.
professioneller wäre die Verwendung eines Datenbanksystems,
aber das wäre für den Moment bestimmt zuviel aufwand.


ich kann mich jetzt nicht erinnern, dass schon mal so ein Multiple-Choice-Test-Programm
für den Screen im Forum beschrieben wurde.

wenn es irgendwo ein Beispiel gibt, dann war das glabich für ein Fenster mit Gadgets,
da ist die Problematik etwas anders gelagert als auf einem Screen.


das erstmal zum Überblick.

[MichiS]

Oje, ich hätte gedacht, eine Zeile auf den Screen zu schreiben wäre was eher Einfaches. Ich glaube ohne Beispiel oder ein zumindest ähnliches Gerüst werd ich das nicht hinkriegen.

nach einigem Lesen weiß ich jetzt, dass

ich die Befehle brauche:
OpenScreen(800,600,16,"Test") - für Screen, noch fraglich wie der weiß wird
InitSprite() - um Grafiken zu platzieren (Schalter)
LoadSprite() - holt Schaltergrafik ins Programm
locate? - um das Ganze zu positionieren
StartDrawing() - und dann Text eintragen
InitMouse() - für Mausbefehle
If MouseButton(1) - wo dann die Schalter sind soll dann etwas passieren, wenn der Mausknopf gedrückt ist

aber wie ich diese Befehle anwende ist mir noch ein Rätsel, wie kann ich das am Besten lernen

[Kaeru Gaman]

also, es gibt im Paket schon mal einige Beispiele zu den Screen Befehlen.
einfach mal durch den Ordner "\Examples\Sources\" stöbern.

auch hier im Forum sind etliche Beispiele zu finden, was man mit nem Screen alles machen kann.

> ich hätte gedacht, eine Zeile auf den Screen zu schreiben wäre was eher Einfaches.

öhm, ja, ist es eigentlich auch.

du musst halt nur beachten, dass du sie zig mal in der sekunde wieder schreiben musst /solltest,
und dass du eben irgendwo den Text herholen musst wenn er sich ändert.


... die Daten die drunterliegen, musst du ja bei nem Consolen programm auch wo her holen.
vielleicht hast du die bisher hardgecoded, also in den Programmcode direkt reingeschrieben.
das geht zwar, aber ist unflexibel.

[mk-soft]

Geht auch ohne Screen mit Standard GUI.

Code: Alles auswählen

ExamineDesktops()
win_dx = DesktopWidth(0)
win_dy = DesktopHeight(0)

If OpenWindow(0 , 0 ,0, win_dx, win_dy, "MyWindow", #PB_Window_BorderLess)

  SetWindowColor(0, RGB(0,0,240))
  
  CreateGadgetList(WindowID(0))
    ButtonGadget(0, win_dx / 2 - 60, win_dy / 2 - 22, 120, 24, "Exit")
  
  Repeat
  
    evid = WaitWindowEvent()
    
    Select evid
      Case #PB_Event_Gadget
        gdid = EventGadget()
        Select gdid
          Case 0
            exit = 1
        EndSelect
        
    EndSelect
    
  Until exit

EndIf

FF

[ts-soft]

Ich frag mich die ganze Zeit, warum es Fullscreen sein soll? Es gibt für mich
nichts schrecklicheres als Fullscreen Programme, jedenfalls grundlos.
Bei Spielen macht es ja sinn und wenn ich Video schaue manchmal auch,
aber ansonsten nervt so ein Fullscreen nur, ausserdem wird bei meiner
Auflösung sowieso die größte Fläche leer bleiben
Verhindern das man andere Sachen macht, kanns auch nicht, die mache ich
am zweitem Bildschirm

[Kaeru Gaman]

ich bezweifle aber mal lebhaft, dass du zur zielgruppe eines "ich probier mich mal an programmierung"-multiple-choice-test gehörst.

[ts-soft]

Ich möchte ihn ja auch nur dazu anregen, nochmal über das
Oberflächendesign nachzudenken. Weil vor dem Beginn erspart es manchmal
eine Menge arbeit.
Nicht nur das Wie ist wichtig, das Warum auch!

[MichiS]

Ja, das mit der GUI ist auch gut für mich, ich hab die Möglichkeit einfach nicht gekannt. Ich muss das mal ausprobieren und ob ich da auch Grafiken einbauen kann.

[ts-soft]

Für Grafiken gibts das ImageGadget, für Grafiken auf Buttons gibts das
ButtonImageGadget