Der neue FileSplitter ist da

[Luckie]

So, die neue Version (4.0) des FileSplitters ist da. Die Dateioperationsroutinen sind noch die alten, aber der Code und das Design wurden etwas überarbeitet.

Wenn die Testphase erfolgreich verlaufen ist, gibt es auch den Source.

Download: FileSplitter (68 KB)

[Luckie]

Moin Luckie,

Zitat von Luckie:

Das hei-, wenn man diesen Code>
ofn.lStructSize := SizeOf(TOpenFilename) - (SizeOf(DWORD) shl 1) - SizeOf(Pointer); Mit einer Delphi-Version kleine D6 kompiliert geht es nicht mehr?

Das dürfte tatsächlich nicht mehr funktionieren, weil dann ja die TOpenFilename Struktur eh' schon 12 Byte kürzer ist.

Zitat von Luckie:

Aber die Version aus meinem Forum hatte ich auch schon mal uind irgend wo hat dass dann wieder nicht geklappt, ich glaube das war dann ME oder so.

Wie schon gesagt, bei ME bin ich auch schon auf Unstimmigkeiten gestossen.

[mirage228]

Zitat von Luckie:

Zitat von mirage228:

Also bei mir (Windows XP) geht der Opendialog einwandfrei

Sei geküßt, Bruder.

Und wie gefällt es sonst so?

die anwendungsoberfläche selbst gefällt mir sehr gut, nur eine kleine Kritik hätte ich: Vielleicht schon feste Größen, wie CD-ROM oder Diskette auswählen können oder halt dann seine eigene Größe eingeben.

also das teilen hat geklappt und ging auch sehr schnell.

nur beim wieder zusammenfügen hatte ich nen Fehler (s.Anhang)
Fehler 6 ist "Das Handle ist ungültig"

EDIT: Das lag wohl daran, dass dein Programm irgendwie den Pfad "D:\\SplinterCellManual.pdf" gewählt hat. Das 2te "\" muss natürlich weg. Wenn ich den Pfad manuell auf diesen Setze (also D:\SplinterCellManual.pdf), dann gehts.

mfG
mirage228

[OrallY]

Ist ein nettes Programm. Klein und vorallem schnell. Ein kleiner Kritikpunkt, ist, dass man das Verzeichnis nicht einfach von Hand eingeben kann oder die Zieldatei. Außerdem wird die Zeile bei einem langen Verzeichnispfad einfach gebrochen und man sieht den Rest nicht mehr. Also würde ich dir eine Editbox ans Herz legen.
Wenn ich "Teile löschen" anklicke, hat das trotzdem keine Wirkung: Die Teile bleiben erhalten.
Wenn man schon eine Datei gesplittet hat und dann eine andere öffnet, wird das Label, in dem die Anzahl der Teile steht, nicht geupdatet. Erst wenn man die Teilzahl verändert oder neu eintippt.
Vielleicht könntest du auch noch eine Drag & Drop funktion einbauen.
Und noch ein kleiner Kritikpunkt: Der große weiße Balken oben bei der Form wirkt ein wenig, hmm, öde. Das erinnert mich immer an die alten "Ignorieren, Abbrechen"-Fehler in Win98. Ansonsten gefällt das Design.

[tommie-lie]

Ähh, nur so als Anmerkung, ich habe ihm auch gesagt, daß er lieber eine Abfrage nach Windows-Version (nicht Compiler!!!) machen sollte, aber nachdem es anscheinend auch unter 2k und XP läuft, weiß ich nicht genau, wie gravierend ein auf die Art und Weise verkürzter Rekord sich auswirken wird.
Und die Begründung liegt nicht in der Delphi-Version, aber nur indirekt. D5 verwendet nämlich mit an Sicherheit grenzender Wahrscheinlichkeit noch die alte Deklaration, während D6 das nicht mehr tut (deswegen hat auch ein Neukompilieren bie mir nichts gebracht). Die neue Deklaration sieht wie folgt aus (Quelle: PSDK, Danke Luckie, sonst hätte ich auch noch das alte *g*):

Code:

typedef struct tagOFN {
// [...]
#if (_WIN32_WINNT >= 0x0500)
  void *        pvReserved;
  DWORD         dwReserved;
  DWORD         FlagsEx;
#endif // (_WIN32_WINNT >= 0x0500)
} OPENFILENAME, *LPOPENFILENAME;

(man beachte unbedingt die beiden IFDEFs!!!)
Macht man also die Abfrage nach der Version genauso wie hier in den IFDEFs, dürfte es keine Probleme geben; nie.
Im Prinzip ist es also die reine Unzulänglichkeit Seitens Delphi5, daß MathiasSimmacks selbstkompilierte Version unter Win98 läuft und reiner Zufall, das sie es noch unter NT5 (also Win2k) tut.

[MathiasSimmack]

Zitat von tommie-lie:

Ähh, nur so als Anmerkung, ich habe ihm auch gesagt, daß er lieber eine Abfrage nach Windows-Version (nicht Compiler!!!) machen sollte, aber nachdem es anscheinend auch unter 2k und XP läuft, weiß ich nicht genau, wie gravierend ein auf die Art und Weise verkürzter Rekord sich auswirken wird.

Das habe ich beschrieben. Wenn du den alten Record nochmals kürzt, dann kann das nicht klappen. Und genau das passiert bei D5, wenn man ohne Versionsprüfung kürzt.

Zitat:

Und die Begründung liegt nicht in der Delphi-Version, aber nur indirekt.

Doch, die Begründung liegt in der Delphi-Version, wie du ja auch selbst nun feststellst:

Zitat:

D5 verwendet nämlich mit an Sicherheit grenzender Wahrscheinlichkeit noch die alte Deklaration, während D6 das nicht mehr tut (deswegen hat auch ein Neukompilieren bie mir nichts gebracht). Die neue Deklaration sieht wie folgt aus (Quelle: PSDK, Danke Luckie, sonst hätte ich auch noch das alte *g*):

Code:

typedef struct tagOFN {
// [...]
#if (_WIN32_WINNT >= 0x0500)
  void *        pvReserved;
  DWORD         dwReserved;
  DWORD         FlagsEx;
#endif // (_WIN32_WINNT >= 0x0500)
} OPENFILENAME, *LPOPENFILENAME;

(man beachte unbedingt die beiden IFDEFs!!!)
Macht man also die Abfrage nach der Version genauso wie hier in den IFDEFs, dürfte es keine Probleme geben; nie.

Das Problem ist, dass D5 eben diese Variablen nicht kennt. Aus gutem Grund stellt Microsoft daher auch die Konstante OPENFILENAME_SIZE_400 zur Verfügung, die diesem Umstand Rechnung trägt. Sie begrenzt die Recordgröße auf lpTemplateName als Maximum. In Delphi benutzt du dafür die Recordgröße des erweiterten Records (D6/7) und ziehst einen Pointer und zwei DWORDs ab.

Zitat:

Im Prinzip ist es also die reine Unzulänglichkeit Seitens Delphi5, daß MathiasSimmacks selbstkompilierte Version unter Win98 läuft und reiner Zufall, das sie es noch unter NT5 (also Win2k) tut.

Nein, das ist Quatsch! Luckie und ich haben uns über das Problem unterhalten, und auf meine Bitte hin hat er mir den Quelltext der Version 4.0 geschickt. Dieser Quelltext enthielt aber lediglich die Angabe:
ofn.lStructSize := SizeOf(TOpenFilename); Ich denke, du weißt wohl selbst, warum es so funktioniert hat - Es ist der Quellcode! Kompiliert Luckie den mit seinem Delphi 6, dann wird bei ihm das erweiterte Record benutzt, und es funktioniert. Kompiliere ich den selben Quellcode mit meinem Delphi 5, dann wird bei mir das alte Record benutzt. Da aber hier noch nichts gekürzt wurde, funktioniert es logischerweise bei mir auch.

Von Unzulänglichkeiten oder gar Zufällen kann also nicht die Rede sein.

[Luckie]

Zitat von OrallY:

Ist ein nettes Programm. Klein und vorallem schnell. Ein kleiner Kritikpunkt, ist, dass man das Verzeichnis nicht einfach von Hand eingeben kann oder die Zieldatei.

