Kleines Problem.
Ich verwende diesen Tip aus der CodeLibrary etwas angepasst auf meine Bedürfnisse.

Meine Frage ist wie oft wird die Callback aufgerufen?
Denn mein Dialog hängt kann ihn nicht bedienen trotz WinprocessMessages..

zusammenfalten · markieren

Delphi-Quellcode:

function TBindStatusCallback.OnProgress(ulProgress, ulProgressMax, ulStatusCode: ULONG;
  szStatusText: LPCWSTR): HResult;
var
  szST: string;
begin

  if FTimeouCheck then
  begin
    if GetCurrentTime > FTimeoutValue then
    begin
      Result := E_ABORT;
      szST := 'TimeOut.. no TMDB_backdrop is loaded';
      SendMessage(GetDlgItem(hDlg, ID_DOWNLOADTEXT), WM_SETTEXT, 0, LONG_PTR(szST));
      Sleep(3000);
      SendMessage(hDlg, WM_CLOSE, 0, 0);
      hDlg := 0;
      Exit;
    end;
  end;

   case ulStatusCode of

     BINDSTATUS_CONNECTING:
     begin
       szST := 'Connected to Server ' + szStatusText;
       SendMessage(GetDlgItem(hDlg, ID_DLG_INFOSTATUS), WM_SETTEXT, 0, LONG_PTR(szST));

       if(FUserCancel) then
       begin
         Result := E_ABORT;
         exit;
       end;
     end;

     BINDSTATUS_BEGINDOWNLOADDATA:
       begin
         // reset progressbar ******* hier inkrementiere ich die Value weil BINDSTATUS_DOWNLOADINGDATA nie aufgerufen wird.
         inc(Value, 50);
         ProgressBar.Value := Value;
         SKAERO_InvalidateRect(ProgressBar.Handle, false);
         // show current action
         case Value of
           50:
             szST := 'Downloading TMDB_backdrop';
           100:
             szST := 'Downloading TMD_Poster';
         end;

         SendMessage(GetDlgItem(hDlg, ID_DOWNLOADTEXT), WM_SETTEXT, 0, LONG_PTR(szST));

         // download exit by the user?
         if(FUserCancel) then
           begin
             Result := E_ABORT;
             exit;
           end;
       end;

     BINDSTATUS_DOWNLOADINGDATA:
       begin
         // update progress
         SendMessage(GetDlgItem(hDlg, ID_PROGRESS), PBM_SETPOS, MulDiv(ulProgress, 100, ulProgressMax), 0);

         // download exit by the user?
         if(FUserCancel) then
           begin
             Result := E_ABORT;
             exit;
           end;
       end;

     BINDSTATUS_ENDDOWNLOADDATA:
       begin
         if Value = 100 then
         begin
           SendMessage(hDlg, WM_CLOSE, 0, 0);
           hDlg := 0;
         end;
       end;
   end;

    // message pump
   WinProcessMessages;

   Result := S_OK;
end;

zusammenfalten · markieren

Delphi-Quellcode:

procedure WinProcessMessages;
var
  ProcMsg: TMsg;
begin
  while PeekMessage(ProcMsg, 0, 0, 0, PM_REMOVE) do
  begin
    if (ProcMsg.message = WM_QUIT) then
      Exit;
    TranslateMessage(ProcMsg);
    DispatchMessage(ProcMsg);
  end;
end;

BINDSTATUS_DOWNLOADINGDATA wird auch niemals aufgerufen.
FUserCancel kann ich auch nicht bedienen weil der Dialog hängt.
Gib es da keine bessere Alternative um 2 Images zu laden ?

gruss

Ich kenne mich in dem Bereich jetzt nicht wirklich aus, deine Botschaftenschleife sieht aber etwas komisch/verdächtig aus:

1. Du benutzt PeekMessage statt GetMessage. Dadurch pollst du dauernd statt einfach nur aufgeweckt zu werden wenn eine neue Message da ist

2. Die If Abfrage für WM_QUIT wäre zumindest bei einer GetMessage basierten Lösung m.W. überflüssig. Da würde man nur
while Getmessage do schreiben.

Grüße
TubroMagic

Zitat:

Ich kenne mich in dem Bereich jetzt nicht wirklich aus, deine Botschaftenschleife sieht aber etwas komisch/verdächtig aus:

Hmm.. Du kennst ich nicht wirklich aus möchtest mir aber sagen das meine Messagequeue falsch ist?
Nun denn. Danke.

Sorry.. Hilft mir nicht wirklich weiter.
Schau mal was Application.ProcessMessages; denn so macht.

Ich könnte es auch so auslegen ändert aber nichts daran das mein Dialog hängt.

markieren

Delphi-Quellcode:

if(PeekMessage(msg, hDlg, 0, 0,PM_REMOVE)) then
  IsDialogMessage(hDlg, msg);

Der einzige unterschied ist hier das ich mir

markieren

Delphi-Quellcode:

TranslateMessage(ProcMsg);
DispatchMessage(ProcMsg);

sparen kann.

Zitat:

IsDialogMessage must not be passed to the TranslateMessage or DispatchMessage function.

Nun ich behandle es aber gerne mit.. Deshalb meine Funktion!
Das ich WM_QUIT mit behandle ist für mich so in Ordnung zur Sicherheit.

PS:
Nur zu deiner Information!

zusammenfalten · markieren

Delphi-Quellcode:

[SecurityPermission(SecurityAction.LinkDemand, UnmanagedCode=True)]
function TApplication.ProcessMessage(var Msg: TMsg): Boolean;
var
  Handled: Boolean;
  Unicode: Boolean;
  MsgExists: Boolean;
begin
  Result := False;

  MsgExists := PeekMessage(Msg, 0, WM_MOUSEFIRST, WM_MOUSELAST, PM_REMOVE);

  if MsgExists or PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE) then
  begin
    Unicode := (Msg.hwnd = 0) or IsWindowUnicode(Msg.hwnd);

    if not MsgExists then
    begin
      if Unicode then
        MsgExists := PeekMessageW(Msg, 0, 0, 0, PM_REMOVE)
      else
        MsgExists := PeekMessageA(Msg, 0, 0, 0, PM_REMOVE);
    end;

    if MsgExists then
    begin
      Result := True;
      if Msg.Message <> WM_QUIT then
      begin
        Handled := False;
        if Assigned(FOnMessage) then FOnMessage(Msg, Handled);
        if not IsPreProcessMessage(Msg) and not IsHintMsg(Msg) and
          not Handled and not IsMDIMsg(Msg) and
          not IsKeyMsg(Msg) and not IsDlgMsg(Msg) then
        begin
          TranslateMessage(Msg);
          if Unicode then
            DispatchMessageW(Msg)
          else
            DispatchMessageA(Msg);
        end;
      end
      else
      begin
  {$IF DEFINED(CLR)}
        if Assigned(FOnShutDown) then FOnShutDown(self);
        DoneApplication;
  {$IFEND}
        FTerminate := True;
      end;
    end;
  end;
end;

gruss

Der Unterschied zwischen VCL's Process Message und deiner ist, dass die von Delphi nur dann greift,
wenn dein Programm gerade nichts zu tun hat. Deine läuft in einem Eventhandler immer und solange,
bis deine Anwendung beendet wird.

SOweit ich weiß, sollte in einem Eventhandler jedoch keine Nachrichtenbearbeitung erfolgen, da diese
mitunter Reetranz Probleme verursachen kann.

z. B. im Kontext der ICS Socket Komponenten wird soweit ich mich erinnere immer empfohlen, bloß nicht
Application.ProcessMessages oder ähnliches innerhalb des Handlers aufzurufen. Das kann zum erneuten
Aufruf des Handlers für die selbe Nachricht führen (ich fragte mich zwa schon immer wieso, weil die
Nachricht doch zu dem Zeitpunkt eigentlich schon aus der Warteschlange raus sein sollte, aber es scheint
tatsächlich zu Problemen zu führen).

Zitat:

Der Unterschied zwischen VCL's Process Message und deiner ist, dass die von Delphi nur dann greift,
wenn dein Programm gerade nichts zu tun hat. Deine läuft in einem Eventhandler immer und solange,
bis deine Anwendung beendet wird.

Entschuldige das ist Blödsinn! nicht richtig.

Sie läuft nur solange wie meine Callback aktiv ist und wird auch nur dann aufgerufen.
Und sie soll sicherstellen das andere Messagen weiterhin verarbeitet werden können.
Was nicht in der Callback funktioniert da diese in zu unterschiedlichen Intervallen aufgerufen wird.

Es ist nicht GetMessage sondern PeekMessage.
Im ersten bei GetMessage würde ich dir recht geben diese Queue läuft bis die Anwendung beendet ist.

Zitat:

z. B. im Kontext der ICS Socket Komponenten wird soweit ich mich erinnere immer empfohlen, bloß nicht
Application.ProcessMessages oder ähnliches innerhalb des Handlers aufzurufen. Das kann zum erneuten
Aufruf des Handlers für die selbe Nachricht führen (ich fragte mich zwa schon immer wieso, weil die
Nachricht doch zu dem Zeitpunkt eigentlich schon aus der Warteschlange raus sein sollte, aber es scheint
tatsächlich zu Problemen zu führen).

Würde ich das überhaupt nicht tun würde mein Fenster sich niemals aktualisieren.
Das Problem ist die Callback das sie nicht kontinuierlich aufgerufen wird sondern nur nach einer bestimmten zeit.
Deshalb bekomme ich keinen zugriff auf meinen Dialog.

Zitat:

Das kann zum erneuten Aufruf des Handlers für die selbe Nachricht führen

Wenn es mal so wäre dann würde mein Dialog nicht hängen!

Ich habe es jetzt erstmal so gelöst ändert nichts daran das der Dialog hängt und ich keine Eingaben über den Button tätigen kann
aber so wird der Dialog zumindest geschlossen wenn das TIMEOUT abgelaufen ist.

zusammenfalten · markieren

Delphi-Quellcode:

BindStatusCallback := TBindStatusCallback.Create;
BindStatusCallback.FTimeouCheck := True;
BindStatusCallback.FTimeoutValue := GetCurrentTime + TIMEOUT;

Status := URLDownloadToFileW(nil, Url, FBackdroppath, 0, BindStatusCallback);
//… callback
  if FTimeouCheck then
  begin
    if GetCurrentTime > FTimeoutValue then
    begin
      Result := E_ABORT;
      szST := 'TimeOut.. no TMDB_backdrop is loaded';
      SendMessage(GetDlgItem(hDlg, ID_DOWNLOADTEXT), WM_SETTEXT, 0, LONG_PTR(szST));
      Sleep(3000);
      SendMessage(hDlg, WM_CLOSE, 0, 0);
      hDlg := 0;
      Exit;
    end;
  end;

gruss

Da "man" eh Alles besser weiß, kennt "man" auch den Unterschied zwischen SendMessage und PostMessage, gell?

Warum schreibt "man" nicht endlich in die Signatur, dass "man" non-VCL bevorzugt?


Gibbets hier kein Popcorn-Smiley ?

SCNR

https://www.delphipraxis.net/199075-...log-win10.html
Sorry, falscher Link, meinte den hier:
https://www.delphipraxis.net/199396-...nngemaess.html

Zitat:

Da "man" eh Alles besser weiß

Und.. Was stimmt an meiner Aussage nicht?
Wenn dem so wäre müsste ich hier nichts fragen aber Danke für die Blumen.

Zitat:

auch den Unterschied zwischen SendMessage und PostMessage, gell?

Ja und wo liegt das Problem oder besser was willst du mir sagen.

Zitat:

Sorry, falscher Link, meinte den hier:

Was hat der link (Thread) mit meiner frage zu tun.

Zitat:

Warum schreibt "man" nicht endlich in die Signatur, dass "man" non-VCL bevorzugt?

Warum sollte ich das tun?

Möchtest du jetzt über mich herziehen oder hast du vielleicht auch eine funktionierende Lösung anzubieten?

Du must aber nicht meinen das durch Postmessage die Callback eher aufgerufen wird.
Wenn der Server der an gepinkt wurde keine Rückantwort sendet dann kannst du lange warten bis die Callback aufgerufen wird.
Und das sorgt dann dafür das mein Dialog hängt.

Aber habe eine Lösung oben gepostet mit Timeout das reicht mir erstmal.

gruss

SendMessage wartet (d.h. blockiert) so lange, biss die Nachricht auf der Gegenseite (wer immer das auch ist) bearbeitet wurde.
PostMessage schickt die Nachricht los und kehrt gleich zurück.

Wenn ich's richtig gesehen habe hast du dieses Muster in deinem Code:

SendMessage
Sleep
Sendmessage

Keine Ahnung ob das wirklich die Ursache ist,aber das sieht zumindest auf einen oberflächlichen Blick so aus, als ob
da eigentlich PostMessage hin gehört.

Zitat:

SendMessage wartet (d.h. blockiert) so lange, biss die Nachricht auf der Gegenseite (wer immer das auch ist) bearbeitet wurde.
PostMessage schickt die Nachricht los und kehrt gleich zurück.

Habe dir eine PN geschickt.. will nicht wieder gebannt werden!

Zitat:

Wenn ich's richtig gesehen habe hast du dieses Muster in deinem Code:

Hat seine Richtigkeit und nichts mit meinem Problem zu tun.

gruss