Inoffizielles deutsches Xbase-Forum

hi,

ich war mal am Original DBU Source um es nach Xbase++ VIO zu portieren. Das ganze war in paar Minuten erledigt.
dann habe ich mit der Option /w compiliert und dem entsprechend hat er eine lange Liste an Warnungen ausgespuckt.

mir war schon klar das es viele PRIVATE / DECLARE gibt die irgendwo im DBU Source auftauchen können.
dann sah ich eine solche Konstruktion

Code: Alles auswählen

PRIVATE i,j,k

na klar habe ich mir gedacht das ist bestimmt für irgendwelche Schleifen gedacht also suchte ich nach "FOR i".

zu meinem Erstaunen fand ich nichts in dem PRG ...

dann mal "M->i" und d gab es viele Treffer und das in mehreren PRG Dateien

eine PRIVAT die aus 1 x Zeichen besteht ... wie soll man so was in einem Project finden

ok die sind zwar alle mit "M->i" geschrieben aber verwirrend ist es schon i,j,k durch ganz DBU zu jagen ...

hat man früher wirklich so programmiert

Die findet man doch leicht in einem geeigneten Editor:
Suche nach: i
[x] Ganzes Wort
Mehr Optionen braucht es nicht.

Viele Grüße,
Martin

AUGE_OHR hat geschrieben: ↑Di, 10. Okt 2017 10:03hat man früher wirklich so programmiert

Ja klar! Und um ehrlich zu sein - in FOR...NEXT-Schleifen mache ich das heute noch so. Meistens. Ab und an habe ich auch Erbarmen mit mir und benutze ordentlich benamte Zähl-Variablen. Aber meistens schlägt die alte Angewohnheit doch wieder durch , und dann kommt doch wieder i.

Bei einem Kunden von mir gibt es zusätzlich stapelweise normale Variablen (also nicht in Zählschleifen) wie x, zz, h, usw. Sogar Feldnamen, die nur aus einem Buchstaben bestehen, und natürlich nicht mit dem Alias davorgestellt genutzt werden. Das ist ist immer eine Sucherei ...

Jan

AUGE_OHR hat geschrieben: ↑Di, 10. Okt 2017 10:03hat man früher wirklich so programmiert

was hat das mit "früher" zu tun?

Roland,

insofern, als das wir ja alle lernfähig sind, Erfahrungen machen, und damit heute lieber "sprechende" Variablennamen benutzen, die sich auch leicht finden lassen. Und auch nicht mehr ultrakurze Variablennamen benutzen, nur weil die Programmiersprache oder der Speicherplatz auf der Diskette nicht mehr hergeben.

Jan

Servus Jan

das ist doch klar dass das besser ist mit sprechenen Variablen.
Da es aber nicht nur bei Alaska in den Sources und Dokus noch viele Beispiele mit Variablen in der Form i, j, k geben wird kann man davon ausgehen, dass Neulinge auch wieder mit diesen Kurznamen anfangen werden.
(Nicht nur in Xbase++, in vielen Codes im Internet, MSDN usw.)

Und es funktioniert ja auch - deshalb zeitlos...

Jimmy, DBU ist ein Konstrukt, welches seit Uraltzeiten besteht und jeweils nur angepasst wurde. Daher die Uralt-Dinge, welche heute als fatale Falschprogrammierung enttarnt werden.

Herbert,
so ein Schmarn. DBU läuft im Gegensatz zu vielen anderen Programmen bis heute klaglos.
Möchte nicht Deine Programme aus der Zeit sehen.

Hallo Klaus,

naja, so ganz Unrecht hat Herbert ja nicht. Sehr viel, was in dbu programmiert ist bzw. wie, würde heute vermutlich kaum einer von uns heute noch so machen. Der Stil der Programmierung hat sich halt geändert im Laufe der Jahre und Jahrzehnte.

Was aber, und da stimme ich mit Dir überein, nichts daran ändert, das dbu trotz des aus heutiger Sicht streckenweise kruden Codes immer noch ein Muster an Stabilität ist.

Jan

Einspruch!
Wenn man mit dem alten DBU eine Strukturänderung einer Tabelle macht (Feldnamen und gleichzeitig Feldlänge ändert) dann gibt es eine Absturz.
Sonst sind mir persönlich keine weiteren "Fehler" bekannt.

hi,

ich habe von PRIVATE i,j,k gesprochen nicht von LOCAL wie ich es auch in der Kurzform verwende.
JA ich glaube DBU kommt noch von Summer87 und da gab es noch keine LOCAL