Damit vermeide ich, dass man einen ungueltigen Datei oder Pfadnamen eingibt. Aber das koennte man eventuell noch anderen, dann muss ich eben nur auf FileExists bzw. DirExists pruefen.

Zitat:

Außerdem wird die Zeile bei einem langen Verzeichnispfad einfach gebrochen und man sieht den Rest nicht mehr. Also würde ich dir eine Editbox ans Herz legen.

Das liegt daran, dass dein Windows den Static-Style: SS_PATHELLIPSIS nicht kennt. Gibt es erst ab NT und hoeher.

Zitat:

Wenn ich "Teile löschen" anklicke, hat das trotzdem keine Wirkung: Die Teile bleiben erhalten.

In der Listbox? Oder nachhher beim Zusammenfuegen?

Zitat:

Wenn man schon eine Datei gesplittet hat und dann eine andere öffnet, wird das Label, in dem die Anzahl der Teile steht, nicht geupdatet. Erst wenn man die Teilzahl verändert oder neu eintippt.

wird behoben der Herr.

Zitat:

Vielleicht könntest du auch noch eine Drag & Drop funktion einbauen.

Schon drin.

Zitat:

Und noch ein kleiner Kritikpunkt: Der große weiße Balken oben bei der Form wirkt ein wenig, hmm, öde. Das erinnert mich immer an die alten "Ignorieren, Abbrechen"-Fehler in Win98. Ansonsten gefällt das Design.

Diesen Balken haben alle meine kleinen Tools.

[MathiasSimmack]

Noch ein PS:

Zitat von tommie-lie:

Im Prinzip ist es also die reine Unzulänglichkeit Seitens Delphi5, daß MathiasSimmacks selbstkompilierte Version unter Win98 läuft und reiner Zufall, das sie es noch unter NT5 (also Win2k) tut.

Meine o.g. Erläuterungen erklären auch, warum ein mit Delphi 5 kompiliertes Programm dennoch unter 2000/XP funktioniert. Da hätte ich auch gestern schon drauf kommen können. Wenn ich mit dem alten Record arbeite und kompiliere, dann entspricht
sizeof(TOpenFileName) ja ebenfalls der Recordgröße ohne die neuen 12 Bytes, da dieser Wert fest im Programm kompiliert und nicht erst zur Laufzeit anhand des OS bestimmt wird. (Compiler <> Interpreter ) Und weil sich 2000 und XP nicht darüber beschweren, wenn du die kürzere Struktur benutzt, werden hier auch die Dialoge angezeigt.

[OrallY]

Zitat:

Das liegt daran, dass dein Windows den Static-Style: SS_PATHELLIPSIS nicht kennt. Gibt es erst ab NT und hoeher.

Da muss ich dich enttäuschen. Ich besitze WinXP. Ich denke das gilt als "höher".

Zitat:

In der Listbox? Oder nachhher beim Zusammenfuegen?

Bei beiden, wobei ich doch davon ausgehe, dass das erstere ein Feature ist und kein Bug, oder?

Zitat:

Schon drin.

Darf ich fragen wo? Wenn ich ne Datei auf die Form ziehen will, ist nur der schöne "geht nicht"-Cursor zu sehen. Auch bei den Teilen..

Zitat:

Diesen Balken haben alle meine kleinen Tools.

Was es ja auch nicht schöner macht. Aber diese Diskussion hatten wir ja schonmal. Ich geb's auf .

[tommie-lie]

Zitat von MathiasSimmack:

Das habe ich beschrieben. Wenn du den alten Record nochmals kürzt, dann kann das nicht klappen. Und genau das passiert bei D5, wenn man ohne Versionsprüfung kürzt.

Okay, es hörte sich so an, als sei es mein Vorshclag gewesen, das ganze ohne Versionsprüfung laufen zu lassen, und das war es nicht.

Zitat:

Doch, die Begründung liegt in der Delphi-Version, wie du ja auch selbst nun feststellst:

Nein.
Im Prinzip sind es die veralteten Header von Delphi5. würde man die windows.pas (oder in welcher Unit auch immer TOpenFilename stehen mag, bin zu faul zum nachgucken) entsprechend ändern und neu kompilieren, würde es auch so klappen. Es ist also nicht direkt das Delphi dran schuld, sondern nur die veralteten, vorhandenen Header (man beachte das Wort "veraltet", es ist hier vollkommen zurecht am Platze und wird später noch mal genutzt werden)

Zitat:

Zitat:

Im Prinzip ist es also die reine Unzulänglichkeit Seitens Delphi5, daß MathiasSimmacks selbstkompilierte Version unter Win98 läuft und reiner Zufall, das sie es noch unter NT5 (also Win2k) tut.

Nein, das ist Quatsch! Luckie und ich haben uns über das Problem unterhalten, und auf meine Bitte hin hat er mir den Quelltext der Version 4.0 geschickt. Dieser Quelltext enthielt aber lediglich die Angabe:
ofn.lStructSize := SizeOf(TOpenFilename); Ich denke, du weißt wohl selbst, warum es so funktioniert hat - Es ist der Quellcode! Kompiliert Luckie den mit seinem Delphi 6, dann wird bei ihm das erweiterte Record benutzt, und es funktioniert. Kompiliere ich den selben Quellcode mit meinem Delphi 5, dann wird bei mir das alte Record benutzt. Da aber hier noch nichts gekürzt wurde, funktioniert es logischerweise bei mir auch.

Aber es ist trotzdem eine Unzulänglichkeit. Ich weiß jetzt nicht genau, was der Pointer und die beiden DoubleWords für eine Funktion haben (ich hab' nichtmal mehr die Namen im Kopf), aber diese Funktionalität der Struktur ist unter D5 ohne Änderungen nicht nutzbar. Das sehe ich als unzulänglichkeit an, sobald man diese drei Werte benutzen will/muss, und daher verdankt man es dieser Unzulänglichkeit, das es dann auch wieder utner Win98 läuft.
Genauso sieht es mit Win2k und XP aus. Ich weiß nicht, wozu Windows intern die Stukturgrößen nochmal als Parameter übergeben haben will und was es damit anstellt, aber es könnte unter irgendwelchen Umständen mit dieser (zu kleinen!) Strukturgröße zu Fehlern kommen, die mit der richtigen Strukturgröße eben nciht geschehen sind. Es ist also auch reiner Zufall, daß es mit der kleinen (und alten) Struktur auch unter Windows2k und WindowsXP funktioniert, die beiden könnten sich genausogut als untoleranter erweisen.

Zitat:

Von Unzulänglichkeiten oder gar Zufällen kann also nicht die Rede sein.

Doch. Zumindest von meinem Standpunkt aus. Sicherer wäre es natürlich, die Strukturwerte einzeln zu addieren anstatt ein pauschales SizeOf zu verwenden, oder man müsste nochmal per IFDEF die Delphi-Version abfragen.
Fakt ist nunmal, daß etwas, was ich unter D5 normalerweise als Einschränkung oder Fehler bezeichnen würde, dem Programm dazu verhilft, unter Win98 zu laufen.

[Christian Seehase]

Moin tommie-lie,

Zitat von tommie-lie:

Ich weiß nicht, wozu Windows intern die Stukturgrößen nochmal als Parameter übergeben haben will und was es damit anstellt,

Das ist ein in der Windows API übliches Vorgehen, damit die Funktionen erkennen können, welche Version einer Struktur übergeben wird.

Zitat von tommie-lie:

...aber es könnte unter irgendwelchen Umständen mit dieser (zu kleinen!) Strukturgröße zu Fehlern kommen, die mit der richtigen Strukturgröße eben nciht geschehen sind. Es ist also auch reiner Zufall, daß es mit der kleinen (und alten) Struktur auch unter Windows2k und WindowsXP funktioniert,...

Nein, kann es nicht, denn dazu wird ja gerade die Strukturgrösse übergeben, und deshalb funktioniert die kleinere Struktur auch unter W2K/XP. Das hingegen ältere Versionen mit der neuen Struktur auf einen Fehler laufen ist logisch, denn die kennen die längere Variante nicht.
Ich vermute mal, leider kann ich's nicht ausprobieren, das der Aufruf von GetOpenFilename mit der neuen Struktur unter eine älteren Windows Version mit False zurückkehrt und GetLastError 87 liefert.