Xbase Version 2.0.710

Hier können die Unterschiede, Fehler und Probleme zwischen den Versionen bzw. bei der Migration besprochen werden

Moderator: Moderatoren

ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Xbase Version 2.0.710

Beitrag von ramses »

@Auge_Ohr
warum so viel Aufwand um eine Datei zu kopieren wie im Demo ?
Bei diesen Dateien handelt es sich um List&Label Projektdateien die vor dem Druck via DOM-Objekt entsprechend angepasst werden.
Im Multi-User System können gleichzeitig mehrere User das selbe Projekt (z.B. Lieferschein) drucken.
Es muss also für das Anpassen und den Ausdruck für jeden solchen Druckjob eine temporäre Projektdatei verwendet werden.
Alle andern File-Copy Metoden haben im Multiuser-Betrieb sporadisch zu Fehlern (Datei nicht kopiert) geführt.
Deshalb dieser Aufwand. Damit gabs dann nie mehr ein Problem. Diese Kopierfunktion war einfach die erste Stelle an der ich das Problem erkannte.

Das FSIZE(Filename) habe ich nicht versucht. Das ist auch keine Alternative.
FSIZE() muss einwandfrei funktionieren oder die ganze Xbase++ Umgebung ist schlicht unbenutzbar! Der plötzlich fehlerhafte 0 Rückgabewert hat in vielen anderen Bereichen (nicht dem Druckjob) in den Installation zu massiven Problem, Datenverlusten und vielen vielen Stunden Arbeitsaufwand geführt. Vom Ärger gar nicht zu sprechen.

Von einer LOW-Level Funktion wird ohne wenn und aber ein 100% korrektes Ergebnis erwartet, kann es ja nicht auf plausibilität getestet werden, den 0 Länge ist ja auch möglich wenn noch nicht in die Datei geschrieben wurde.....das falsche Ergebniss führte z.B. an anderer Stelle dazu dass ganze Stücklisten "vergessen" wurden. ....

Ich betrache den Schweregrad dieses Fehlers als "Schlimmster möglicher Fehler"

Cu Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von brandelh »

In diesem Sinne ... öffnen und sofort Länge ermitteln ... dann erst später die zweite öffnen.

Workaround um einen Fehler den es nicht geben dürfte.
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von Jan »

Alaska hat da bislang auch noch keinen PDR für angelegt.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Xbase Version 2.0.710

Beitrag von ramses »

Ich Arbeite sehr, sehr viel mit den Funktionen fopen(), fcreate(), fread(), fwrite(), fseek(), FSIZE() usw. .....
Wenn auf diese Funktionen nicht wie bisher ein absoluter Verlass ist kann ich meine Projekte ja auch gleich einstampfen!!!!

Für mich ist jeglicher Workaround für eine Low-Level Funktion nicht diskutabel !!!!!!! Wo kämen wir den da hin?????

Für mich zeigt die Abwicklung dieses Problems wie ich künftig mit xBase++ bezw. dessen Einsatz umgehen werde.
Immer mehr verstehe ich die sinkende Benutzerzahlen und die schlechten Berurteilungen von xbase Programmen bei Risikobewertungen.
Ich habe an anderer Stelle schon einiges darüber geschrieben.

Bei einem so krassen Fehler erwarte ich eigentlich innert kürzester Zeit eine Antwort vom Hersteller ..........

Cu Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
Wolfgang Ciriack
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2932
Registriert: Sa, 24. Sep 2005 9:37
Wohnort: Berlin
Hat sich bedankt: 13 Mal
Danksagung erhalten: 34 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von Wolfgang Ciriack »

Schon mal mit der 721 probiert, vielleicht ist der Fehler ja schon behoben ?
Viele Grüße
Wolfgang
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Xbase Version 2.0.710

Beitrag von ramses »

Ja, soeben versucht und NEIN der Fehler ist NICHT behoben er besteht noch immer.
Valar Morghulis

Gruss Carlo
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Xbase Version 2.0.710

Beitrag von AUGE_OHR »

ramses hat geschrieben:Alle andern File-Copy Metoden haben im Multiuser-Betrieb sporadisch zu Fehlern (Datei nicht kopiert) geführt.
Deshalb dieser Aufwand. Damit gabs dann nie mehr ein Problem. Diese Kopierfunktion war einfach die erste Stelle an der ich das Problem erkannte.
hm ... ein COPY FILE oder CMD COPY läuft, wie die Windows API Function SHFIILE(), unter dem OS() und ist nicht Xbase++ abhängig.


nun hab ich gesehen das du die API GetTempPathA() benutzt. ich gehe davon aus das OS() > XP und TEMP / TMP local liegen.
Frage : verwendest du den Alaska SMB2 "Patch" oder ist TEMP / TMP im Netzwerk freigegeben ?
ramses hat geschrieben:Das FSIZE(Filename) habe ich nicht versucht. Das ist auch keine Alternative.
ich habe es immer nur mit dem Filenamen gemacht und wusste gar nicht mich das man auch ein Handle nehmen kann.
ramses hat geschrieben:FSIZE() muss einwandfrei funktionieren oder die ganze Xbase++ Umgebung ist schlicht unbenutzbar!
JA :!:

allerdings wenn du die Datei geöffnet hast kannst du die Grösse ja auch so ermitteln

Code: Alles auswählen

   // gehe an das Ende -> SIZE   
   nSize := FSeek( nHandle, 0, FS_END)
   // zurück auf Anfang
   FSeek( nHandle, 0,FS_SET) 
ramses hat geschrieben:Ich betrache den Schweregrad dieses Fehlers als "Schlimmster möglicher Fehler"
JA :!:
gruss by OHR
Jimmy
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Xbase Version 2.0.710

Beitrag von ramses »

@Auge_Ohr
Die Funktionen im Testprogramm sind gekürzt. Es ging dabei darum schnell den Fehler zu isolieren. Hubert hat dann noch experimentiert.
Die Funktion MyGetTempPath() habe ich einmal am Programmstart wo auch geprüft wird dass das Temp Verzeichniss auf C:\xxx\ liegt und volle Create/Lese/Schreibrechte haben ist alles OK speichere ich den TempPath in einer Public-Variable oder beende das Programm mit Fehlermeldung.
Ich muss Programme unter Programme(x86) / Temp-Files im Temp-Ordner / Daten auf dem Netz ablegen, das vorgehen hat sich bis jetzt so bewährt.

Ja ich verwende die SMB2 "Patch" Werte und mein Update Installationsprogramm prüft diese bei jedem Update.

Ja es gäbe sicher viele möglichkeiten der Dateilängenabfrage. Nur: Der Zeitpunkt an dem ein Programmierer beginnt Krücken zum Ersatz einer fehlerhaften Low-Level Funktion zu suchen ist der beginn des grossen Chaos und des schnellen Untergangs!!....
Insbesonders da es nach Speicherfehler riecht und niemand weiss ob dies das einige Problem der betroffen DLL ist macht das ganze noch viel schlimmer.
Valar Morghulis

Gruss Carlo
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von brandelh »

Ich habe den Fehler auch im aktuellen Verzeichnis erzeugen können.

Frage hast du das gemeldet ?

Und woher habt ihr 2.00.711 ?? ich sehe nur die 2.00.710 *** Ach nach der Installation von 2.00.710 kam dann auch 2.00.721 ... (Tippfehler verbessert ;-) )
Gruß
Hubert
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Xbase Version 2.0.710

Beitrag von ramses »

Die 2.00.721 ist über die Updatefunktion der Admin-Konsole gekommen.
Ja ich habe es vorgestern morgen gemeldet.
Valar Morghulis

Gruss Carlo
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von Jan »

Hubert,

nicht 711. Seit gestern gib es die 721. Alaska hat das mit seinem neuen automatischen Testsystem offensichtlich massiv angezogen mit den Builds.

Leider fehlt da auch die Beseitigung des Speicherfehlers. Obwohl der ja im Gegensatz zum Problem von Carlo eine PDR hat, und bei Alaska hohe Priorität bekommen hat.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von brandelh »

in der 2.00.703 steht, dass FSize() einen neuen Parameter bekommen hätte, damit man die Größe angeben kann.
In der Hilfe dazu steht nix, Intellihelp findet auch nix, aber die Funktion arbeitet nicht mehr richtig ...
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von brandelh »

ramses hat geschrieben:Für mich ist jeglicher Workaround für eine Low-Level Funktion nicht diskutabel !!!!!!! Wo kämen wir den da hin?????
nun mann kann den Fehler umgehen, indem man die Länge direkt nach dem Öffnen zum ersten Mal ermittelt.
Nicht schön aber man kann damit leben bis der Fehler gefixt wird. Sicher kannst du bei der Version bleiben die den Fehler noch nicht hatte, wenn du sonst nix brauchst.
Gruß
Hubert
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Xbase Version 2.0.710

Beitrag von ramses »

nun mann kann den Fehler umgehen, indem man die Länge direkt nach dem Öffnen zum ersten Mal ermittelt.
Nicht schön aber man kann damit leben bis der Fehler gefixt wird. Sicher kannst du bei der Version bleiben die den Fehler noch nicht hatte, wenn du sonst nix brauchst.
Hubert, du bist aber nicht tatsächlich dieser Ansicht?

