Hallo Delphianer,

vorsicht, es wird ein kleiner Roman, aber, ich versuche so weit es geht Missverständnisse und sicher auch gut gemeinte Vorschläge über Alternativen von vorneherein auszuschließen. Und dazu braucht es eben auch ein paar Zeilen.

Ich habe für meine SW ein Update-Programm, das über ein mit Blowfish gesichertes TCP/IP-Protokoll eine Datenbank-Verbindung zu meinem Update-Server (NexusDB-Server) herstellt, eventuell neuere Dateien herunterlädt, und dann installiert. Der selbe DB-Server (nur eine andere Datenbank) wird für die Bereitstellung der Lizenzen verwendet. Soweit nichts besonderes. Läuft auch seit 2 Jahren prima.

Wenn ich meine SW mit meinem selbst geschriebenen Installationsprogramm installiere, ist der Ablauf (Ausschnitt) wie folgt:

1. Der User gibt die Lizenznummer ein
2. Die Lizenz(datei) wird heruntergeladen
3. Installation wird fortgesetzt

Nach der Installaton wird meine SW mit Admin-Rechten gestartet und die SW ruft dann in festgelegten Zeiträumen das Updateprogramm auf. Das passiert normalerweise nach einer Update-Installation via CD beim ersten Programmstart.

Und nun das eigentliche Problem: Die Firewall blockiert das Updateprogramm natürlich bei der Erstinstallation und nach jeder Aktualisierung. Wir wissen ja, was User alles weg klicken, oder wohin sie "nicht" klicken, wenn sie sollen. Stichwort "Ach ja, die Meldung kommt immer..:"

Der Gedanke ist also, wenn ich bei der Installation die Lizenz abfrage (da passen die User noch richtig auf, weil sie die Lizenz ja installieren wollen/müssen) und anschließend herunterlade, dann habe ich ja zu dem Zeitpunkt schon eine aktive Verbindung und könnte doch in der Zeit wo ich die SW installiere, parallel dazu eventuell vorhandene Updates herunterladen.

- Das sollte ein eigener Thread sein, damit die Installation ungehindert fortgesetzt wird
- Das Installationsprogramm muss den Fortschritt des Downloadvorganges abfragen können.
- Wenn die Installation fertig und der Download noch nicht abgeschlossen ist, sollte auch der Downloadfortschritt angezeigt werden können
- Der Code sollte so "verpackt" sein, dass er auch vom eigentlichen Updateprogramm verwendet werden kann. Im Updateprogramm sind getrennt: Form (das was der User sieht), Logik (der Downloadvorgang, das Ersetzen der vorhandenen Dateien) in einer Unit, und der Datenbankzugriff in einem Datenmodul.

Nun habe ich über Threads schon einiges gelesen, so richtig kapiert hab ich das allerdings noch nicht. Noch dazu gibt's ja - wenn man sich die Beiträge hier so ansieht - auch sehr unterschiedliche und differenzierte Meinungen und Ansichten, wie man Threads einsetzt bzw. damit umgeht. Das macht es für mich nicht einfacher.

Ich bin Autodidakt, kein studierter Informatiker. Damit ich aber bei Problemen reagieren kann, muss ich das Ganze auch "verstehen" können. Darum meine Frage und Bitte nach Vorschlägen und Anregungen. Gerne gegen Bezahlung....in dem Fall bitte PN.

Nicht das ich hier jemandem den Job wegnehmen will, aber Bezahlung wird nicht nötig sein.

Ob Du einen Download aufrufst und warten musst oder es in einen Thread auslagerst ist "erst mal" das Gleiche.

Mit zwei unterschieden:
1. Deine Application läuft mit anderen aufgaben weiter.
2. Du musst in Deiner Download-Procedure Zugriffe auf ein Form oder die VCL syncronisieren. (Bedeutet mit Syncronize eine Procedure aufrufen, die z.B. eine Processbar updatet)

Die eigentliche Frage lauten: An welcher Stelle kommst Du nicht weiter?

Mavarik

Hallo,

genauso einfach hab ich mir das ja vorgestellt...

zusammenfalten · markieren

Delphi-Quellcode:

unit uUpdateThread;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;

type

  TMyUpdateThread = class(TThread)
  protected
    procedure Execute; override;
  end;

  TForm1 = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    procedure FormCreate(Sender: TObject);
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
    FMyUpdateThread: TMyUpdateThread;
    function UpdateStart: boolean;
  end;

var
  Form1: TForm1;

implementation

uses Dat_Glo, // Globales Datenmodul
     Update_Server; // Update-Form

{$R *.dfm}

procedure Execute_INTERACTIVE; // Schnittstelle zur Update-Form in Update_Server.pas
begin
  Application.CreateForm(TFrmUpdate_Server, FrmUpdate_Server); // Update-Form
  FrmUpdate_Server.Execute; // Update durchführen
end;


procedure TMyUpdateThread.Execute;
begin
  Execute_INTERACTIVE;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  UpdateStart;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  FMyUpdateThread := nil;
end;

function TForm1.UpdateStart: boolean;
begin
  Result := true;
  FMyUpdateThread := TMyUpdateThread.Create(True);
  try
    FMyUpdateThread.FreeOnTerminate := True; // Gibt sich selber frei
    FMyUpdateThread.Resume; // Start
  except
    on E:Exception do begin
      Result := false;
      ShowMessage(E.Message);
    end;
  end;
end;

end.

Und jetzt scheitert es an der Synchronisierung. Also wie bekomme ich mit, wie weit der Download gerade ist (der Stand des Progressbar in FrmUpdate_Server)

Außerdem ist mir nicht klar, wann der Thread "vollkommen" fertig ist, damit ich FrmUpdate_Server wieder freigeben kann.

OK! Erst mal in einem Thread kein FormCreate!

Der eigentlich download muss in den Thread...
Es gibt ein nettes Beispiel für Anonyme Threads.
Das Beispiel zeigt Dir auch direkt den Sync-Aufruf für Process & Ende...

Mavarik

Hallo,

erst mal vielen Dank für deine Bemühungen. Anonymer Thread bedeutet doch, dass die darin erstellten Objekte nicht geshared werden? Hmmmm....bedeutet das, dass ich dann außerhalb des Threads auf die Eigenschaften der Form zugreifen kann, also beispielsweise den Status des Progressbar abfragen? Weil ich die Form ja auch außerhalb des Thread erstellt habe. Das wäre ja einfach, dann müsste ich nur noch ein paar properties einbauen. Aber dann muss doch der Thread irgendwie die Form aktualisieren...oder stehe ich jetzt total auf dem Schlauch.

Hast du mal bitte einen Link auf das obengenannte Beispiel? Hier habe ich unter "Anonyme Threads" nichts prickelndes gefunden.

[OT]
Auch wenn du es nicht hören willst, ich sage es trotzdem (nicht das nachher noch jemand sagt, warum das keiner gesagt hat, und ich mir dann denke, warum hast du das denn nicht einfach gesagt ...):

Wenn du den Krams umstellst auf

• Kommunikation per HTTP(S) (löst die Firewall-Problematik)
• Setup-Programm mit InnoSetup (oder wer auch immer) (löst die Nachlade-Problematik)

dann hast du diese ganzen Probleme nicht mehr und du beschreitest alte, bewährte und funktionierende Trampelpfade.

Aber du möchtest es ja nicht hören ...
[/OT]