Das deutsche QBasic- und FreeBASIC-Forum

[St_W]

Ich kann nicht ganz nachvollziehen, warum man die Daten nicht einfach manuell einliest anstatt unbedingt ganze UDTs einlesen zu wollen. z.B. so:

[Elor]

[RockTheSchock]

Bitte schaue dir auch die Unterschiede zwischen len und sizeof in FB an.!
Die verhalten sich nicht exakt gleich gerade:
http://www.freebasic-portal.de/befehlsreferenz/sizeof-399.html
http://www.freebasic-portal.de/befehlsreferenz/len-328.html

[Neuling]

@Elor:
15.09.2013 18:56
Ich kann dir versichern, dass dieser Lapsus garantiert nicht passiert ist. Was allerdings zutrifft ist die Tatsache, dass ich weder mit PDS 7.x noch mit QuickBasic 4.5 gearbeitet habe. Beide Programme (DOS-Versionen) lassen sich bei mir auch mit allen möglichen Tricks nicht starten; dafür müsste ich auf Win XP wechseln. Ich habe beide Male FreeBasic verwendet; mit expliziter Angabe von '#lang "qb"' bzw. '#lang "fb"'. Falls hier ein Grund für die "falsche" Dateibehandlung liegt, ist ja eine mögliche Fehlerquelle entdeckt.

[Jojo]

[Sebastian]

Hallo,

man könnte die alte Quelldatei auch einfach Byte für Byte oder mit einem variablen Puffer einlesen, dessen Länge man je Feld individuell über SPACE(...) vorbereitet. Mit FreeBASIC kannst du jedes denkbare Dateiformat einlesen, genauso wie in C, VB oder wo auch immer.

FreeBASIC verwendet zur Speicherung und zum Laden von User Defined Types bloß nicht zwingend dasselbe Format wie QBasic oder irgendwelche anderen Sprachen bzw. Interpreter/Compiler. QBasics Methode zur Speicherung der UDTs ist ja keine DIN-Norm oder so, an die sich Compiler-Entwickler zu halten hätten. Wenn man mit den Komfortfunktionen, die die Sprache für sowas bietet, nicht zum Ziel kommt, weil sie nicht 100% kompatibel zu Jahrzehnte alter Software sind, muss man unterhalb dieser Abstraktionsschicht (UDT) ansetzen und selber die zu lesenden Byte-Anzahlen bestimmen.

Für das Programm besteht die Datei ja einfach nur aus einer Sequenz von Bytes. Diese Dateien als UDT einzulesen, ist eine Interpretation der Daten, die die Laufzeitbibliothek (von QB oder FB) für dich macht.

Früher hatten viele Anwendungen übrigens ganz eigene Binärformate. Gerne auch mit Unteraufteilung einzelner Bytes, sodass darin jedes Bit eine unterschiedliche Bedeutung (quasi Boolean) haben konnte. Das musste man auch manuell implementieren bzw. "auseinanderklamüsern" und konnte nicht die fertigen Easy-Go-Funktionen benutzen.

SEEK braucht man dafür aber dennoch nicht. Mit SEEK kannst du in der Datei an eine bestimmte Position springen. Du möchtest sie ja aber einfach nur in bestimmten "Portionen" komplett Stück für Stück nacheinander weg einlesen oder? Du kannst z. B. ungefähr Folgendes machen:

[Elor]

@Jojo: Ich hab nicht gesagt das UDT's ein Allzweckmittel fuer die Datenkonvertierung ist, ich hab einfach nur ein QB Programm geschrieben das seine eigene Datendatei auf einfache weise in eine FB Kompatible Datei umwandelt, sonst nichts. Ich bin davon ausgegangen das Neuling ein DOS Programm Ausfuehren kann, da es ja um ein DOS Programm geht.
Ich weis nicht ob man meine Methode jetzt Kritisieren muss.

[Neuling]

Hallo,