Um einen Fehler in einer Funktion eines Produkt's welches sich für den Umstieg von Clipper-Programmen anpreist schlägst du vor für eine Funktion die es seit etwa 1987 gibt, die bis vor kurzem einwandfrei funktioniert hat einen Workaround zu schreiben????
Wohlgemerkt nicht für Probleme einer neuen Funktion, für eine "alteingesessene". Weisst du was das bedeutet? Funktionstest aller Funktionen die seit vielen Jahren entstanden. Hast du mal zusammengezählt wieviel Geld du in den letzten Jahren an Alaska bezahlt hast? Für was????????????????????

So, ich darf jetzt zur Besprechung zu dem Kunden wo ich die fsize() Probleme hatte. (Qualitätssicherung ISO blablabla) Ich bringe da deinen Spruch ....

Cu Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von Jan »

Carlo,

Du tust Hubert hier Unrecht.

Fakt ist, das Alaska da Mist gebaut hat. Und schnellstens für eine Behebung sorgen muß. Was aber sehr sicher nicht von jetzt auf sofort passieren wird.

Aber Fakt ist auch, das Du JETZT Deinen Kunden zufrieden stellen mußt. Und da ist ein Workaround der einzig sinnvolle Weg. Vielleicht ist der Code dann komplizierter, vielleicht auch langsamer. Aber wenigstens läuft die Software wieder fehlerfrei. Und wenn Alaska den Fehler behoben hat, dann kannst Du ja den Workaround wieder raus nehmen.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von brandelh »

Ich sehe das pragmatisch ;-)

Und die Umstellung der Position einer Zeile ... ist ja so dicke nicht.

Es kann natürlich bei deiner Anwendung aufwändiger sein ;-)

Es ist eher nicht zu erwarten, dass Alaska das in 1 oder 2 Tagen bereinigt ... und fehlerfreie Software hab ich selten gesehen :D
Gruß
Hubert
Benutzeravatar
Wolfgang Ciriack
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2932
Registriert: Sa, 24. Sep 2005 9:37
Wohnort: Berlin
Hat sich bedankt: 13 Mal
Danksagung erhalten: 34 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von Wolfgang Ciriack »

Ehe du Hubert Vorwürfe machst, solltest du dich fragen, warum du bei einer Umstellung auf eine neue Version dein Programm nicht ausführlich getestet hast.
Ich weiß, dass dies in allen Bereichen schwierig ist, da du aber diese Funktion elementar benutzt, hätte es dir auffallen müssen.
Viele Grüße
Wolfgang
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Xbase Version 2.0.710

Beitrag von Manfred »

vielleicht sollte man solche Abfragen auch zentralisieren? Dann muß nur an einer Stelle repariert, oder umgebaut werden.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von brandelh »

Hätte man mir gesagt, dass die F-Funktionen, welche ja auf FileHandles basieren plötzlich von der GUI Einstellung
abhängen und nicht mehr auf die richtige Datei zugreifen, hätte ich das nicht geglaubt.

Nun hab ich ja erst auch nicht und es selbst ausprobiert. Ich denke nicht, dass dieser Fehler in einem normalen Programm schnell auffällt.
Es ist einfach unglaublich und so weltfremd als dass man damit rechnet. :wink:
Gruß
Hubert
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Xbase Version 2.0.710

Beitrag von ramses »

Ich wollte niemandem Vorwürfe machen, erst recht nicht Hubert! Ist dieser Eindruck entstanden bitte ich um Entschuldigung.

Ich habe den String "fsize( nHandle" in 237 Zeilen in meinen aktuell verwendeten PRG's gefunden. Diese alle umzuschreiben und zu prüfen ist doch nicht möglich. Bei nur einer Zeile gebe ich Hubert recht, müsste man die Zeilen tauschen. Nur solange sich Alaska zu dem Fehler nicht äussert ist das Vertrauen in die betroffende DLL weg. Und Alaska hat sich nach 2 Tagen noch nicht dazu geäussert.
Ehe du Hubert Vorwürfe machst, solltest du dich fragen, warum du bei einer Umstellung auf eine neue Version dein Programm nicht ausführlich getestet hast.
Das habe ich. Da hast du recht. Gegenfrage: Wieviel Vertrauen hast du jeweils zu Updates? Wie umfangreich und was testest du nach einem Update jeweils? Ich wurde von einem dringenden änderungswunsch überrascht und habe vielleicht zu leichtfertig auch die V. 2.00.710 dazu verwendet.

Ich verwende vorerst die 2.00.685 wieder. Das künfige Verhalten mit Updates muss sicher überdacht werden.

Man könnte fsize() auch ohne weiteres durch folgende Funktion ersetzen:

Code: Alles auswählen

static FUNCTION MyGetFileSizeFromHandle( nHandle )  // Abfrage bis max. 4GB grösse der Dateien möglich. 
local nRet 

     nRet := GetFileSize( nHandle, NIL )
     
     if nret = 0xffffffff
        // Fehlerbehandlung, Fehler hier nicht möglich  --> Log und Programmende 

     endif

