?
Th schrieb:
Du kannst schon im Konstruktor ein 2. Formular aufrufen (oder sonstige beliebige Dinge machen), nur mir schien es so, daß du nicht so viel Ahnung von der Speicherverwaltung hast.
Ich sag es mal so: Ich tue mich schon ein wenig schwer, was Programmierung für Windows angeht. Ich habe C-Progammierung mit einem Borland Compiler unter DOS für DOS gelernt. Selbst als ich meinen ersten Borland Compiler unter Windows hatte, habe ich weiterhin für DOS programmiert. Und ich gebe ehrlich zu, dass zu dieser Zeit Anwendungen unter DOS entstanden sind, die ich mir unter Windows nicht zutrauen würde zu programmieren. So sicher wie ich in DOS bin, was ich mache, so unsicher bin ich unter Windows.
Doch grundlegende Kenntnisse der Speicherverwaltung kann ich natürlich auch unter Windows weiter nutzen. Dazu zählt für mich ganz klar (auch in Zeichen von 4 GB RAM) arbeitsspeicherschonendes programmieren (z.B.: warum int, wenn auch short int möglich ist, warum global, wenn ich die Variable nur lokal benötige?) und natürlich auch alles, was ich irgendwann mal aufmache (z.B.: filestream, Formular) sofort wieder zu schließen, wenn ich es nicht mehr benötige.
Th schrieb:
Bzgl. der Funktion 'execl': du brauchst den Dateinamen(incl. Pfad) nicht doppelt angeben (obiges reicht aus, außer du willst deiner Anwendung noch den eigenen Namen+Pfad als Parameter übergeben, aber das ist wohl unnötig).
Ich hatte diesbezüglich eigentlich in der Hilfe nachgesehen, wie die Funktion aussieht:
int execl (char *path, char *arg0 ..., NULL);
Der Parameter path gibt den Dateinamen des untergeordneten Prozeßes an.
Sämtliche exec-Funktionen müssen zumindest ein Argument an den untergeordneten Prozeß übergeben, nämlich arg0. Dieses Argument enthält per Konvention eine Kopie von path.
Und als Beispiel führt
execl("C:\\Programme\\Office\\msaccess.exe", "C:\\Datenbanken\\Database.mdb");
nur dazu, dass Access geöffnet wird.
Willst Du wirklich die Datenbank aufmachen, muss es
execl("C:\\Programme\\Office\\msaccess.exe", "C:\\Programme\\Office\\msaccess.exe", "C:\\Datenbanken\\Database.mdb");
heißen
Th schrieb:
Außerdem solltest du den Rückgabewert prüfen (nResult, s.o.), denn es kann immer mal Probleme geben...
Yepp, 100% Zustimmung. Mach ich auch noch.
Th schrieb:
Auch solltest du evtl. den Pfad für das Update-Programm nicht fest im Quellcode ablegen (evtl. besser relativ zum eigentlichen Programm angeben, d.h. z.B. "./AccessControlUpdater.exe").
Werde ich wohl nicht hinbekommen, da die Anwendung lokal auf dem Rechner liegt und die "Updater.exe" auf verschiedenen Servern. Jedoch hat jeder PC immer nur einen von diesen Servern eingebunden und das immer unter Q:[...].
Ich möchte die "Updater.exe" auch nicht lokal auf die Rechner legen, weil diese definitiv noch weiterentwickelt werden wird. Wenn Sie aber lokal auf mehreren Rechnern liegt, dann komme ich da nicht mehr ohne weiteres dran.
Und falls ich Änderungen an dieser (durch ein Update) vornehmen möchte, kann ich das dann nicht machen, da die Datei sich ja nicht selber austauschen kann wenn sie läuft.
Überlegung daher:
- Anwendung lokal, "Updater.exe" auf dem Server.
- wenn Update vorhanden, Start der "Updater.exe" über execl
- nach erfolgreichem Start der "Updater.exe" schließt sich die lokale Hauptanwendung selber, was ja in der Natur von execl liegt.
Damit sind alle Dateien der lokalen Hauptanwendung geschlossen und austauschbar. Und eine neue Version der "Updater.exe" kann ich auf dem Server austauschen.
Ich weiß ja nicht, wann ich das nächste Mal auf ein Problem stoße und Eure Hilfe benötige, daher an dieser Stelle schon mal ein gang ganz großes Dankeschön für Eure Unterstützung.
Ich werde auch hin und wieder mal reinsehen, vielleicht kann ich selber ja auch mal jemandem helfen.