In virt. Meth. wird stat. Meth. aufgerufen, diese Verdecken?

[APP]

Hallo,
Ich möchte verhindern, dass ein Modales Fenster unter bestimmten Umständen geschlossen wird.
[EDIT] Das Programm soll aber weiterlaufen, auch wenn das Fenster geöffnet bleibt. [/EDIT]

(Siehe auch Thread)
Dort Überschrieb ich die Methode ShowModal, diese Lösung ist aber nicht sehr elegant.

Daher untersuchte ich die Methode ShowModal etwas genauer:

in der

Delphi-Quellcode:

function TCustomForm.ShowModal: Integer;
var
...
begin
...
  try
    Show;
    try
...
    finally
      Hide;   // <---------------------------------
    end;
  finally
...
  end;
end;

befindet sich u.a. der Aufruf von Hide, den ich Überschreiben wollte.

Hide ist aber eine statische Methode:

Delphi-Quellcode:

procedure TCustomForm.Hide;
begin
  Visible := False;
end;

Wenn ich nun folgendes schreibe

Delphi-Quellcode:

TYPE
   TForm3 = CLASS(TForm)
   PRIVATE
      FDebugMode: Boolean;
   PUBLIC
      PROCEDURE Hide;                             // Static, d.h. nicht Override-bar
      PROPERTY DebugMode: Boolean READ FDebugMode WRITE FDebugMode;
   END;

PROCEDURE TForm3.Hide;
BEGIN
   IF DebugMode AND (fsModal IN self.FormState) THEN
   ELSE
      Visible := False;                           // Original-Code
END;

wird nach

Delphi-Quellcode:

PROCEDURE TForm1.Button2Click(Sender: TObject);
VAR
   aDebugForm                      : TForm3;
BEGIN
   aDebugForm := TForm3.Create(self);
   aDebugForm.DebugMode := TRUE;
   aDebugForm.Showmodal; // Hier gibt es ein "Hide" 
END;

trotzdem TCustomForm.Hide und nicht "mein" Hide aufgerufen,
kann ich das irgendwie verhindern (ausser das ich die VCL patche) ?

p.s. Mir ist klar das dieses Verhalten die Regeln der OOP befolgt (zumindest jene die mir geläufig sind), aber trotzdem: Es muß doch noch einen anderen Weg geben, oder?

[MrSpock]

Hallo App,

wie du ja selbst schon gesagt hast: Hide ist eine statische Methode und wird deshalb "früh gebunden", soll heißen, die Adresse der Funktion wird schon im Comiliervorgang festgelegt und sie hat keinen Eintrag in der VMT (virtuellen Methoden Tabelle). Es kann dir deshalb (außer dem Patchen von VCL) nicht gelingen, dass dein Hide aufgerufen wird. Natürlich könntest du versuchen eine neue Komponente von einem Vorgänger abzuleiten, bei der Hide noch nicht definiert ist, dabei dürfte aber der Aufwand deutlich größer sein.

Eventuell könntest du eine eigene "ShowModalCustomHide" schreiben, die parallel zu ShowModal existiert.

[oki]

Hallo,

erst mal ist es wichtig zu wissen was für ein Fenster du benutzt. Ich würde ein "normales" Fenster benutzen und es mit ShowModal aufrufen. Dann ist es recht einfach alle Bedingungen in der OnClose Methode zu verarbeiten um ein Schließen zu verhindern.

Gruß oki

[APP]

Hallo oki,
da hast Du schon recht, aber mein Programm soll danach ja weiterlaufen,
das tut es aber nicht wenn das modale Fenster nicht geschlossen wird.

TSCHULDIGUNG :oops: , ich dachte neues Thema - neuer Tread, leider ist der Zusammenhang nun futsch,
daher eine Kurzzusammenfassung des "Parent-Threads"Programm anhalten und auf Taste/Button warten:

Zitat:

ich schreibe gerade an ein "DebugWindow", das bestimmte Meldungen, die ich im Hauptprogramm einfüge in einem separaten Fenster anzeigt.
...
Nun möchte ich aber eine Art "Einzelschrittmodus" implementieren, d.h. erst nachdem der Weiter-Knopf gedrückt wurde soll das Hauptprogramm weitermachen.
...

• Zuerst dachte ich daran das DebugWindow modal anzuzeigen,
  das hat aber den Nachteil das das Fenster bis zum nächsten
  Aufruf verschwindet, das möcht ich aber nicht!
  (Ich habe auch versucht zur Laufzeit ein 2. Fenster zu erzeugen und
  als Parent ein Panel auf dem DebugWindow anzugeben und dieses Fenster
  Modal zu zeigen, leider funktionierte das Ganze nicht wie erwartet)
• Dann versuchte ich es mit einer Endlosschleife:

p.s. Ich habe dort auch eine Lösung gepostet, die ich aber nicht sehr elegant finde :roll:.

[oki]

Hi,

ich hab mir deine eingefügten Komentare sowie deinen Link angeschaut.

Folgende Lösung:

Schreibe einen Thread in dem Du die Aktionen deines nicht modalen Überwachungsfensters steuerst (Fenster auch in diesem Thread kreieren und aufrufen).

An den entsprechenden Stellen deines Hauptprogrammes setzt du eine Abfrage über eine eigene Function für Warten (in dieser ein Sleep und Application.ProcessMessages). Mit dem Thred kannst du ein Ereignis senden, mit dem eine globale Variable deines Hauptprogrammes gesetzt wird.

Das alles so etwa nach dem Schema

Delphi-Quellcode:

Function MyWeiter: Boolean;
begin
  Result := False;
  sleep(50);
  Application.ProcessMessages;
  if not isWait then Result := True;
end;

  // laufend im Hauptprogramm

  // ab hier warten
  repeat
  until MyWeiter
  isWait := False;
  

  // und weiter zum nächsten Wartepunkt

Die Variable isWait wird durch das Ereignis des Thread für das Anzeigefenster gesetzt. So liegt das Fenster aus dem Thread heraus immer oben und der Programmablauf wird durch die Schalter gesteuert.

Gruß oki

[APP]

Hallo oki,
vielen Dank für Deine Bemühungen, ich habe mir Deine Lösung leider nur Kurz ansehen können, aber ich finde den Ansatz sehr interessant.


p.s. Außerdem habe ich etwas über Endlosschleifen gelernt: :shock:

Delphi-Quellcode:

REPEAT
  sleep(50);
  Application.ProcessMessages;
UNTIL MyWeiter;

belastet den Prozessor (genauer die CPU-Auslastun im Taskmanager) fast gar nicht, aber

Delphi-Quellcode:

REPEAT
  Application.ProcessMessages;
UNTIL MyWeiter;

führt zu einer 100% CPU-Auslastung

...und ein Druck auf

Delphi-Quellcode:

PROCEDURE TForm1.Button4Click(Sender: TObject);
BEGIN
   sleep(3000);
END;

führt dazu, dass das Programm 3 Sekunden nicht ansprechbar ist (d.h. nicht einmal die Form läßt sich bewegen), da habe ich die OH

Zitat:

The Sleep function suspends the execution of the current thread for a specified interval.

wohl falsch verstanden, ich meinte eher dass der Prozess "Prozessorzeit zurückgibt" aber doch noch Messages verarbeitet (wie der kleine Maxi sich das so vorstellt...).

Tja, man lernt nie aus! :warn:

[jbg]

Zitat:

suspends the execution of the current thread

Man muss nur wissen was alles zum "current thread" gehört.

[oki]

Jo,

ich denke das wars.

Gruß oki