erzeugter SpeedButton "sammelt" Mausklicks im deaktivierten Zustand

[Helmi]

Hallo,

ich habe das Problem, dass bei einem selbst erzeugten SpeedButton die Mausklicks "gesammelt" werden, wenn der Button disabled ist.

Erzeugen tu ich den Button so:

Delphi-Quellcode:

  FSpeedButton  := TSpeedButton.Create(HPanel);

  FSpeedButton.Parent         := HPanel;
  FSpeedButton.Enabled        := true;
  FSpeedButton.Visible        := true;
  FSpeedButton.Layout         := blGlyphLeft;
  FSpeedButton.Margin         := -1;
  FSpeedButton.GroupIndex     := 0;
  FSpeedButton.Top            := 0;
  FSpeedButton.Height         := FSpeedButton.Parent.ClientHeight;
  FSpeedButton.AllowAllUp     := false;
  FSpeedButton.Down           := false;
  FSpeedButton.ParentShowHint := true;

  FSpeedButton.OnClick := OnButtonClick;

Setze ich

Delphi-Quellcode:

Enabled := false

und klicke ich dann auf den Button drauf, so passiert erst mal nichts.
Auch das Event wird nicht ausgelöst.
Erst nach

Delphi-Quellcode:

Enabled := true

wird das OnClick-Event so oft ausgelöst, wie ich den Button im deaktivierten Zustand geklickt habe.

An was könnte das liegen und wie kann ich das abstellen?

[himitsu]

Wann wird geklickt und was passiert alles zwischen Disable, Enable und Click?

[Helmi]

geklickt wird nachdem der SpeedButton disabled hat

wobei deine Frage, nach dem was dazwischen passiert, mich zu etwas brachte

Wenn der Button geklickt wird, dann wird dieser gedisabled und danach wird diese Code ausgeführt:

Delphi-Quellcode:

function WinExecAndWait(FileName: string; Visibility: Integer): DWORD;

  procedure WaitFor(processHandle: THandle);
  var
    Msg: TMsg;
    ret: DWORD;

  begin
    repeat
      ret := MsgWaitForMultipleObjects(1, processHandle, false, INFINITE,
                                        QS_PAINT or QS_SENDMESSAGE);
      If ret = WAIT_FAILED then
        exit;

      If ret = (WAIT_OBJECT_0 + 1) then
        begin
          while PeekMessage(Msg, 0, WM_PAINT, WM_PAINT, PM_REMOVE) do
            DispatchMessage(Msg);
        end;
    until ret = WAIT_OBJECT_0;
  end;

var
  zAppName   : array[0..512] of Char;
  StartupInfo: TStartupInfo;
  ProcessInfo: TProcessInformation;

begin
  StrPCopy(zAppName, FileName);
  FillChar(StartupInfo, SizeOf(StartupInfo), #0);
  StartupInfo.cb          := SizeOf(StartupInfo);
  StartupInfo.dwFlags     := STARTF_USESHOWWINDOW;
  StartupInfo.wShowWindow := Visibility;

  If not CreateProcess(nil, zAppName, nil, nil, false, CREATE_NEW_CONSOLE or
                       NORMAL_PRIORITY_CLASS, nil, nil, StartupInfo, ProcessInfo) then
    Result := DWORD(-1)
  else
    begin
      Waitfor(ProcessInfo.hProcess);
      GetExitCodeProcess(ProcessInfo.hProcess, Result);
      CloseHandle(ProcessInfo.hProcess);
      CloseHandle(ProcessInfo.hThread);
    end;
end;

Es wird eine Exe ausgeführt und gewartet, bis diese wieder geschlossen ist

[edit]
auch ohne dem Code passiert das...

[Mavarik]

Also erstmal: 42!

Dann :glaskugel: wenn Du im OnClick (Der Code fehlt uns) direkt den Execute aufrufst... Wann soll der "arme" VCL Mainthread den dann Status ändern usw.

Auch wenn jetzt das Geschrei anfängt: Füge mal für einen Test ein

Delphi-Quellcode:

Application.Processmessages

ein...

Mavarik

[himitsu]

PS: Außer den Grafik-Messages, wird nichts verarbeitet und alles langes in der MessageQueue.
Irgendwann ist der Button wieder aktiviert und rate mal, was dann passiert, wenn danach dann die angesammelten Messages (vorallem der aufgelaufene Klick) dann verarbeitet werden? :angle:

[Perlsau]

Wenn ich das richtig verstanden habe, werden die Messages im Projekt von Helmi deshalb nicht verarbeitet, weil die dazu notwendigen Prozessor-Ressourcen fehlen, sprich: der Prozessor ist anderweitig beschäftigt und arbeitet die Message-Queue nicht ab, weil er nicht auf ein Application.ProcessMessages trifft bzw. weil die Methode, die das Programm gerade durchläuft, im Haupt-Thread der Anwendung stattfindet statt in einem eigenen Thread. Bis die Methode vollständig durchlaufen ist und der Prozessor dann endlich dazu kommt, die angesammelten Messages abzuarbeiten, ist aber der betroffene Button wieder Enabled, so daß die für ihn bestimmten Messages ihn im "aktiven" Zustand (enabled = true) erreichen. Hätten die Messages ihn im "deaktivierten" Zustand (enabled = false) erreicht, wären die Messages damit erledigt (vernichtet, gelöscht oder was auch immer) gewesen.

@himitsu: Ist diese Darstellung soweit korrekt?

[Sir Rufo]

Wenn man das in einem separaten Thread ausführen würde, könnte man sich das ganze mit dem

Delphi-Quellcode:

PeekMessage

sparen und es würde auch nicht diese Seiteneffekte geben.

Der Thread ruft bei Beendigung einen Callback mit dem Ergebnis auf und in diesem Callback kann man den Starus für den Button zurücksetzen und das Ergebnis auswerten.

[Helmi]

Hallo,

Danke für die ganzen Hinweise!

Das Projekt ist etwas komplex.
Die einzelnen Buttons werden abhängig von Textdateien individuell erzeugt und auch deren OnClick-Events sind vom Inhalt her individuell (einstellbar).

Die Buttons selbst sind nochmal in einer Klasse gekapselt - so dass man nicht direkt mit dem Button "spricht", sondern mit der Klasse darüber und die gibt dann dem Button Befehle
(manche Verheiratete dürften diese Struktur von zu Hause kennen :mrgreen:)

Eigenartigerweise hat ein einfaches

Delphi-Quellcode:

Application.ProcessMessages;

vor dem Disablen Abhilfe geschaffen.
Ohne dem werden die Messages gesammelt, mit nicht mehr

[Mavarik]

Zitat:

Zitat von Helmi (Beitrag 1300112)

Eigenartigerweise...

Wieso... Das haben Dir doch "im Prinzip" alle geantwortet...

[Helmi]

Zitat:

Zitat von Mavarik (Beitrag 1300113)

Zitat:

Zitat von Helmi (Beitrag 1300112)

Eigenartigerweise...

Wieso... Das haben Dir doch "im Prinzip" alle geantwortet...

Mysteriös :-)

Ne, hab es schon verstanden warum