WS_POPUP Windowstyle hat seltsamen Nebeneffekt

[idefix2]

Nachdem mir die vorgefertigten Delphi Messagedlg Routine zu unflexibel ist und ich aber nicht für jede kleine Zwischenfrage eine neue Form machen will, habe ich begonnen, mir eine flexiblere Dialog-Unit zu erstellen. Das Fenster soll zunächst einen grossen Label für die Textausgabe, ein Panel mit 5 Buttons (die man wahlweise vor dem Aufruf sichtbar oder unsichtbar machen kann) enthalten, geplant ist ein zusätzliches Frame, in das man zur Laufzeit weitere Eingabekomponenten, z.B. ein Edit-Feld oder eine Dropdownbox hängen kann.
Ich würde dem Fenster gerne den Style WS_POPUP or WS_THICKFRAME geben, weil mir für so ein Fragefenster eine Titelleiste überflüssig und eher störend erscheint.
Aber sobald ich in der Routine TdlgFrage.CreateParams die Zeile

Delphi-Quellcode:

Params.Style := WS_POPUP OR WS_THICKFRAME

einfüge, passsiert etwas ganz eigenartiges: Der erste Button wird bei der Anzeige der Form nicht gezeichnet. Er kann aber angeklickt werden, und wird sichtbar, sobald man ihn anklickt. Ohne diese Zeile sind alle Buttons normal sichtbar.

Zum Ausprobieren einfach die Unit einbinden, Aufruf mit

Delphi-Quellcode:

result:=Ask (Fragetext, Button1text, button2text ...)

[Bernhard Geyer]

Wieso nicht TTaskDialog verwenden? Damit ist man flexibel genug um viele einfache Dialogklassen zu vermeiden und man hat auch keine Buttons mit ganzen Fragen als Buttontext.

[idefix2]

Ich habe keine "Buttons mit ganzen Fragen" als Buttontext, sondern die möglichen Antworten auf die im Label angezeigte Frage. z.B:

Delphi-Quellcode:

case Ask('Eine PDF Datei mit diesem Namen existiert schon.'#13+#10   
            +'Wollen sie die PDF Datei überschreiben'#13#10
            +'oder eine neue Seite an die Datei anhängen?',
         'Überschreiben', 'Anhängen', 'Anderer Name', 'Abbrechen') of
   1:  doÜberschreiben;
   2:  doAnhängen;
   3:  DoAndererName;
   4:  exit;
   end;

Die Einschränkung der Buttontexte auf die paar vorgefertigten möglichen Antworten (Ok, Ja, Nein etc.) ist ein Hauptgrund für meine Eigenbau Dialog-Unit. Das Anzeigen anderer Buttons im TTaskdiaog ist zwar möglich, aber doch recht umständlich.

Abgesehen davon, dass ich noch auf einige Windows-XP-Anwender Rücksicht nehmen muss und in dem konkreten Projekt die Verwendung dieses Windows-Dialogs, den es erst ab Vista gibt, dadurch ohnehin nicht möglich ist.

Und der Standard-TTaskDialog ist übrigens auch mit der unnötigen Überschrift ausgestattet, die ich in meinem Dialog gerne weg hätte.

[bcvs]

Ich nehme für solche Zwecke Solway's Task Dialog. Der emuliert den Taskdialog auch unter XP. Zusätzlich habe ich mir eine Funktion ähnlich deiner Funktion Ask() geschrieben.
Damit kann man solche etwas komplexeren Fragedialoge auch mit einem Funktionsaufruf erzeugen. Man kann auch noch kurze Erläuterungstexte zu den einzelnen Antworten angeben, damit der Anwender genau weiß, was er da tut. (s. Solways Hompege, unteres Beispiel).

[idefix2]

Mir geht es in diesem Thread um diesen Fensterstyle ohne Überschrift, der nicht richtig funktioniert. Dass es prinzipiell andere Möglichkeiten gibt, Dialoge u erzeugen, ist schon klar.

[uligerhardt]

Zitat:

Zitat von idefix2 (Beitrag 1306642)

Das Anzeigen anderer Buttons im TTaskdiaog ist zwar möglich, aber doch recht umständlich.

Das kannst du natürlich genausogut in eine Helper-Routine packen, wie du es mit deiner Implementation getan hast. :mrgreen:

Zitat:

Zitat von idefix2 (Beitrag 1306642)

Abgesehen davon, dass ich noch auf einige Windows-XP-Anwender Rücksicht nehmen muss und in dem konkreten Projekt die Verwendung dieses Windows-Dialogs, den es erst ab Vista gibt, dadurch ohnehin nicht möglich ist.

Auch da gibt's Abhilfe: http://blog.synopse.info/post/2011/0...XP,Vista,Seven

Edit:

Zitat:

Zitat von idefix2 (Beitrag 1306646)

Mir geht es in diesem Thread um diesen Fensterstyle ohne Überschrift, der nicht richtig funktioniert. Dass es prinzipiell andere Möglichkeiten gibt, Dialoge u erzeugen, ist schon klar.

Aber obige Aussgaen kann man ja nicht unkommentiert stehen lassen. :twisted:

[Bernhard Geyer]

Zitat:

Zitat von idefix2 (Beitrag 1306642)

Ich habe keine "Buttons mit ganzen Fragen" als Buttontext, sondern die möglichen Antworten auf die im Label angezeigte Frage. z.B:

Delphi-Quellcode:

case Ask('Eine PDF Datei mit diesem Namen existiert schon.'#13+#10   
            +'Wollen sie die PDF Datei überschreiben'#13#10
            +'oder eine neue Seite an die Datei anhängen?',
         'Überschreiben', 'Anhängen', 'Anderer Name', 'Abbrechen') of
   1:  doÜberschreiben;
   2:  doAnhängen;
   3:  DoAndererName;
   4:  exit;
   end;

Die Einschränkung der Buttontexte auf die paar vorgefertigten möglichen Antworten (Ok, Ja, Nein etc.) ist ein Hauptgrund für meine Eigenbau Dialog-Unit. Das Anzeigen anderer Buttons im TTaskdiaog ist zwar möglich, aber doch recht umständlich.

Und genau für so einen Fall ist ein Taskdialog besser geeignet als ein "altertümlicher" Dialog mit geänderten Buttonbechriftungen
Anbei ein Screenshot (der LMD-Implementierung - mit noch Designfehlern der der D6-Version) wie es hier aussieht

Zitat:

Zitat von idefix2 (Beitrag 1306642)

Abgesehen davon, dass ich noch auf einige Windows-XP-Anwender Rücksicht nehmen muss und in dem konkreten Projekt die Verwendung dieses Windows-Dialogs, den es erst ab Vista gibt, dadurch ohnehin nicht möglich ist.

Der native Dialog ist erst ab Vista vorhanden. Wenn man aber einen der Zig-Delphi-Implementierungen nimmt so läuft das auch unter XP.

Zeige einfache einen "unbedarften" User deinen Dialog und diesen Taskdialog. Zu 95% wird er den Taskdialog verständlicher finden. Unter den Haupttexten kann man auch noch längere Beschreibungen unterbringen.

[frankyboy1974]

Hallo,

also ich generiere alle Formulare erst dynamisch zur Laufzeit des Programms. Den graphischen Editor von Delphi benutze ich nur noch zum Testen, ansonsten programmiere ich Oberflächen wie auch in Java üblich nur aus dem Quellcode heraus. Damit kann man sich natürlich beliebige Abfragedialoge sehr schnell flexibel erzeugen, ohne jedesmal ein neues Formular mit dem Editor erstellen zu müssen

mfg

frank

P.S.: Mir ist klar, dass dir dies nicht wirklich weiter hilft :P

[uligerhardt]

Ach ja - zu deiner Frage: :mrgreen:
Du kickst mit deinem CreateParams die Vorbelegungen raus. Das muss so ausschauen:

Delphi-Quellcode:

