Hi,

ich arbeite an einer kleinen Dateiverwaltung, welche in leicht abgewandelter Form in der neuen Version meines Multimediaplayers auftauchen wird. Aber es geht vorerst nicht um die integrierte sondern um die selbstständige Variante. Angenommen einem stürzt der Windows Explorer ab, werden alle Fenster die etwas mit diesem zu tun haben geschlossen. Das kann manchmal sehr ärgerlich sein. Daher dachte ich, man könnte mein Programm mehrfach ausführen und wenn eins abstürzt, fällt auch nur ein Fenster weg. Zur schnelleren Auflistung ist es ratsam, eine Liste der Dateiendungen zu erzeugen, deren Icon sich schon in einer Imagelist befinden. Da es verschiedene Ansichten gibt, habe ich zwei Imagelisten und eine Stringlist mit den Dateiendungen. Die Stringlist klingt überflüssig, aber ich denke die Performance von IndexOf sollte den Sinn klarstellen. Da es nun mehrere Programme gibt, wäre es sehr unperformant, wenn jedes Programm seine eigenen Imagelisten usw. enthalten würde. Daher müsste man die beiden Imagelisten und die Stringlist via TIPCStream bereit halten. Dann würde jede Instanz des Programms gleich schnell sein, als wären die ganzen laufenden Programme nur eins. Allerdings frage ich mich, ob das überhaupt so schnell genug wäre: Der Stream muss immer wieder ausgelesen und temporär verarbeitet werden. Kostet das nicht bei vielen Icons extrem viel Zeit ? Ist diese Methode besser als ein einziges Programm ? Oder anders gefragt: Was haltet ihr für sinnvoller ?

Ich würde darauf verzichten für jede Kleinigket einen eigenen Prozess zu starten (verschwendug von Resourcen)

Speichere doch immer die geöffneten Ordner-Pfade und öffne sie bei einem Absturz automatisch wieder.

Oder wie bei Opera oder Firefox: Nach Absturz Frage, ob letzte Sitzung wiederhergestellt werden soll

Das dumme ist, dass die VCL nur aus einem Thread heraus verwendet werden kann. Sonst könntest du einfach für jedes Fenster einen Thread erstellen - das wäre meiner Ansicht nach unabhängig genug.

Problematisch ist, dass du die Imagelisten nicht zwischen zwei Programmen teilen kannst. Die Handles sind nämlich Prozess-relativ.

Zum Teilen von Stringlisten würde ich von TStringlist abraten und stattdessen ein Array von kurzen Strings verwenden, das du über die MMF teilst. Das hat den Vorteil, dass du nicht ständig LoadFromStream aufrufen musst, sondern inline arbeiten kannst. Du musst nur aufpassen, dass das Ganze threadsicher ist.

Der Vorschlag von new32 ist sehr gut, aber wie realisiert man das ? OnDestroy geht denke ich weniger, da OnDestroy auch aufgerufen wird, wenn ein Programm normal beendet wird.

Das mit den Threads wäre wirklich cool, schade dass das nicht geht. Und wieso müsste ich bei einem Stringarray kein LoadFromStream ausführen ? Wie sähe das denn aus ?

Nimm an, dass alle deine Strings maximal 7 Zeichen lang sind - bei Dateiendungen ist das meiner Ansicht nach durchaus praktikabel.

markieren

Delphi-Quellcode:

type
TExtStringArray = array[0..(MaxWord div 8 - 1)] of String[7];
PExtStringArray = ^TExtStringArray;

var ExtStrings: PExtStringArray; Str: TIPCStream;
begin
//initialisieren...

ExtStrings := Str.Memory;
end;

Jetzt kannst du direkt auf ExtStrings zugreifen und musst gar nichts mehr mit Str machen. Das einzige Problem liegt in der Threadsicherheit, aber auch das lässt sich lösen, indem man das Längen-Feld des Shortstrings als Flag missbraucht (0 = leer, andernfalls belegt).

erstelle bei jedem Öffnen eines Ordners einen Eintrag z.B. in einer Textdatei und lösche ihn beim "Schließen" des Ordners.

Ist alles ordnungsgemäß geschlossen worden sollte die Datei beim nächsten Start leer sein, sonst kannst du die noch vorhandenen Einträge erneut öffnen.

Um das Programm nach einem Absturz automatisch neu starten zu lassen musst du einen zweiten Prozess starten, der nur überwacht, ob das eigentliche Programm geschlossen wird (WaitForSingleObject) und dann, jenachdem, ob das Prog. "normal" oder nicht "normal" beendet wurde es neu startet, oder sich selbst beendet.

Dann vielen Dank an euch beide. In meinem Programm kann man sich so gut wie alles einstellen. Daher dachte ich mir, ich baue beide Methoden ein und der Benutzer muss sich entscheiden.

Was ist denn das für eine Vorgehensweise, das ich mir Gedanken über das Programmverhalten mache, wenn es abstürzt? also ich schreib einfach stabile Programme, und spare mir diese Überlegungen. Ich würde die hierfür verschwendete Energie lieber in das Studium der Grundregeln für robiste Software stecken.

Es geht nur um Vorkehrungen, es gibt immer Möglichkeiten ein Programm zum Absturz zu bringen. Genauso wie du in fast jedem Spiel Sachen machen kannst die du nicht sollst. Weil aber Grundvorkehrungen fehlen kannst du diese Lücken nutzen.

Wenn du getrennte Prozesse verwendest, hast du aber trotzdem das Problem mit den nicht identischen GDI-Handles.