Bertram Hansen hat geschrieben: ↑Di, 10. Okt 2017 17:01 Wenn man mit dem alten DBU eine Strukturänderung einer Tabelle macht (Feldnamen und gleichzeitig Feldlänge ändert) dann gibt es eine Absturz.

es liegt nicht am Code von DBU denn die Cl*pper Version machte es ohne Probleme.

Code: Alles auswählen

DBUSTRU.PRG ca. Zeile 1270 

   stat_msg(IF(new_name <> "J", "Ändere Dateistruktur",;
           "Ändrere Feldname(n)"))

     * save the old and create the new
     RENAME &filename TO &name_temp
         cAlias := MakeAlias( filename )
         CREATE &filename FROM ddbbuuuu.ext ALIAS cAlias

     IF new_name = "J"
       * change field names by copying SDF
       USE &name_temp
       COPY TO ddbbuuuu.txt SDF
       USE &filename
       APPEND FROM ddbbuuuu.txt SDF
       ERASE ddbbuuuu.txt
     ELSE
       * normal modify structure
       APPEND FROM &name_temp
     ENDIF

Das Xbase++ Problem liegt in SDFDBE wo ich beim Export/Import nie wirklich klar gekommen bin mit dem "Ergebnis".
wenn man die COPY TO / APPEND FROM auf FWrite() / FRead() umschreibt und mit FieldPut() arbeitet funktioniert es einwandfrei.

Koverhage hat geschrieben: ↑Di, 10. Okt 2017 15:47 Herbert,
so ein Schmarn. DBU läuft im Gegensatz zu vielen anderen Programmen bis heute klaglos.
Möchte nicht Deine Programme aus der Zeit sehen.

Eh, habe ich doch gar nicht behauptet...

Jan hat geschrieben: ↑Di, 10. Okt 2017 15:57 naja, so ganz Unrecht hat Herbert ja nicht. Sehr viel, was in dbu programmiert ist bzw. wie, würde heute vermutlich kaum einer von uns heute noch so machen. Der Stil der Programmierung hat sich halt geändert im Laufe der Jahre und Jahrzehnte.

Jan, danke, genau so meinte ich die Sache!

ich "denke" ich habe raus wofür M->i steht : es ist der SELECT() Ausdruck

PRIVATE und DECLARE sind zusammen > 300 ...

alles in eine *.CH Datei "generiert" damit ich nicht die ganzen /Warnungen sehe ... und dabei den Fehler übersehe

Frage : wenn ich aus einer PRIVATE eine LOCAL mache und vergesse die MEMVAR aus der *.CH zu löschen ... wie "finde" ich die

---

DBU ist ja nur für NTX ausgelegt. es werden nur *.NTX Index Dateien angezeigt obwohl der Title "*.CDX" ( IndexExt() ) anzeigt. ich kam nun darauf das es eine Prüfung geben müsste und fand NTX_KEY() welche z.b. einen "leeren" CDX IndexKey() anzeigte. der Grund ist nun diese Stelle im Original DBU Source

Code: Alles auswählen

═ DBUUTIL.PRG ═ ca. Zeile 2845

FUNCTION ntx_key()
...

* open the file and get handle
handle = FOPEN( M->filename )
IF FERROR() = 0
   * allocate 512 byte buffer
   buffer = SPACE( 512 )
   * read the index file header into memory
   FREAD( M->handle, @buffer, 512 )
   * discard all bytes before the key expression
   k = SUBSTR( M->buffer, M->k_pos )
   * the expression is terminated with a zero byte (chr(0))
   k = TRIM( SUBSTR( M->k, 1, AT( CHR( 0 ), M->k ) - 1 ) )
ENDIF

* close the file and release the handle
FCLOSE( M->handle )

das ganze diente (früher) dazu den INDEXKEY(), von NTX Dateien, auszulesen aber funktioniert natürlich nicht mit CDX

Inoffizielles deutsches Xbase-Forum

DBU und i, j, k

DBU und i, j, k

Re: DBU und i, j, k

Re: DBU und i, j, k

Re: DBU und i, j, k

Re: DBU und i, j, k

Re: DBU und i, j, k

Re: DBU und i, j, k

Re: DBU und i, j, k

Re: DBU und i, j, k

Re: DBU und i, j, k

Re: DBU und i, j, k

Re: DBU und i, j, k

Re: DBU und i, j, k

Re: DBU und i, j, k