procedure TdlgFrage.CreateParams(var Params: TCreateParams);
begin
  inherited;
  Params.Style := Params.Style or WS_POPUP or WS_THICKFRAME;
  Params.ExStyle := Params.ExStyle or WS_EX_TOOLWINDOW;
end;

Edit: Dazu noch

Delphi-Quellcode:

BorderStyle := bsNone

. (Siehe http://stackoverflow.com/questions/1...ar-from-a-form)

Noch ein Nörgelkommentar: Messageboxen ohne Titelleiste hat z.B. List&Label, und ich hasse es. Die sind manchmal kaum zu sehen.

[BadenPower]

Zitat:

Zitat von uligerhardt (Beitrag 1306652)

Noch ein Nörgelkommentar: Messageboxen ohne Titelleiste hat z.B. List&Label, und ich hasse es. Die sind manchmal kaum zu sehen.

Und wenn dann naoch jemand meint, er müsse die Property "Position" der Form auf "poDesktopCenter" stellen, dann wird es ganz spassig.

[Bernhard Geyer]

Zitat:

Zitat von BadenPower (Beitrag 1306661)

Zitat:

Zitat von uligerhardt (Beitrag 1306652)

Noch ein Nörgelkommentar: Messageboxen ohne Titelleiste hat z.B. List&Label, und ich hasse es. Die sind manchmal kaum zu sehen.

Und wenn dann naoch jemand meint, er müsse die Property "Position" der Form auf "poDesktopCenter" stellen, dann wird es ganz spassig.

Stört das bei 3 Bildschirmen :-) (Ok, hab nur 2 - Da sind solche Desktopzentrierten Dialog "Suboptimal")

[BadenPower]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1306672)

(Ok, hab nur 2 - Da sind solche Desktopzentrierten Dialog "Suboptimal")

Bei 2 Monitoren ist es noch schlimmer als bei 3, da Du ja noch die Monitorumrandungen hast, welche beim Lesen der Meldung extrem stören.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1306672)

Stört das bei 3 Bildschirmen :-

Auch bei meinem 3 Monitor-System ist es für mich sehr oft störend, da die Meldung immer auf dem mittleren Monitor erscheint und dies ist dann meistens nicht der, auf welchem das Fenster liegt, welches die Meldung verursacht hat.

Darum erstelle ich ein Meldungsfenster im Regelfall immer mit poScreenCenter in Verbindung mit dmActiveForm.

[idefix2]

@ uligerhardt
Danke, in Verbindung mit Borderstyle=bsnone funktioniert es.

Die Microsoft Hilfe zu dem Thema ist leider reichlich undurchsichtig. Statt der verschiedenen vordefinierten Konstanten, die zum Teil mehrere Bits kombinieren, wäre es hilfreicher, wenn beschrieben wäre, was jedes einzelne Bit bewirkt, und welche Bits miteinander inkompatibel sind.
Ich habe jetzt mit verschiedenen Einstellungen ein bißchen experimentiert, z.B. bei

Delphi-Quellcode:

or WS_CHILD

erscheint kein Fenster und die Anwendung friert komplett ein -

Delphi-Quellcode:

or WS_CHILD and not WS_POPUP

stürzt genauso ab.

Zitat:

Zitat von BadenPower (Beitrag 1306679)

Darum erstelle ich ein Meldungsfenster im Regelfall immer mit poScreenCenter in Verbindung mit dmActiveForm.

Ich finde, eine solches Meldungsfenster sollte standardmässig relativ zur gerade vorher aktiven Form zentriert werden, nicht relativ zum Bildschirm. Das hat mich besonders beim Standarddialog mit Timeout gestört, bei dem habe ich nämlich keine einfache Möglichkeit gefunden, die Position zu verändern.

Delphi-Quellcode:

function MessageBoxTimeOut(hWnd: HWND; lpText: PChar; lpCaption: PChar; uType: UINT;
  wLanguageId: WORD; dwMilliseconds: DWORD): Integer; stdcall;
  external user32 name 'MessageBoxTimeoutW';