Xbase Version 2.0.710
Moderator: Moderatoren
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Xbase Version 2.0.710
@Hubert
INT() schneidet doch nur die nach dem Komma Stellen weg. Auch mit grössen Zahlen als 4GB
In meinem BSP. ist die Null überzählig, habe zuerst round() verwendet --> nRet := int( nRet )
Ohne das int() war der rückgabewert z.B. 1000.00
INT() schneidet doch nur die nach dem Komma Stellen weg. Auch mit grössen Zahlen als 4GB
In meinem BSP. ist die Null überzählig, habe zuerst round() verwendet --> nRet := int( nRet )
Ohne das int() war der rückgabewert z.B. 1000.00
Valar Morghulis
Gruss Carlo
Gruss Carlo
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Xbase Version 2.0.710
Letzte Neuigkeiten:
Alaska bestätigt meinem Testprogramm unterschiedliches Verhalten mit den letzten Xbase Versionen. Es wird "baldmöglichst" angesehen.
Was das wohl bedeutet ....
Alaska bestätigt meinem Testprogramm unterschiedliches Verhalten mit den letzten Xbase Versionen. Es wird "baldmöglichst" angesehen.
Was das wohl bedeutet ....
Valar Morghulis
Gruss Carlo
Gruss Carlo
- brandelh
- Foren-Moderator
- Beiträge: 15699
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 68 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
Zu meiner größten Verwunderung muss ich feststellen, dass sowohl INT() als auch ROUND() scheinbar eine Integer korrekt zurückgeben die den Wertebereich der 32 Bit Integer überschreitet:
fsizeX1(nHandle) mit INT()
fsizeX2(nHandle) mit ROUND()
fsizeX3(nHandle) ohne dies wird ,00 angezeigt => keine INT
Mein Problem ist der Datenbereich:
Long-integer 32 bits (4 bytes), signed => -2,147,483,648 to 2,147,483,647
Double-word 32 bits (4 bytes), unsigned => 0 to 4,294,967,295
beides dürfte eine Länge von 8.309.375.402 nicht anzeigen können. Da es aber auch mit der 1.90.355 sauber angezeigt wird,
bleibt nur die Vermutung, dass intern schon mit QUAD-Integers gerechnet wird, aber das hätten die doch gesagt oder ?
Quad-integer 64 bits (8 bytes), signed => -9.22*10^18 to +9.22*10^18
Hier mal die Ausgabe (PowerBasic) was passiert wenn man den Zahlenbereich überschreitet (in letzter Spalte wird der zu hohe Wert in die Var gedrückt)
Code: Alles auswählen
#include "fileio.ch"
procedure main
#if .f.
local cFileName := "verybig.txt"
local nSizeExPl := 4154687701
local cSizeExPl := " 4.154.687.701"
local nSizeExPl := 8309375402
local cSizeExPl := " 8.309.375.402"
local nSizeExPl := 8309375402*10
local cSizeExPl := " 83.093.754.020"
#endif
#if .f.
local cFileName := "DAT4GB.txt"
local nSizeExPl := 4154687701
local cSizeExPl := " 4.154.687.701"
#endif
#if .t.
local cFileName := "DAT8GB.txt"
local nSizeExPl := 8309375402
local cSizeExPl := " 8.309.375.402"
#endif
#if .f.
local cFileName := "DAT80GB.txt"
local nSizeExPl := 8309375402*10
local cSizeExPl := " 83.093.754.020"
#endif
local nQuelle, nZiel, nBytes, nSize, cBuffer, nReadByte, x, nReadBytes, nCopyBytes
local nDauer
cls
nDauer := seconds()
set alternate to TestBigLog.txt
set alternate on
nBytes := 4096
cBuffer := space(nBytes)
?
?
?
? "Test der low level file Funktionen", time()
? " Xbase++ Version: ",Version()+"."+Version(3)
? cFileName
? "Größe laut Explorer: ", transform(nSizeExPl,"999,999,999,999"), " (numerisch)"
? "Größe laut Explorer: ", cSizeExPl, " (string)"
? "Größe laut FSize(c): ", transform(FSize(cFileName),"999,999,999,999"), " (Dateiname)"
nQuelle := FOpen( cFileName , FO_READ )
nSize := FSeek( nQuelle, 0 , FS_END ) // gehe zum Ende
? "Größe laut FSEEK(): ", transform(nSize, "999,999,999,999") , " (numerisch)"
? "Größe laut FSize(h): ", transform(FSize(nQuelle),"999,999,999,999") , " (mit filehandle)", FSize(nQuelle)
? "Größe laut FSizeX1(h): ", transform(FSizeX1(nQuelle),"999,999,999,999"), " (mit filehandle)", FSizeX1(nQuelle)
? "Größe laut FSizeX2(h): ", transform(FSizeX2(nQuelle),"999,999,999,999"), " (mit filehandle)", FSizeX2(nQuelle)
? "Größe laut FSizeX3(h): ", transform(FSizeX3(nQuelle),"999,999,999,999"), " (mit filehandle)", FSizeX3(nQuelle)
nSize := FSize(nQuelle)
? "Größe laut FSize(n): ", transform(nSize, "999,999,999,999"), " (über Variable)"
? "Wieder am Anfang: ", FSeek( nQuelle, 0 , FS_SET ) // gehe zum Anfang
nBytes := 4096
cBuffer := space(nBytes)
nZiel := FCreate( "c:\temp\NeueDatei.TXT", FC_NORMAL )
IF nZiel == -1
? "Fehler beim Erzeugen der Datei:", FError()
ELSE
x := 1
nReadBytes := 0
nCopyBytes := 0
do while nBytes > 0
if x > 100
@ 1, 40 say "gelesen: "+transform(nReadBytes, "999,999,999,999")
@ 2, 40 say "kopiert: "+transform(nCopyBytes, "999,999,999,999")
x := 1
else
x++
endif
nBytes := FRead(nQuelle, @cBuffer, len(cBuffer))
nReadBytes += nBytes
if FError() > 0
?
? "LESEN - FError() = ",FError()
?
exit
endif
nBytes := FWrite(nZiel, @cBuffer, nBytes)
nCopyBytes += nBytes
if FError() > 0
?
? "SCHREIBEN - FError() = ",FError()
?
exit
endif
enddo
ENDIF
?
? "am Ende nochmal 1. Filehandle abfragen:"
?
? "Größe laut FSize(h): ", transform(FSize(nQuelle),"999,999,999,999") , " (mit filehandle)", FSize(nQuelle)
? "Größe laut FSizeX1(h): ", transform(FSizeX1(nQuelle),"999,999,999,999"), " (mit filehandle)", FSizeX1(nQuelle)
? "Größe laut FSizeX2(h): ", transform(FSizeX2(nQuelle),"999,999,999,999"), " (mit filehandle)", FSizeX2(nQuelle)
? "Größe laut FSizeX3(h): ", transform(FSizeX3(nQuelle),"999,999,999,999"), " (mit filehandle)", FSizeX3(nQuelle)
FClose( nQuelle )
FClose( nZiel )
@ 1, 40 say "gelesen: "+transform(nReadBytes, "999,999,999,999")
@ 2, 40 say "kopiert: "+transform(nCopyBytes, "999,999,999,999")
nDauer := seconds() - nDauer
? "Gelesen: ",transform(nReadBytes, "999,999,999,999")
? "Kopiert: ",transform(nCopyBytes, "999,999,999,999")
?
? time()," Dauer: ",nDauer / 60
set alternate off
set alternate to
wait
return
#include "ot4xb.ch"
FUNCTION fsizeX1(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)
FUNCTION fsizeX2(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 := round(nRet,0)
oNetR:_free_(.F.)
return(nRet)
FUNCTION fsizeX3(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 := round(nRet,0)
oNetR:_free_(.F.)
return(nRet)
BEGIN STRUCTURE _Large_Integer
MEMBER DWORD nLowPart
MEMBER DWORD nHighPart
END STRUCTURE
fsizeX2(nHandle) mit ROUND()
fsizeX3(nHandle) ohne dies wird ,00 angezeigt => keine INT
Mein Problem ist der Datenbereich:
Long-integer 32 bits (4 bytes), signed => -2,147,483,648 to 2,147,483,647
Double-word 32 bits (4 bytes), unsigned => 0 to 4,294,967,295
beides dürfte eine Länge von 8.309.375.402 nicht anzeigen können. Da es aber auch mit der 1.90.355 sauber angezeigt wird,
bleibt nur die Vermutung, dass intern schon mit QUAD-Integers gerechnet wird, aber das hätten die doch gesagt oder ?
Quad-integer 64 bits (8 bytes), signed => -9.22*10^18 to +9.22*10^18
Hier mal die Ausgabe (PowerBasic) was passiert wenn man den Zahlenbereich überschreitet (in letzter Spalte wird der zu hohe Wert in die Var gedrückt)
Code: Alles auswählen
DAT4GB.txt Byte: 4154687701 4154687701
DAT8GB.txt Byte: 8309375402 4014408106
DAT80GB.txt Byte: 83093754020 1489375396
Fertig, Taste drücken
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Xbase Version 2.0.710
Unter "Data Types and Literals" steht:
Numeric values are handled within Xbase++ in the IEEE 64 bit format for floating point numbers. This provides a range for calculations of 10 to the power of -307 to 10 to a power of +308. The binary representation of a floating point number yields a 16 decimal digit precision.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- brandelh
- Foren-Moderator
- Beiträge: 15699
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 68 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
ja für die Fließkommazahlen ist das schon immer so, aber für die Beschleunigung werden intern Integers als Integer abgelegt (Bei Clipper war das nicht so),
eine Schleife mit einer x := 1 ist schneller als mit Kommazahlen (x := 1.00) --- wobei der Unterschied heute mit den Matcos und hochgezüchteten Prozessoren kaum ins Gewicht fallen dürfte.
Ich ging davon aus, dass diese interne Integer Unterstützung auf 32 Bit Integer begrenzt ist, aber offensichtlich kann Xbase++ mit größeren Werten auch umgehen.
Schon die 1.82 konnte, wie ich gerade geprüft habe, mit den lowlevel file Funktionen Dateien über 4 GB verarbeiten, hatte aber bis 1.90.355 einen Fehler mit FSeek() sobald 4 GB überschritten wurden.
eine Schleife mit einer x := 1 ist schneller als mit Kommazahlen (x := 1.00) --- wobei der Unterschied heute mit den Matcos und hochgezüchteten Prozessoren kaum ins Gewicht fallen dürfte.
Ich ging davon aus, dass diese interne Integer Unterstützung auf 32 Bit Integer begrenzt ist, aber offensichtlich kann Xbase++ mit größeren Werten auch umgehen.
Schon die 1.82 konnte, wie ich gerade geprüft habe, mit den lowlevel file Funktionen Dateien über 4 GB verarbeiten, hatte aber bis 1.90.355 einen Fehler mit FSeek() sobald 4 GB überschritten wurden.
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
Alaska hat dazu den PDR 6805 erstellt.
Jan
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15699
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 68 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
und sie kennen keinen Workaround ?
Nun wir schon
1. Vor fCreate() die Datei löschen !
2. Die Funktionen oben im Quellcode einkompilieren
Nun wir schon
1. Vor fCreate() die Datei löschen !
2. Die Funktionen oben im Quellcode einkompilieren
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12911
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Xbase Version 2.0.710
ich fürchte Alaska hat es noch gar nicht kapiert ...
Das Alaska kein Hotfix liefern kann (?), wo wir doch die Läsung haben, ist schon ziemlich erbärmlich ...
das FSize 0 ergibt bei einer Datei die nicht existiert ist doch nicht das Problem sondern wenn die Datei existiert auch 0 liefertPDR 6805 hat geschrieben:The function FSize() returns zero after a function was called for which
the Windows system set an error state.
The following sniplet illustrates the coding pattern which results
in an error.Code: Alles auswählen
=========================== snip ============================ // Open a file nhandle1 := fopen(sName1,FO_READ+FO_SHARED) // Call FCreate() for a file that does already exist nhandle2 := fcreate(sName2) // PDR 6805: FSize returns zero FSize( nHandle1 ) // -> 0 =========================== snap ============================
Das Alaska kein Hotfix liefern kann (?), wo wir doch die Läsung haben, ist schon ziemlich erbärmlich ...
gruss by OHR
Jimmy
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15699
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 68 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
Ich denke du hast das falsch verstanden.
FCREATE() erzeugt einen internen Fehlercode (API Ebene) und danach zeigt FSIZE() 0 an.
Ob ich das in meinem Beispiel auch mache weiß ich gar nicht.
FCREATE() erzeugt einen internen Fehlercode (API Ebene) und danach zeigt FSIZE() 0 an.
Ob ich das in meinem Beispiel auch mache weiß ich gar nicht.
Gruß
Hubert
Hubert
- brandelh
- Foren-Moderator
- Beiträge: 15699
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 68 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
Ich habe das Beispiel nun um ein erase (cDFile) erweitert und kein Fehler tritt mehr auf.
Alaska hat das Problem besser durchschaut, als wir davor. Ich dachte sie haben ein Problem mit den Handles.
Alaska hat das Problem besser durchschaut, als wir davor. Ich dachte sie haben ein Problem mit den Handles.
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
Alaska hat einen Workaround veröffentlicht. Aber den PDR noch nicht als gelöst geschlossen.
Jan
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
Jetzt ist auch der PDR geschlossen. Die Jungs haben da mal richtig schnell reagiert.
Jan
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Xbase Version 2.0.710
@Jan
"Schnell?" Kommt drauf an wann "er" verteilt wird. Bis jetzt noch nicht. Warten wir mal ab ......
"Schnell?" Kommt drauf an wann "er" verteilt wird. Bis jetzt noch nicht. Warten wir mal ab ......
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
Hallo Karl,
ja klar. Aber wichtig ist doch erstmal, das der PDR überhaupt gefixt ist. Meiner, der hier massive Probleme bereitet, ist das auch nach mehreren Wochen nicht, trotz persönlicher Zusicherungen.
Aber wenn das so geht wie die letzten Monate, dann sollte Dein Fix wohl spätestens Anfang September rauskommen.
Jan
ja klar. Aber wichtig ist doch erstmal, das der PDR überhaupt gefixt ist. Meiner, der hier massive Probleme bereitet, ist das auch nach mehreren Wochen nicht, trotz persönlicher Zusicherungen.
Aber wenn das so geht wie die letzten Monate, dann sollte Dein Fix wohl spätestens Anfang September rauskommen.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Xbase Version 2.0.710
@Jan
Hallo Jan, ich ziehe eigentlich die Südländische Version meines Names vor, die andere steht nur auf dem Papier
es ist nicht "mein" Fix.
Cu Carlo
Hallo Jan, ich ziehe eigentlich die Südländische Version meines Names vor, die andere steht nur auf dem Papier
es ist nicht "mein" Fix.
Ich sehe das anders: Kommt eine neue Funktion "auf den Markt" ist es noch lange nicht so schlimm wenn diese während den ganzen Entwicklungs- Test- und Roll- Out Phasen Probleme bereitet. Ein Desaster ist es hingegen wenn eine Funktion nach Jahren einwandfreier Funktion plötzlich nicht mehr korrekt funktioniert. ... Krass. Grösst möglicher Fehler .......Meiner, der hier massive Probleme bereitet,
Cu Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- brandelh
- Foren-Moderator
- Beiträge: 15699
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 68 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
mit der gerade installierten Version 2.00.726 (die deutsche Version dauerte wohl 2 Tage länger) ist der Fehler behoben.
Gruß
Hubert
Hubert
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2936
- 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
Welche deutsche Version, es gibt keine deutsche Version mehr, ist alles integriert.
Viele Grüße
Wolfgang
Wolfgang
- brandelh
- Foren-Moderator
- Beiträge: 15699
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 68 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
Ich habe deutsche Menüs, deutsche Grundeinstellungen und irgendwann nach Jans Hinweis vom englischen auf den deutschen Installationspfad gewechselt:
xpp-prof.20-00-575.en.msi // nach dem gewechselt auf ...
...
xpp-prof.20-00-623.de.msi // mit manuellem Update die DE angefordert.
...
xpp-prof.20-00-726.de.msi // nun wird automatisch die DE angeboten.
und im downloadbereich kann man mit "deutsch" oder "englisch" auch die Sprache wählen, wenn beide angeklickt sind gibt es alle zur Auswahl.
Möglich dass die das intern nun so geregelt haben, dass alles über einen Prozess automatisch gesteuert wird aber ich habe eine deutsche Version mit englischer Hilfe
xpp-prof.20-00-575.en.msi // nach dem gewechselt auf ...
...
xpp-prof.20-00-623.de.msi // mit manuellem Update die DE angefordert.
...
xpp-prof.20-00-726.de.msi // nun wird automatisch die DE angeboten.
und im downloadbereich kann man mit "deutsch" oder "englisch" auch die Sprache wählen, wenn beide angeklickt sind gibt es alle zur Auswahl.
Möglich dass die das intern nun so geregelt haben, dass alles über einen Prozess automatisch gesteuert wird aber ich habe eine deutsche Version mit englischer Hilfe
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
Hallo Thomas,
die wird lt. Aussage von Steffen auf den Xbase-Tracks 2015 in Frankfurt allerspätestens im 1. Quartal 2016 (kein Typo!) lieferbar sein.
Jan
die wird lt. Aussage von Steffen auf den Xbase-Tracks 2015 in Frankfurt allerspätestens im 1. Quartal 2016 (kein Typo!) lieferbar sein.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2829
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 97 Mal
- Danksagung erhalten: 13 Mal
Re: Xbase Version 2.0.710
Hat Steffen auch was drüber gesagt, ob deren Zeitmaschine irgendwann in den Handel kommt? 2014 eventuell?
Liebe Grüsse aus der Eifel,
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
- brandelh
- Foren-Moderator
- Beiträge: 15699
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 68 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
Ich bin ja gar nicht so anspruchsvoll, mir würde es schon reichen wenn die englische Hilfe vollständig wäre
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Xbase Version 2.0.710
Hallo zusammen,
Ja, tatsächlich mit der 2.00.726 ist das FSIZE() Problem beseitigt.
Gerade etwa 1 Monat hat es gedauert .....
Mann/Frau muss daraus seine Lehren / Kosequenzen ziehen, ist es doch ganz einfach:
a) Man lebt mit all den Sorgen: Fehlende dt. Hilfe, das "Zeitmaschinen-Problem" von Georg und alles andere was fehlt usw. und uns belastet..... Mann/Frau muss einfach ein "Sorgenkonzept haben" ....
b) Wechsel zu einer Anderen Sprache
c) Pensionierung / Umschulung oder sonst etwas womit "Mann/Frau" die Sorgen aus dem eigenen Blickfeld beseitigt
Cu Carlo
Ja, tatsächlich mit der 2.00.726 ist das FSIZE() Problem beseitigt.
Gerade etwa 1 Monat hat es gedauert .....
Mann/Frau muss daraus seine Lehren / Kosequenzen ziehen, ist es doch ganz einfach:
a) Man lebt mit all den Sorgen: Fehlende dt. Hilfe, das "Zeitmaschinen-Problem" von Georg und alles andere was fehlt usw. und uns belastet..... Mann/Frau muss einfach ein "Sorgenkonzept haben" ....
b) Wechsel zu einer Anderen Sprache
c) Pensionierung / Umschulung oder sonst etwas womit "Mann/Frau" die Sorgen aus dem eigenen Blickfeld beseitigt
Cu Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Xbase Version 2.0.710
Carlo,
so sehr ich Deinen Ärger auch verstehen kann (solch ein Fehler sollte einfach nicht passieren) - was wäre denn die Alternative?
a) Naja, das machen wir ja alle mehr oder weniger. Schon seit Jahren. Und die Meisten von uns kommen da mehr oder weniger gut mit klar.
b) Was würde das denn bringen? Dein Fehler ist innerhalb eines Monats von Alaska beseitigt und freigegeben worden - welche Sprache schafft denn sowas? Bevor hier einer rummosert: Mir ist bewußt, das Alaska nicht immer so schnell ist. Aber hier hat es nun einmal geklappt, genau wie mit "meinem" Fehler. Und das muß ich einfach positiv anerkennen.
c) Das nehm ich Dir nicht wirklich ab. Ich denke, das war eher eine rethorische Frage, um die Auflistung etwas zu vervollständigen.
Jan
so sehr ich Deinen Ärger auch verstehen kann (solch ein Fehler sollte einfach nicht passieren) - was wäre denn die Alternative?
a) Naja, das machen wir ja alle mehr oder weniger. Schon seit Jahren. Und die Meisten von uns kommen da mehr oder weniger gut mit klar.
b) Was würde das denn bringen? Dein Fehler ist innerhalb eines Monats von Alaska beseitigt und freigegeben worden - welche Sprache schafft denn sowas? Bevor hier einer rummosert: Mir ist bewußt, das Alaska nicht immer so schnell ist. Aber hier hat es nun einmal geklappt, genau wie mit "meinem" Fehler. Und das muß ich einfach positiv anerkennen.
c) Das nehm ich Dir nicht wirklich ab. Ich denke, das war eher eine rethorische Frage, um die Auflistung etwas zu vervollständigen.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.