return(nRet)

DLLFUNCTION GetFileSize( nHandle, @buffer ) USING STDCALL FROM KERNEL32.DLL

Diese würde nach ersten Tests als Workaround funktionieren. Nur möchte mein Kunde vorerst bei der alten Version bleiben.
Zuletzt geändert von ramses am Do, 28. Jul 2016 13:46, insgesamt 1-mal geändert.
Valar Morghulis

Gruss Carlo
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von brandelh »

Wenn du die Funktion oben nicht static machst, sondern eine normale (MS empfiehlt die EX ) ...

mit dem gleichen Namen wie in der DLL, wird DEINE EIGENE genommen !

Einfacher Test:

Code: Alles auswählen

FUNCTION fSize(nHandle)
   msgbox("MySize")
RETURN 99
zeigt die MsgBox und gibt immer 99 zurück ... dann die richtige rein und gut ist.
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von brandelh »

und hier die richtige Funktion, einfach in deinem Quellcode einbinden und du hast die bis 4 GB OK Variante wieder scharf:

Code: Alles auswählen

#include "dll.ch"
FUNCTION fSize(nHandle)
   LOCAL nRet
   nRet := GetFileSize( nHandle, NIL )
   IF nret = 0xffffffff
      nret := 0
   ENDIF
RETURN(nRet)
DLLFUNCTION GetFileSize( nHandle, @buffer ) USING STDCALL FROM KERNEL32.DLL
Gruß
Hubert
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Xbase Version 2.0.710

Beitrag von ramses »

Hallo Hubert

oder folgende für alle Dateigrössen:

Code: Alles auswählen

#include "ot4xb.ch"

FUNCTION fsize(nHandle)  // Abfrage aller Dateien Grössen  möglich. 
local nRet, oNetR 
     
     oNetR := _Large_Integer():new()
     oNetR:_alloc_()
     nRet := @Kernel32:GetFileSizeEx( nHandle, @oNetR )
     if nRet = 0
        // Fehlerbehandlung: Fehler an dieser Stelle nicht zulässig  --> Log und Programmende 
        ** logEXEerror( "GetFileSizeEx")
        quit
     endif
     make_QWord(oNetR:nLowPart,oNetR:nHighPart,@nRet)
     nRet := int(nRet,0)
     oNetR:_free_(.F.)
     
return(nRet)


BEGIN STRUCTURE _Large_Integer
   MEMBER DWORD nLowPart
   MEMBER DWORD nHighPart
END STRUCTURE
ich bleibe jedoch vorerst bei der 2.00.685.


Cu Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Xbase Version 2.0.710

Beitrag von brandelh »

nRet := int(nRet,0)

soweit ich das weiß, wandelt INT() eine Zahl in eine Integer um, Xbase++ kann nur 32 Bit Integers verwalten und somit müsste es hier ein Problem mit dem Zahlenbereich geben.

wenn Pablo das aber geschrieben hat ist das wohl eine ot4xb Funktion die das besser kann.
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Xbase Version 2.0.710

Beitrag von AUGE_OHR »

ramses hat geschrieben:oder folgende für alle Dateigrössen:

Code: Alles auswählen

     oNetR := _Large_Integer():new()
...
BEGIN STRUCTURE _Large_Integer
   MEMBER DWORD nLowPart
   MEMBER DWORD nHighPart
END STRUCTURE
da war doch was mit 4GB und FileSize() (XbTool) ...

Ja da hatte ich auch eine eigene Function mittels ot4xb jedoch ohne Structure.

Code: Alles auswählen

FUNCTION FileSize(cFile)
LOCAL hFile       := 0
LOCAL lpFileSize  := 0
LOCAL nHighPart   := 0
LOCAL nLowPart    := 0
LOCAL lSetFixed   := .F.

   IF FILE(cFile)

      // get File Handle
      //
      hFile := FOpen(cFile)

      // call API Function
      //
      @Kernel32:GetFileSizeEx( hFile, @lpFileSize )

      // get HI / LOW Part
      //
      nHighPart := hi_dword(lpFileSize)
      nLowPart  := lo_dword(lpFileSize)

      // make Quadword
      //
      MAKE_QWORD(nLowPart,nHighPart,@lpFileSize)

      lSetFixed   := Set( _SET_FIXED ,.F. )
      // round without Decimal
      //
      lpFileSize  := Round(lpFileSize,0)
      Set( _SET_FIXED ,lSetFixed )

      // Close File Handle
      //
      FClose(hFile)

   ENDIF

RETURN lpFileSize
ramses hat geschrieben:ich bleibe jedoch vorerst bei der 2.00.685.
und ich bei der v1.9.355 und meinen native Schnittstellen.
gruss by OHR
Jimmy
Antworten

Zurück zu „Unterschiede Version 1.9 <-> 2.0“