habe neben den übrigen Verpflichtungen jetzt alle Dateien erfolgreich konvertiert und dabei definitiv festgestellt, dass es nicht möglich ist, die mit QB 4.5 (PDS 7) erstellten Datendateien ohne diese Konvertierung zu nutzen. Spätestens beim ersten Speichern ist die Datei unbrauchbar. UDTs unter QB sind nicht gleich mit UDTs unter FreeBasic. Auch dann nicht, wenn man in FB die ehemaligen Integer-Variablen als SHORT deklariert. Sobald eine STRING-Variable gespeichert wird, ist der Inhalt "verschoben".

In den vergangenen Tagen habe ich mich auch noch intensiver mit UDTs, SUBs und FUNCTIONs beschäftigt. Man kann in FB deutlich sensibler damit umgehen, muss aber dafür die Konventionen gut kennen und entsprechend einsetzen. Die Befehle BYREF und BYVAL machen die Sensibilität und gleichzeitig Variabilität aus. In QB habe ich das nicht kennengelernt. Hier stecken sehr schöne Möglichkeiten drin, die man kennen sollte. Nochmal zur Erinnerung: Ich habe Programmieren nie (professionell) gelernt - es war learning by doing auf dem Hintergrund des BWL-Studiums gepaart mit sehr viel Interesse und Spaß an der Sache.

Im QB-Code habe ich zur Eingabesteuerung eine "Routine" gestellt bekommen, die ein Bekannter selbst geschrieben hat <<http://www.freebasic-portal.de/porticula/eingabe-in-qb-alt-1657.html>>. Die ermöglicht es, mittels Parameter die komplette Steuerung zu bewältigen. Cursor Up, down, links, rechts, Page up, down, ESC usw. können leicht abgefangen und umgesetzt werden. Diese Routine ist aber leider nicht FB-kompatibel. Und ein Anpassen ist mir nicht gelungen, da zu viele Variablen mit gleichem Bezeichner aber unterschiedlichen Typs in der SUB und dem Hauptprogramm verwendet werden. Und - QB-typisch - werden sie gerade verwendet wie sie kommen. In FB geht ohne Deklaration nichts. Das Alles ginge noch, aber es sind Befehle im Einsatz, die unter FB in dieser Form nicht arbeiten. In QB war es ursprünglich eine GOSUB und eine Anpassung an eine SUB will mir nicht gelingen. Das "Beste" daran ist aber, dass die Cursor-Steuerung "verschlüsselt" ist. Eine Abfrage nach z.B. Csr_Up (egal ob in IF ... ELSE... oder SELECT CASE ...) ist nicht möglich. Die einzelnen Codes sind umgesetzt in 1, 2, 4 usw. was ich nach der langen Zeit nicht mehr weiß. Auch der "Programmierer" kann es nicht mehr in angemessener Zeit entschlüsseln - wenn überhaupt.

Hierfür habe ich im FB-Portal ein verfügbares Programm gefunden, das ich fast bis ins letzte Detail verstanden zu haben glaube. Eines allerdings nicht. Das ist:

[nemored]

[HorstD]

Wenn es an dem CHR(255) statt CHR(0) liegt, versuch' mal folgendes:

[RockTheSchock]

Bitte kein Goto verwenden! Warum?

http://www.antonis.de/faq/index.html

[Neuling]

@nemored:

Sorry, wusste nicht (mehr), dass das deine Eingabe-Routine ist, die ich mir angeschaut habe und auch gerne nutzen würde. Dafür muss ich sie allerdings ganz verstehen. Wenn Zeile 1 "function inputusing (y as .... " ist, sind die Zeilen 159 + 160 diejenigen, die ich zitiert habe. Und den Begriff "Bitverschiebung" habe ich verwechselt mit "Bitvergleich". Bitte um Nachsicht.

Zeile 159 : if leftright and 1 andalso cursor > length then retvar = chr(0) : exit do
Zeile 160 : if leftright and 2 andalso cursor < 1 then retvar = chr(0) : exit do

Zeile 94 : case 62 : leftright or= 1 ' Verlassen bei rechter Ueberschreitung
Zeile 95 : case 60 : leftright or= 2 ' Verlassen bei linker Ueberschreitung

