![]() |
Der neue FileSplitter ist da
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. :wink: Download: ![]() |
Ach übrigens:
Das Teilen und Zusammmenfügen passiert in Threads. Theoretisch könnte man eine Datei teilen und gleichzeitig eine andere zusammenfügen. Diesen Härtetest haben ich den FileSplitter aber noch nicht unterzogen. :mrgreen: |
Bei mir (Win98 SE) funktionieren deine gesamten Dialoge nicht...
Das ist mir schon bei deinem Crypter aufgefallen, den ich mir wegen den Callbacks runteralden sollte. Gemeint sind die "Datei Öffnen"-Dialoge. Der Info-Button funktioniert (sowohl im FileSplitte rlas auch im Crypter). Ist das so beabsichtigt, daß Win98-User keine Dateien öffnen dürfen? :mrgreen: |
Das liegt daran, dass unser Luckie nicht hören will ... und wir müssen es dann ausbaden. :wink: Tatsächlich benutzt der Gute eine modifizierte Struktur, die unter Win9x dann nicht reagiert.
Das habe ich ihm bei seinem Crypter auch schon vorgehalten. Wenn er stattdessen den Originalrecord von Borland benutzt, gibt´s dieses Problem nicht (mehr). :) |
Mensch Luckie, was machst du denn auch :-P
|
Zitat:
Zitat:
Delphi-Quellcode:
{-----------------------------------------------------------------------------
Procedure : OpenFile - 2003-06-01 03:45:47 modified : 2003-06-01 Author : Michael Puff Purpose : OpenFileDialog for file to split Arguments : None Result : string -----------------------------------------------------------------------------} function OpenFile : string; var ofn : TOpenFilename; Buffer : array[0..MAX_PATH - 1] of Char; begin result := ''; ZeroMemory(@Buffer[0], sizeof(Buffer)); ZeroMemory(@ofn, sizeof(TOpenFilename)); ofn.lStructSize := sizeof(TOpenFilename); ofn.hWndOwner := hApp; ofn.hInstance := hInstance; ofn.lpstrFile := @Buffer[0]; ofn.nMaxFile := sizeof(Buffer); ofn.Flags := OFN_LONGNAMES; { Datei-Öffnen-Dialog aufrufen } if GetOpenFileName(ofn) then result := ofn.lpstrFile; end; |
Zitat:
|
Tja, dann läuft's bei mir aus einem anderen Grund nicht. Ich bitte um Korrektur!
|
So. Probiert noch mal. Ich habe da jetzt was gedreht. Der Code sieht jetzt so aus:
Delphi-Quellcode:
const
OPENFILENAME_SIZE_VERSION_400 : Cardinal = $000004C; function IsNT5OrHigher: Boolean; var ovi: TOSVERSIONINFO; begin ZeroMemory(@ovi, sizeof(TOSVERSIONINFO)); ovi.dwOSVersionInfoSize := SizeOf(TOSVERSIONINFO); GetVersionEx(ovi); if (ovi.dwPlatformId = VER_PLATFORM_WIN32_NT) AND (ovi.dwMajorVersion >= 5) then result := TRUE else result := FALSE; end; {----------------------------------------------------------------------------- Procedure : OpenFile - 2003-06-01 03:45:47 modified : 2003-06-01 Author : Michael Puff Purpose : OpenFileDialog for file to split Arguments : None Result : string -----------------------------------------------------------------------------} function OpenFile : string; var ofn : TOpenFilename; Buffer : array[0..MAX_PATH - 1] of Char; begin result := ''; ZeroMemory(@Buffer[0], sizeof(Buffer)); ZeroMemory(@ofn, sizeof(TOpenFilename)); if IsNT5OrHigher then ofn.lStructSize := sizeof(TOpenFilename) else ofn.lStructSize := sizeof(OPENFILENAME_SIZE_VERSION_400); ofn.hWndOwner := hApp; ofn.hInstance := hInstance; ofn.lpstrFile := @Buffer[0]; ofn.nMaxFile := sizeof(Buffer); ofn.Flags := OFN_LONGNAMES; { Datei-Öffnen-Dialog aufrufen } if GetOpenFileName(ofn) then result := ofn.lpstrFile; end; |
Ich wollte nur einwerfen: die von Luckie vor-kompilierte Version hat das Problem, das tommie bereits erwähnt hat; die Dialoge erscheinen nicht. Das Interessante kommt aber jetzt -
Ich habe den Quellcode zur Ansicht bekommen und habe ihn mit meinem Delphi 5 Pro unter Win98 kompiliert (ohne irgendeine Änderung!). Fazit: die Dialoge erscheinen. :? Jetzt weiß ich auch nicht mehr. |
[OffTopic] @luckie kommentierst du jede Prozedur mit so nem riesen Kopf. Sollte man das machen oder is das einfach nur so?
|
Aaaargh. :twisted: Ich glaube ich steige auf VB um, da kommt man wenigstens nicht so schnell in Versuchung mit er WinAPI direkt zu programmieren.
Aber mich würde mal interessieren, was die Exe jetzt macht, nach dem ich die Strukturgröße für die OS-Versionen getrennt angebe. Wenn das geht, dann hätten wir ja eine Lösung. |
Zitat:
Da ich die GExperts benutze ist das ein Tastendruck und ich brauche nur noch Autor und Zweck ausfüllen und das Änderungsdatum gegebenfalls anpassen. |
Hi Luckie
bei mir läuft alles soweit unter WinXP Home. Ähm könntest du nicht wieder deine alten Buttons machen fand die irgendwie schöner. Ist sicher ansichtssache. Vielleicht wäre eine richtige Fortschrittsanzeige (also nicht nur unten in der statusbar) auch nicht schlecht, muss aber eigentlich auch nicht |
Moin Zusammen,
@Mathias: Hast Du jetzt 98 oder 98 SE, wie tommie-lie? Das manches nicht unter jeder Windows Version so funktioniert wie es von Borland deklariert wurde hatte ich mit ME nämlich auch schon mal (hallo Daniel B ;-) ) Einzige Idee die mir als denkbarer Workaround dazu einfällt, um es gezielt austesten zu können: Die Datenstruktur selber deklarieren, wie's im PSDK vorgesehen ist, statt den Borland Datentyp zu verwenden. Sollte der Effekt bleiben auch noch die Funktion selber importieren, das dann aber C-Like und nicht im Borland Stil. |
Könnte sich mal bitte jemand erbarmen und die Version von 17:19 unter Win98 testen?
|
Moin Christian,
Zitat:
Aber ich hab ja seit 3-4 Tagen Win2000. :mrgreen: //Sorgen Ade :lol: Grüsse, Daniel :hi: |
Ich könnte es morgen in der Schule testen, dort haben wir ein paar Rechner mit Win98. Früher allerdings nicht
|
Zitat:
|
Zitat:
Dass manches nicht immer funktioniert, mag ja sein, aber bei den bisherigen Problemen (speziell waren es irgendwie immer Öffnen- und Speichern-Dialoge von Luckies Programmen :wink:) reichte es bei mir aus, das Programm mit D5Pro unter 98 neu zu kompilieren. Ich erinnere mich, dass ich beim Crypter ein bisschen was verändert habe. ´s ist aber schon ein Weilchen her, darum weiß ich nicht mehr, was. Na egal, jedenfalls liefen die von mir kompilierten (nur teilweise gepatchten) Programme von Luckie dann auch unter XP problemlos und zeigten die Dialoge auch weiterhin an. |
So, wa sich jetzt auch noch mal probiert habe:
Ich habe mir die CommDlg.pas von jemanden schicken lassen, der D5 Enterprise hat und habe damit kompiliert - geht auch nicht. Un dich habe Mathias Version aus meinem Forum probiert - geht auch nicht. Gleich rufe ich bei Borland. :twisted: |
So jetzt habe ich die Nase aber so langsam voll. Unter ME etwas gebastelt bis es lief und dann unter 2000 getestet lief nicht. Unter 2000 wieder gebastelt bis es lief, unter ME getestet, jetzt läuft es da auch. So und welche Version läuft jetzt unter beiden OS? Genau die aller erste wieder, die mit TOpenFilename. Ich weiß echt nicht, was jetzt anders ist, als vorher.
Aaaaaaaaaaaaaaaaaaaaaaaaaah gerade wird mir berichtet das die Exe, die unter ME läuft unter 98SE es nicht tut. Wenn das so weitergeht, bin ich bald ein nervliches Wrack. :twisted: |
tommie-lie hat es gefunden:
Code:
ofn.lStructSize := SizeOf(TOpenFilename) - (SizeOf(DWORD) shl 1) - SizeOf(Pointer);
Jetzt sollte es auch unter 98, ME und 2000 gehen. Bleibt abzuwarten, was XP dazu sagt. |
So Version 4.1 ist draußen. Ich habe doch noch was schnelleres gefunden, als Read- und WriteFile: BlockRead und BlockWrite. Bei großen Dateien (700 MB) ist es nicht so gravierend aber bei kleineren (6 MB) ist es ungefähr doppelt so schnell.
Desweiteren sind noch ein paar Visualisierungen dazugekommen. Link im ersten Post! |
Also bei mir (Windows XP) geht der Opendialog einwandfrei ;-)
|
Zitat:
Und wie gefällt es sonst so? |
Zitat:
Delphi-Quellcode:
Delphi 5 ist zu alt und kennt nur das Standardrecord "TOpenFileName". Ausgehend von den Problemen würde ich dann also vermuten, dass Delphi 6 bereits auf das erweiterte, neue Record zugreifen kann. (s. PSDK)
ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400;
Das PSDK enthält zusätzlich das alte Record mit der Bezeichnung "OPENFILENAME_NT4". Inwieweit Borland das übernommen hat, weiß ich (mangels D6) nicht. Wie dem auch sei, in den Delphi-Tutorials (auch online bei dir im ![]() |
btw: Natürlich funktioniert das Programm (= der Quellcode) jetzt nicht mehr, wenn man nicht Delphi 6 oder 7 hat. Ist ja auch logisch. Wie ich schon schrieb, sind die Versionen vor D6 zu alt und kennen nur das Standardrecord, und durch
Delphi-Quellcode:
bzw.
ofn.lStructSize := SizeOf(TOpenFilename) - (SizeOf(DWORD) shl 1) - SizeOf(Pointer);
Delphi-Quellcode:
werden nun davon noch zwei DWORDs und ein Pointer abgezogen. Damit stimmt die Originalgröße nicht mehr, und die Dialoge erscheinen bei älteren Delphi-Versionen nicht. Du musst dich also tatsächlich an die Idee aus dem Forum halten:
ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400;
Delphi-Quellcode:
oder du probierst dein Glück mal mit dem schon erwähnten "OPENFILENAME_NT4"-Record, sofern es von Borland deklariert wurde.
if(Win2k) or (WinXP) then ofn.lStructSize := sizeof(TOpenFilename)
else ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400; Ja, ich weiß: du hattest das bereits gestern (~17 Uhr) geschrieben. Ich wollte also nur noch mal sagen, dass diese Idee also schon die richtige war. Gerade in Bezug auf ältere Delphi-Versionen. Ich habe sie nur nicht berücksichtigt, weil du mir deinen Quellcode ja zwecks Fehlersuche zur Verfügung gestellt hast. Die von tommie-lie vorgeschlagene "Lösung", pauschal (ohne Versionsprüfung) die Größe zu verringern, halte ich deswegen auch für falsch. |
Moin Mathias,
so man denn die letzen Felder der Struktur nicht braucht, schadet es auch nicht sie wegzulassen. Neuere Versionen von Funktionen "wissen" ja von den verschiedenen Möglichkeiten, die sie dann anhand der übergebenen Strukturgrösse zu unterscheiden vermögen. Die Standardkonstante für die kurze Grösse lautet gemäss PSDK OPENFILENAME_SIZE_VERSION_400, und Borland hat sich bei solchen Konstanten eigentlich immer schön an's PSDK gehalten. @Luckie: Ich hab' ja gesagt: Deklarier Dir die Datenstruktur selber ;-) |
In dem Fall sollte bzw. muss er das sogar tun, weil er den Quellcode ja auch freigibt. Also muss er auch damit rechnen, dass sich jemand den Quellcode unter einer anderen Entwicklungsumgebung als Delphi 6/7 ansieht.
In dem Fall sehe ich mein Delphi 5 als Vorteil an. Alles, was neu ist, habe ich meist nicht. Nehmen wir nur die erweiterten Möglichkeiten der List-View unter Windows XP. Also muss ich den ganzen Kram selbst deklarieren. Veröffentliche ich dann so ein Programm samt Quellcode, dann lege ich auch die entsprechenden Deklarationen bei. So kann ich halbwegs sicher sein, dass das Programm auch bei anderen D5-Usern funktioniert. btw: Konstante ist nicht gleich Record. OPENFILENAME_SIZE_VERSION_400 ist mir bekannt, und das habe ich ja auch erwähnt. Aber es gibt im PSDK noch ein Record namens OPENFILENAME_NT4, das bei lpTemplateName endet und damit der alten Struktur entspricht - oder sagen wir: dem Record, das ich in D5 habe. Wenn Borland das nun ebenfalls übernommen hat (vielleicht als "TOpenFileName_NT4"), kann man es ja auch mal versuchsweise verwenden. |
Moin Luckie,
Zitat:
Zitat:
|
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
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 |
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. |
Ä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:
(man beachte unbedingt die beiden IFDEFs!!!)
typedef struct tagOFN {
// [...] #if (_WIN32_WINNT >= 0x0500) void * pvReserved; DWORD dwReserved; DWORD FlagsEx; #endif // (_WIN32_WINNT >= 0x0500) } OPENFILENAME, *LPOPENFILENAME; 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. |
Zitat:
Zitat:
Zitat:
Zitat:
Delphi-Quellcode:
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.
ofn.lStructSize := SizeOf(TOpenFilename);
Von Unzulänglichkeiten oder gar Zufällen kann also nicht die Rede sein. |
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
|
Noch ein PS:
Zitat:
Delphi-Quellcode:
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 :wink:) Und weil sich 2000 und XP nicht darüber beschweren, wenn du die kürzere Struktur benutzt, werden hier auch die Dialoge angezeigt. :)
sizeof(TOpenFileName)
|
Zitat:
Zitat:
Zitat:
Zitat:
|
Zitat:
Zitat:
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:
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:
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. |
Moin tommie-lie,
Zitat:
Zitat:
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:51 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz