Wie Dialogs.CreateMessageDialog abfangen

[QuickAndDirty]

Hallo
Ich habe versucht Showmessage mit einen Hook auf WM_INITDIALOG abzufangen...
leider wird diese Message dafür nie verwendet, Stattdessen wird (in D2007) in der Unit Dialogs eine
Function CreateMessageDialog aufgerufen, in der das Formular "komplett zufuß" aufgebaut wird .
Die Einzige Message die man da mit bekommt könnte WM_GETTEXT sein....

Ich möchte Dialogs nicht bearbeiten.

Kann ich die Adresse von CreateMessageDialog nach Programmstart auf eine eigene Function legen?
Würde sich das auch auf Dialoge auswirken die von anderen Komponentensammlungen benutzt werden?

Ich will verhindern, dass in einem Dienst Modale Fenster aufgehen, die auf Eingaben warten.

[Maliko]

Uhh das würde mich auch brennend interessieren. Das selbe Problem haben wir nämlich auch. Wir haben das bisher immer so umgangen, dass der Dienst ein Silent-Flag setzt und dieses Flag sorgt dafür dass der MessageDialog gar nicht erst getriggert wird, sondern die Fehlermeldung stattdessen in ein Logfile geschrieben wird. Das ist natürlich nur möglich wenn man bei der Entwicklungs selbst an so etwas denkt.

Sollte es also tatsächlich ne Möglichkeit geben den tatsächlich abzufangen wäre ich daran ebenfalls sehr interessiert.

[QuickAndDirty]

in Delphi XE wäre es soo einfach.
Man könnte eine angepasste Dialogs.pas in den Projekt Ordner kopieren...und dann würde Delphi die nehmen...
Aber für D2007 weiß ich keine Lösung.

[QuickAndDirty]

OK Ich glaube ich habs. (Bzw. Ich habe noch einen Ansatz...)
Muss es nur noch testen.
https://stackoverflow.com/questions/...lared-function

das dürfte die Lösung sein

[Uwe Raabe]

Zitat von QuickAndDirty:

in Delphi XE wäre es soo einfach.
Man könnte eine angepasste Dialogs.pas in den Projekt Ordner kopieren...und dann würde Delphi die nehmen...
Aber für D2007 weiß ich keine Lösung.

Wieso sollte das bei D2007 anders sein?

[himitsu]

Zitat:

WM_INITDIALOG

Es kommt drauf an, Dialoge können im Delphi über die VCL (TForm) oder die Dialog-WinAPI ablaufen (TaskDialog usw.).

CreateMessageDialog ist natürlich direkt nur VCL.
Beim normalen ShowMessage und Co. kommt es grauf an, ob das Windows aktuell genug ist und ob die neue CommonControls-API (ab v6) vorhanden+aktiv ist.
Nicht dass jemand auf die saublöde Idee kam und denkt der alte Win9x/2K-Look sei zu cool.

Und Delphi-DialogeFenster (CreateWindow) mit ShowModal sind nunmal keine "Dialoge" (mit WM_INITDIALOG usw.).

Zitat:

Stattdessen wird (in D2007) in der Unit Dialogs eine
Function CreateMessageDialog aufgerufen, in der das Formular "komplett zufuß" aufgebaut wird .

Normal sollte das nicht passieren, in Delphis der letzten dutzend Jahre ... außer du baust irgendwo bissl Mist,
denn vor CreateMessageDialog kommt irgendwo eine entsprechende Prüfung, ob der "Fallback" für eine veraltete API nötig ist.

Aktuell in Delphi 11 (davor jeweils ein bissl anders)

Delphi-Quellcode:

  if TOSVersion.Check(6) and UseLatestCommonDialogs and
     IsNewCommonCtrl and not ((shDialogs in TStyleManager.SystemHooks) and not StyleServices(Screen.ActiveCustomForm).IsSystemStyle) then

@QuickAndDirty: schau mal in Form.ShowModal rein.
Ich bin mir fast sicher, dass dort irgendwo ein Event bezüglich "Modal" ausgelöst wird und in System oder SysUtils gäbe es etwas, wo du dich dafür registrieren kannst.

Und eventuell noch ein schmutziges UseLatestCommonDialogs:=False; .

[add]
Nee, in Forms war es (TApplicationEvents)

Delphi-Quellcode:

procedure TApplication.ModalStarted;
begin
  Inc(FModalLevel);
  if (FModalLevel = 1) and Assigned(FOnModalBegin) then
    FOnModalBegin(Self);
end;

Achtung: TService hat ein anderes TApplication, aber das TApplication der VCL läuft dennoch "heimlich" im Hintergrund.
[/add]

Zitat:

Ich will verhindern, dass in einem Dienst Modale Fenster aufgehen, die auf Eingaben warten.

In einem Dienst darf es überhaupt keine Dialoge/Fenster geben, egal ob modal oder nicht,
seit die Alle standardmäßig nicht mehr "interactive" sind.

[QuickAndDirty]

Ja die Entwicklungsumgebung ist WIN2000 und die IDE D2007 dann läuft alles über "CreateMessageDialog"
andernfalls wird alles über "TaskDialogIndirect" aus der CommCtrl unit gemacht.
So ein misst.

Also sind zwei Lösungen notwendig?
UseLatestCommonDialogs ist in D2007 standardmäßig auf true.
Wenn ich es auf FALSE setze dann würden immer die "zufuss"-Dialoge genutzt werden oder?

Im TApplicationEvents.OnModalBegin
bekomme ich leider auch nicht raus welcher Dialog da jetzt offen ist und schließen kann ich ja dann auch nicht. Soweit ich weiß.

Ich will die Dialoge verhindern, weil der Dienst halt in einem Dialog hängen kann.

[himitsu]

Indirekt doch.
VCL-Dialoge stehen in Screen.Forms und dort sollte es der Neuste sein, bzw. soooo viel sollte dort auch nicht existieren.

Aber da das Zeug eh aus dem Service raus gehört, kannst dort schön eine Exception werfen und den Dialog abbrechen.
Der Code wo es dann knallt ... der gehört letztendlich repariert.



Man könnte vielleicht auch noch in TApplicationEvents.OnMessage auf sowas wie WM_SHOWWINDOW und vielleicht WM_CREATE reagieren.
FindControl IsVCLControl

Zitat:

Wenn ich es auf FALSE setze dann würden immer die "zufuss"-Dialoge genutzt werden oder?

Jupp.

Die ganz neuen TaskDialog-APIs bieten nun auch eine Übersetzung,
aber das CreateMessageDialog und Co. haben einen Vorteil ... es sind da drauf z.B. VCL-Buttons, bei denen man schön die Captions ändern kann, ohne sich nicht komplett selbst um den Dialog kümmern zu müssen.
bzw. es lassen sich leicht weitere VCL-Controls draufpappen.



Bei uns hab ich nun die letzten 3 Windows 7 entsorgt. (das eine Windows 7 Embedded ... da ist das Display kaputt und es hat sich leider selbst disqualifiziert )
PS: Selbst die ersten Versionen von Windows 10 sind bereits "offiziell" tot.

[QuickAndDirty]

Zitat von himitsu:

Indirekt doch.
VCL-Dialoge stehen in Screen.Forms und dort sollte es der Neuste sein, bzw. soooo viel sollte dort auch nicht existieren.

Aber da das Zeug eh aus dem Service raus gehört, kannst dort schön eine Exception werfen und den Dialog abbrechen.
Der Code wo es dann knallt ... der gehört letztendlich repariert.



Man könnte vielleicht auch noch in TApplicationEvents.OnMessage auf sowas wie WM_SHOWWINDOW und vielleicht WM_CREATE reagieren.
FindControl IsVCLControl

Zitat:

Wenn ich es auf FALSE setze dann würden immer die "zufuss"-Dialoge genutzt werden oder?

Jupp.

Die ganz neuen TaskDialog-APIs bieten nun auch eine Übersetzung,
aber das CreateMessageDialog und Co. haben einen Vorteil ... es sind da drauf z.B. VCL-Buttons, bei denen man schön die Captions ändern kann, ohne sich nicht komplett selbst um den Dialog kümmern zu müssen.
bzw. es lassen sich leicht weitere VCL-Controls draufpappen.



Bei uns hab ich nun die letzten 3 Windows 7 entsorgt. (das eine Windows 7 Embedded ... da ist das Display kaputt und es hat sich leider selbst disqualifiziert )
PS: Selbst die ersten Versionen von Windows 10 sind bereits "offiziell" tot.

Wir beide wissen, dass technical debt sucked und man sich davon befreien sollte.
Dieser Befreiungschlag, konvertierug zu unicode und Delphi XE 10.3, ist auch geplant, sobald ich mit einem anderen Projekt an dem ich sitze und das immer größer wird , fertig bin.

Da es ja nur um das verhindern der Dialoge für den Dienst, der auch als Desktop tray Anwendung laufen kann, geht es ja erstmal wenn ich die Messageboxen verhindere.