Du lieferst ja eine Erklärung und auch einen entsprechenden Befehl. Aber wieso ist es nötig, diese Verknüpfungen vorzunehmen? Ist es eine Notwendigkeit oder eher Kosmetik, damit der Code "eleganter" i. S. von einfacher ist. Wie müsste die Zeile 159 aussehen, wenn in Zeile 94 die OR-Verknüpfung nicht gemacht würde?

Dass "meine" Eingabe-Routine nicht funktionieren kann, hast du ja erklärt. Wenn ich da die Korrekturen von CHR(0) auf CHR(255) vornehmen würde, wäre sie dennoch wertlos. Mir fehlen die Umsetzungstabellen, die mir sagen, welcher Wert dann z.B. sagt, dass in der aktuellen Eingabe Csr up, Csr down, Enter oder Page down dann wie zu behandeln ist. Ohne diese Tabelle ist eine Nutzung unmöglich, auch wenn der Code in allen Belangen FB-kompatibel ist. Verantwortlich für die Cursorsteuerung sind die Variablen i, c, c0, f und f0, wenn mich nicht alles täuscht. Ehrlich gesagt möchte ich mich da jetzt nicht mehr so tief einarbeiten; man könnte vllt. herausbekommen, wie das zusammenhängt. Aber eine "modernere" Lösung wäre mir lieber.


@HorstD:
Weiter oben habe ich erklärt, warum hier der Dialekt (QB, FBLITe, FB, DEPRECATED) keine Rolle spielt. Da ist auch PB keine Lösung.

@RockTHeSchock:
Das wird eine Herausforderung, die ich annehme und versuche zu beherzigen. Wird im ersten Schritt nicht einfach, aber ich werde daran arbeiten. Die Konstanten werde ich als erstes umsetzen, weil das Klarheit schafft.

@alle:
Kann ich mit MULTIKEY die Bitvergleiche umgehen?

Vielen Dank für eure Hilfe.

[dreael]

Zum Thema Tastatur ein kleiner Testcode:

[nemored]

[RockTheSchock]

[nemored]

Ja, auf die habe ich ja verwiesen. (kann aber sein, dass du schon geschrieben hast, als cih noch am posten war, mein Thread ist mit der Zeit gewachsen ...)
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[St_W]

Wenn ich mir den Eingabe-Code so anschaue, frage ich mich wirklich, ob es nicht sinnvoller wäre das ganze Programm neu zu schreiben. So ein schlechter Programmierstil mit nichtssagenden Variablennamen, sehr vielen und ebenso nichtssagenden Sprungmarken (E1, E2, ... ; GOTO) sowie Konstanten als Werte direkt im Code (anstatt Konstanten mit Bezeichner zu definieren) wird dir eine Konvertierung in FreeBasic (aber wohl auch in PowerBasic oder andere halbwegs moderne Basic Dialekte) zur Qual machen. Es ist dadurch sehr schwierig die Funktionsweise schnell zu erfassen und den Code entsprechend anzupassen. Außerdem sind viele Konstrukte schlicht hoffnungslos veraltet und sollten komplett durch zeitgemäßen Code ersetzt werden.

Wenn der Rest des Programmes auch in diesem Stil programmiert ist würde ich definitiv vorschlagen, das Programm neu zu schreiben, wenn es irgendwie machbar ist. Wenn du dich z.B. für "Visual Basic.NET" entscheidest, bekommst du eine moderne, ausgereifte, funktionsreiche, kostenlose Programmiersprache und -umgebung, die zumindest hinsichtlich Syntax teilweise sehr ähnlich zu QBasic und FreeBasic ist. Technisch sind die Unterschiede jedoch sehr groß.
Dies würde dir erlauben grafische (Windows)Oberflächen mit dem enthaltenen Designer komfortabel zusammenzuklicken. Durch die Verwendung der vorhandenen Steuerelemente (Buttons, Eingabefelder, ...) entfallen auch manuelle Eingabebehandlungen zu großen Teilen.
_________________
Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken)