Das deutsche QBasic- und FreeBASIC-Forum

[HorstD]

[Elor]

@Neuling...
wenn ich das richtig gesehen habe, hast den den Hinweis von nemored
(Strings in der UDT auf eine feste laenge zu Deklarieren) in deinem Code-Schnipsel noch nicht befolgt. Solange das der fall ist wird das mit Get/Put nicht Funktionieren(egal ob im Binary oder Random-Modus).

Dein DatenType koennte z.B. so aussehen:

[RockTheSchock]

Ich habe dein Beispiel mal etwas aufgebohrt und ein bisschen Objektorientierung reingebracht.

http://www.freebasic-portal.de/porticula/adressen-speichern-mit-datei-datenbank-1646.html

Normalerweise sollte man bei größeren Projekten Type TAdresse und TKonto und TFirma in eigene bi und bas Dateien auslagern. Dabei kommen die Deklarationen in die bi Datei und die Implementationen in die bas datei. Die bi Dateien werden in den bas Dateien mit include eingebunden und nachher werden alle bas Dateien kompiliert.
der Compilierbefehl dafür sieht etwa so aus;
fbc -g -s console Hauptprogramm.bas TFirma.bas
da werden einfach immer weitere module drangehängt die dazugehören.
Solltest du TAdressen um eine EingabeÜberprüfungsfunktion werweitern wollen gehört das in TAdresse.bas
Wenn du ein Projekt in der IDE anlegst, wird das etwas vereinfacht.

also z.B. TFirma.bi

[Neuling]

[nemored]

[Elor]

Noch ne kleine Bemerkung zur Laengenangabe deines Datentyps:
Der Datentype FirmenDatei ist nicht 120 Bytes, sondern 126 Bytes lang (erste Version). Im veraenderten Datentype bei dem noch zwei Strings dazu gekommen sind, gibst Du die laenge mit 151 Bytes an, die tatsaechliche laenge ist aber 162 Bytes. Ueberpruefen kannst Du das zum Beispiel so:

[Neuling]

Ich sehe schon, mit dem Datei-Handling hat man heute viel mehr Möglichkeiten - oder sehe ich das erst jetzt.

Da ist es sicher nicht fehl am Platz, wenn ich mich gerade deshalb nochmals intensiv um dieses Thema kümmere, indem ich die Dateien transponiere und gleichzeitig etwas "aufbohre". Schaden kann's nicht.

Den Befehl Print SizeOf(DateiName) werden ich mir gut merken. Danke.

[nemored]

Die Recordlänge spielt nur beim Dateimodus RANDOM eine Rolle und wird sonst ignoriert; im Dateimodus BINARY richtet sich die Anzahl der gelesenen Bytes an der Länge der Variablen, in die gelesen wird (das ist insbesondere wichtig, wenn ein String einzeln ausgelesen werden soll). Aber abgesehen davon empfiehlt es sich natürlich immer, die Länge eines UDTs nicht per Hand auszurechnen, sondern über SIZEOF zu bestimmen.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[RockTheSchock]

Wenn du Datensätze mit Random ließt solltest du beim Type mit Field festlegen welches Alignment gewählt wird. Sonst wird defaultmäßig 4 Byte genommen. bei QB sind es 1 byte. D.h. wenn du in Freebasic die alten Daten auslesen möchtest musst du field auf 1 setzen also

[dreael]

[RockTheSchock]

Ein möglicher Ansatz könnte es sein, den jetzigen Funktionsumfang bzw. den gesamten Unterbau mit den Hauptfunktionen der Software OpenSource Dual zu lizenzieren und die restlichen Zusatzfunktionen Closed Source zu machen, z.B. ein Berichts und ein Druckformular Modul.

Ein gutes Beispiel was mit Software so passieren kann:
http://www.blog-rundum.de/cao-faktura-was-fuer-ein-drama/

Und hier was man so auf Modulebene trennen kann.
http://www.cao-wawi.de/produkte/cao-faktura


Staroffice ist ein gutes Beispiel das gute OpenSource Software mit guter Basis kaum tot zu kriegen ist: http://de.wikipedia.org/wiki/StarOffice

[Neuling]

Kurzes Hallo für etwas (Nach)hilfe,

in den letzten Tagen habe ich weiter gelernt am Beispiel: Daten_konvert.zip <<https://www.hightail.com/download/OGhmS3hjNDJqY3B4Tk1UQw>>

existierende Daten einlesen und in andere Datei mit geänderter Struktur schreiben. Die vorher gemachten Erfahrungen haben mich ja vorsichtig werden lassen bezüglich des schnellen Fortschritts. Das hat sich bewahrheitet. Ich hänge hier gewaltig.

Meine Tests gingen um
OPEN FOR RANDOM, OPEN FOR BINARY, TYPE, FIELD, Datenstrukturen im Allgemeinen und schließlich noch um REDIM. Die Sache mit der Satzlänge ganz schön kniffelig. Addiert man die definierten (explizit und implizit) Längen und vergleicht das Ergebnis von SizeOf, kommt man mit der Angabe der Länge von SizeOf nicht mal annähernd an ein vernünftiges Ergebnis. Im vorliegenden Beispiel ist die gespeicherte Satzlänge (Short = 2 Byte, String = wie angegeben) 120 Bytes, SizeOf (eFir) bringt 6 Bytes mehr, was für jeden String ein NULL-Byte ist. Beim Einlesen der Daten darf dieses NULL-Byte aber keines Falls erscheinen. Ab der 2. String-Variable (eStrasse) ist der Inhalt um jeweils 1 Byte nach "vorne" verschoben. Gibt es eine einfache Möglichkeit, diesen Versatz zu vermeiden? Wenn möglich mit Verwendung der Variable "eFir" als Einheit.
Wenn es keine Möglichkeit gibt, muss ich umständlicher werden und mit SEEK arbeiten. Ist aufwändig, aber dann wohl unumgänglich. Hat aber gleichzeitig das Potential, mehr über Datenmanipulationen zu erfahren - schaden wird es sicher nicht. Bei REDIM habe ich anscheinend noch nicht ganz verstanden, was der genaue Zweck (Hintergrund) ist.

Ein weiteres Problem hat sich auf beim Konvertieren der eingelesenen Daten in die neue Variable "aFir", die mittels TYPE definiert ist. Wenn ich aFir.aNName = eFir.eNName zuweise, hat die Variable aFir.aNName Inhalte, die auf eine Übergabe von zusätzlichen Teilen von eFir hindeuten. Aber warum wird nicht nur der reine Inhalt von eFir.eNName übergeben?

Eine weitere Unklarheit:
Kann der Aufruf der SUB MySub1 (Var1, Var2, Var3, Var4) so gesehen werden, dass "MySub1" eine Variable mit dem Inhalt "Var1Var2Var3Var4" und in genau dieser Folge und Darstellung ist? Logischerweise ist "Var2" im Falle einer Zahl entsprechend "umzusetzen" und "Var1" im Falle eines Strings "as it is" zu sehen.

Die Strukturierung, die RokTheSchock zurecht angemahnt hat, habe ich in diesem Beispiel noch nicht umgesetzt. Die verwendeten SUB habe ich deshalb "angelegt", damit ich gleich noch die Verfügbarkeit und Übergabe von Werten in und aus SUB/FUNCTION bedenken muss. Es soll aber auch eine "Vorstrukturierung" sein, um dann in Richtung .bi usw. weiterzukommen. Auch hier sind mir ein paar Lichtlein aufgegangen, aber auch (s. oben) noch "dunkel".

Die "FIRMEN.DIR" ist die ursprüngliche Datei (erstellt von PDS7.x), aber mittels HEXEditor im Inhalt geändert. Die originale Daten sind natürlich als Kopie gesichert.

Ich arbeite vorwiegend mit FbEdit 1.0.7.6c, in dem es eine Auswahl an Einstellungen gibt: Windows GUI, Windows GUI (debug), Windows Console, Windows Console (debug) usw. Was bewirken hier die Änderungen in meinem derzeitigen Kenntnislevel? Welche Auswahl soll ich treffen?

Herzlichen Dank im voraus.
Dietmar

@RockTheScock: Auf deinen Post vom 09.09.2013 15:10 gehe ich später mal ein, wenn ich ein bisschen weiter bin.

[HorstD]

Nur als Info / Anregung
Es gibt Alternativen zu Freebasic.

Dieser Hexdump (siehe 5.9.)

[nemored]

So kompliziert wird es mit dem SEEK nicht. UDT-Länge * Datensatznummer (beginnend mit 0) + Offset des Records + 1 (weil das erste Byte nicht die Nummer 0, sondern 1 besitzt).

Warum darf das Nullbyte beim einlesen nicht erscheinen? Ein String hat intern doch an den Inhalt so oder so ein Nullbyte angehängt. Ob das Nullbyte "sowieso da" ist oder mit eingelesen wird, macht für mich keinen erkennbaren Unterschied. Muss die Datei noch von einem anderen Programm eingelesen werden? (Und wenn ja, warum kann dieses Programm dann nicht einfach den eingelesenen String um 1 kürzen? )

Man kann das mit dem Nullbyte schon per Hand irgendwie lösen; dazu wäre es aber erst wichtig zu wissen, warum es stört.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[Neuling]

@Horst:
Ich habe zur Kenntnis genommen, dass PowerBasic existiert. Allerdings habe ich keinen Download-Link gefunden, mit dem eine kostenlose Version zu bekommen war. Alle von mir gefundenen Wege führten dazu, dass zuerst ein Bezahlvorgang abgeschlossen werden musste, bevor ein Download möglich war. Und - just for fun - mal $199,- ausgeben, das möchte ich im Augenblick nicht. Als uneingeschränkte Version habe ich nichts gefunden; FirstBasic hat genau die Einschränkungen, die nicht sein dürfen. Auf <<http://www.qbasic.de/pb/#pbdown>>habe gerade nochmals nachgesehen, die Ausführungen zu PB sind interessant. Es geht mir nicht darum, alles kostenlos zu bekommen. Nur zu "Lernzwecken" möchte ich kein Geld investieren. Wenn ich mal den genaueren Weg und das endgültige Ziel kenne, ist das nicht der Knackpunkt.
Wenn wir gerade dabei sind: Falls ich mich für PowerBasic entscheiden sollte, müsste ich kaufen?
1. PowerBASIC Compiler 10.0 for Windows
und/oder
2. PowerBASIC Console Compiler 6.0 for Windows

@nemored:
Kompliziert wäre das nicht, nur aufwändig. Es gibt eine Datei, in der sind pro Datensatz (1415 Bytes) ca. 30 Variablen, davon ca. 10 als Arrays - teils STRINGs, teils numerisch (2 Byte & 4 Bytes) gespeichert. Und das zwischen vielen INTEGER (2 Byte) bzw. LONG (4 Byte) - bezogen auf den "alten" QB-Code.
Es geht um das Einlesen bestehender, alter Daten, das nicht richtig tut. Damals wurde das Stopp-Byte (NULL-Byte) nicht benötigt. Bei der Definition, wie ich sie in der ZIP-Datei verwendet habe, gibt es das Problem, dass ab der 2. STRING-Variablen der Anfang um jeweils 1 Byte abgeschnitten wird. Die TYPE DateiName FIELD = 1 erzeugt automatisch dieses NULL-Byte. Warum sonst verschiebt sich der Inhalt um genau 1 Byte pro STRING-Variable? Und dabei sind die 1. Variable (SHORT) und die 2. (1. STRING) noch korrekt. Mit der EXE-Datei im Download kannst du das leicht nachprüfen - und zwar 1:1 wie ich es erlebt habe. Mit der BAS-Datei könnte - je nach Compiler? - dieses Problem nicht mehr auftauchen.

Deine einfache Formel UDT-Länge * Datensatznummer + Offset des Records + 1 funktioniert aus dem Grund nicht, weil ja innerhalb eines eingelesenen Datensatzes ja bereits eine Verschiebung statt findet. Es bliebe da nur das variablenweise Einlesen, was im vorliegenden Beispiel (gerade) noch überschaubar ist. Aber bei einem Datensatz wie beschrieben und obiger Definition kaum noch überschaubar - auch mit sehr guten Mathekenntnissen. Die ganze Arbeit würde dann im Erstellen von Formeln und händischem Tippen von Variablennamen bestehen. Wenn du willst, kann ich die Datendefinition gerne hier einstellen.

Schau bitte mal mein Programm an. Danke schön und schönen Abend.

[nemored]

[Elor]

@Neuling: Ich wuerde die Konvertierung mit QuickBASIC durchfuehren und zwar so, das man die Daten in FB erst mal verwenden kann. Wenn du dann die Struktur veraendern willst hast du's nicht mehr so schwer. Ich hab mal deine Beispiel-Firmendatei aus deiner Zip in eine FB-Kompatible Datei Konvertieret. Ich hab die Strings im Datentyp fuer FB um ein Byte verlaengert, und diese struktur dann in einer neuen Datei gespeichert. Im FB-Programm muss dann wieder die alte strukturlaenge verwendet werden, funktioniert gut. Das Programm fuer QuickBASIC sieht so aus:

[Neuling]

@nemored:
Durch die Definition

[Elor]

Hallo... ich hab mir die Bilder angeschaut und werde das gefuehl nicht los,
das du beide Programmcodes mit FB Ausgefuehrt hast, das Funktioniert nicht. Ich habe folgendes verwendet.

1. Fuer das QuickBASIC Programm, den Konverter, habe ich QuickBASIC
4.5 verwendet, es geht aber auch mit der Version 7.1.
2. Als Datendatei habe ich deine Beispiel Datei "FIRMEN.DIR" aus deiner
Daten_Konvert.zip verwendet.
3. Die Konvertierte Datei "FIRMEN.NEU" wird dann mit dem zweitem
Programm fuer FB gelesen und Angezeigt.
Und bitte... nicht mit den Typlaengen herum Spielen, der Datentyp ist nun mal 120 Byte unter QuickBASIC und 126 Byte unter FB.

Es geht doch darum: QuickBASIC verwendet (im gegensatz zu FB) keine zwischenraumzeichen bei einem UDT-Datentyp mit Strings. FB Interpretiert aber jedes Zeichen nach der Stringlaengendeklaration als trennbyte. Das ist der grund warum da immer das erste Zeichen vom folgenden String fehlt und das Addiert sich je groesser der Datensatz b.z.w. je mehr Strings enthalten sind.
Mit QuickBASIC kann mann diese Datensatze aber richtig einlesen.
Die Idee die hinter meinem Programmcode steckt, ist einfach der, das man in der UDT-Kopie jeden String um ein Byte verlaengert und FB so ein zwischenraumzeichen zur verfuehgung stellt.

[HorstD]