|
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
e45tg4t3
Anmeldungsdatum: 13.01.2013 Beiträge: 4
|
Verfasst am: 13.01.2013, 04:31 Titel: Tastenabfrage, Probleme bei schreiben und lesen aus 2D Array |
|
|
Guten Tag an alle,
mein erster Post hier.
Erstmal zum aussenrum:
Programmiert werden soll ein kleiner Sequencer für den parallelen Port. Die Eingabe soll über die Cursortasten und die Leertaste, in ein am Bildschirm dargestelltes Gitter erfolgen. Die Abfrage der Cursortasten funktioniert bereits ohne Probleme, jedoch das "Aktivsetzen" des jeweiligen Kästchen noch nicht. Das Kästchen soll, wenn aktiv, mit einem X markiert werden, sowie in einem entsprechenden 2D Array(im code seqpp) eine 1 gesetzt werden. Zum deaktivieren soll das X mit einem Leerzeichen überschrieben und das entsprechende Array Element 0 gesetzt werden. Zur abfrage ob das Kästchen schon "Aktiv" gesetzt ist soll auch das Array genutzt werden.
So nun zum Problem:
Das erste Aktivsetzten funktioniert ohne Probleme, jedoch wird ein weiteres gewähltes Kästchen nicht beim ersten Druck der Leertaste sondern erst beim zweiten Aktiv gesetzt. Der Fehler liegt vermutlich bei der Abfrage des Array, da wenn ich dieses in einem File ausgeben lasse, schon nach dem ersten setzten Alle Elemente auf 1 gesetzt hat. Was natürlich nicht ganz Sinn der Sache ist
Ich hab das Aktivieren in einer Sub implementiert, der ich die Eingelesene Taste übergebe. Hier mal der Sourcecode:
Code: |
SUB MARKPOS (keyin AS STRING)
IF keyin$ = CHR$(32) THEN
curposx% = POS(0)
curposy% = CSRLIN
fposx% = INT(curposx% / 2)
fposy% = INT((curposy% / 2) - 2)
SELECT CASE seqpp(fposx, fposy)
CASE 0:
LOCATE curposy%, curposx%
PRINT "X";
seqpp(fposx, fposy) = 1
CASE 1:
LOCATE curposy%, curposx%
PRINT " "
seqpp(fposx, fpoxy) = 0
END SELECT
END IF
LOCATE curposy%, curposx%
END SUB
|
Der Negative Offset bei fcosy und der Faktor kommen von meinem Bildschirmlayout, also so wie die Kästchen liegen. Das Array seqpp wurde als SHARED erstellt, sodass ich auch in den Subs darauf zugriff hab.
Hab ich da iwo einen riesigen Denkknoten drinnen den ich nun einfach nicht erkenn?
Hat von euch jemand vielleich eine Idee wo das Problem liegen könnte?
Vielen Dank im vorraus
Ben |
|
Nach oben |
|
|
Sebastian Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 5969 Wohnort: Deutschland
|
Verfasst am: 13.01.2013, 14:05 Titel: Implizite Variablendeklaration in QB, Togglen eines Bitwerts |
|
|
Hallo und willkommen im Forum!
Ich vermute spontan, dass das Problem mit der impliziten Deklarierung von Variablen in QBasic zusammenhängt. QBasic erlaubt (leider) einen ziemlich unsauberen Umgang mit Variablen, was eine große Fehlerquelle darstellt.
Im Beispiel:
Während in diesem Fall keyin und keyin$ auf dieselbe Variable verweisen, ...
Code: | SUB MARKPOS (keyin AS STRING)
PRINT keyin
PRINT keyin$
END SUB |
... sind hier fposx und fposx% zwei unterschiedliche Variablen. Beide entstehen "einfach so" bei ihrer ersten Benutzung, ohne dass man sie deklarieren oder mit einem Wert belegen müsste:
Code: | ' Kleines Beispiel zur Demonstration
fposx% = 123
PRINT fposx%
PRINT fposx
SLEEP |
Während du die richtigen Koordinaten am Anfang in die Integer-Variable fposx% ablegst, greifst du später auf fposx zu. Dabei handelt es sich (höchstwahrscheinlich) um eine implizit deklarierte SINGLE-Variable, die QBasic automatisch erzeugt (in dem Moment, in dem du darauf zugreifst). (Nur "höchstwahrscheinlich", weil ich den Rest deines Programms ja nicht kenne und von daher nicht weiß, ob du sowas wie DEFINT A-Z benutzt.)
Von daher würde ich zunächst empfehlen, Variablen grundsätzlich mit DIM zu deklarieren und Suffixe dann wegzulassen. So kommt man nicht in das Problem, gleichzeitig mehrere Variablen mit gleichem Bezeichner, aber unterschiedlichen Typen zu haben.
Gegen Tippfehler hilft allerdings auch das nicht:
Code: | DIM kundenalter AS INTEGER
kundenalter = 28
PRINT kundenalter
PRINT kundenatler ' wird akzeptiert und als 0 angenommen, ohne das der Compiler meckert
' Angabe aendern:
kundnalter = 30 ' wird einer neuen SINGLE-Variablen zugewiesen
PRINT kundenalter
SLEEP |
Und noch zum Togglen der Werte: Das lässt sich auch etwas kürzer schreiben als mit dem SELECT-CASE-Block:
Code: | array(x,y) = 1 - array(x,y) ' Bit invertieren
IF array(x,y) = 1 THEN
PRINT "X"
ELSE
PRINT " "
END IF |
Falls sich das Problem noch nicht lösen lässt, wär es auf jeden Fall hilfreich, den kompletten Quelltext zu sehen und ein bisschen damit testen zu können.
Viele Grüße!
Sebastian _________________
Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen! |
|
Nach oben |
|
|
e45tg4t3
Anmeldungsdatum: 13.01.2013 Beiträge: 4
|
Verfasst am: 13.01.2013, 16:24 Titel: |
|
|
Hallo Sebastian,
ersteinmal Vielen Dank, bei deiner Antwort ist es mir dann wie Schuppen von den Augen gefallen. Dieses Problem hat sich nun gelöst, jedoch tauchte folgend ein weiteres auf, so dass nur in der ersten Array Reihe (seqpp(x,0)) Sauber die Werte getoggelt werden, in allen anderen Reihen werden die Elemente die 1 geschrieben wenn sie zuvor 0 waren, jedoch keine 0 mehr wenn diese einmal auf 1 gesetzt wurden.
Ich habe auch deine Lösung als Ersatz für das Toggeln der Werte versucht, allerdings hat dies keinen Unterschied gemacht.
Hab mal den Gesamten Sourcecode auf meine Dropbox gelegt:
https://www.dropbox.com/s/txly0x1aqws6m47/PARSEQ.BAS
So vielen Dank nochmal
Ben
edit: Sry hatte noch das Config File was benötigt wird vergessen:
https://www.dropbox.com/s/5l1ex1kiqzyq474/INSTR.CFG |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4644 Wohnort: ~/
|
Verfasst am: 13.01.2013, 17:54 Titel: |
|
|
Hmm - kannst du die Datei im reinen Textformat speichern? Das ist wohl das komprimierte QB-Format, das kann ich als Nicht-QB-Besitzer nicht lesen. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
e45tg4t3
Anmeldungsdatum: 13.01.2013 Beiträge: 4
|
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4644 Wohnort: ~/
|
Verfasst am: 13.01.2013, 21:14 Titel: |
|
|
Ich komme leider gar nicht so weit, weil unter FreeBASIC (mit -lang "qb" versteht sich) in der Prozedur MoveCur immer sofort in den ersten CASE-Fall gesprungen wird, egal was für eine Taste übergeben wurde
Gib dir evtl. mal mit PRINT o. ä. die Variableninhalte aus, um genauer einzugrenzen, woran es scheitert (zur Not, wenn es zu unübersichtlich wird, über eine Logdatei).
edit: Zeile 176
Code: | seqpp(fposx%, fpoxy%) = 0 |
genau ansehen, da ist ein Tippfehler drin. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
Sebastian Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 5969 Wohnort: Deutschland
|
Verfasst am: 13.01.2013, 22:03 Titel: |
|
|
nemored hat Folgendes geschrieben: | edit: Zeile 176
Code: | seqpp(fposx%, fpoxy%) = 0 |
genau ansehen, da ist ein Tippfehler drin. |
Tjaja, das sind die Probleme mit der impliziten Variablendeklaration.
Wenn du auf FreeBASIC umsteigst, hast du zumindest solche Fehlerquellen nicht mehr. In FreeBASIC musst du jede Variable mit DIM deklarieren. Wenn du da auf eine Variable zugreifen willst, die du nicht deklariert hast (z. B. weil du dich beim Bezeichner vertippt hast), beklagt sich gleich der Compiler und du kannst den Fehler gar nicht übersehen. _________________
Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen! |
|
Nach oben |
|
|
e45tg4t3
Anmeldungsdatum: 13.01.2013 Beiträge: 4
|
Verfasst am: 17.01.2013, 21:40 Titel: |
|
|
So, heute mal wieder zum Programmieren gekommen, Dankeschön an euch beide |
|
Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|