Ausblenden des Hauptformulars(SDI), aber nicht daraus erzeugte Child Formulare

[dstein]

Die Älteren von euch werden bestimmt das ein oder andere Delphi Buch aus dem Hanser Verlag, C&L oder mitip kennen.
Auch das Internet ist recht spärlich zu diesem Thema.
Leider finde ich zu meiner Frage keine für mich verständliche Antwort.
Also traue ich mich hier in die Runde eine Anfängerfrage zustellen.

Ich habe Hauptformular(SDI) und ein Childformular, vom Hauptformular aus erzeuge ich ein Childformular per:
frmClient := TfrmClient.create(self);
frmClient.show;

Nun möchte ich das Hauptformular minimieren (evtl. später nur in der Taskleiste) aber das frmClient sollen weiterhin auf dem Desktop sichtbar bleiben. Leider verschwinden das frmClient ebenfalls wenn das Hauptformular minimiert wird.
Ich habe verschiedenes ausprobiert, aber das ist ein stochern im Dunkeln.
Habt ihr Literaturhinweise und Stichworte wo ich von lernen kann. Oder sogar praktische Beispiele wie so etwas gemacht wird?

[stifflersmom]

Hide ist das Stichwort, wenn Du es nicht anzeigen willst.

Code:

frmClient := TfrmClient.create(self);
frmClient.show;
self.hide;

[dstein]

Ja Danke,
aber mit hide ist das Mainformular nicht mehr greifbar, bei minimiert kann ich immer noch auf das Mainformular zugreifen

[Bernhard Geyer]

Sowas dürfte einfach nicht gehen. Child kann man nicht sichtbar haben, wenn parent minimiert/versteckt ist.

Überleg dir mal ob du überhaupt noch auf MDI setzt.
Praktisch kein Programm nutzt das mehr. Ist mehr oder minder ein Konzept aus dem letzten Jahrtausend.

[dstein]

Upps das funktioniert auch:
self.WindowState:= wsMinimized;

nee leider nicht, Client wird auch wsMinimized

[dstein]

ich verwende kein MDI sondern Hauptformular(SDI)

[freimatz]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1516287)

Sowas dürfte einfach nicht gehen. Child kann man nicht sichtbar haben, wenn parent minimiert/versteckt ist.

Überleg dir mal ob du überhaupt noch auf MDI setzt.
Praktisch kein Programm nutzt das mehr. Ist mehr oder minder ein Konzept aus dem letzten Jahrtausend.

*Räusper* Kann doch sagen, dass mein Program noch etliche tausende Leute beruflich nutzen.
Ja das Konzept ist alt. Aber solange es keine brauchbare Alternative gibt nutze ich das weiterhin.
Aber zurück zum Thema: ich sehe nicht dass er irgendwo MDI nutzt.

[himitsu]

Das Hauptformular übernimmt hier oft viele Eigenschaften, welche für die ganze Anwendung gelten, bzw. es fummelt (zu) oft eigenmächtig an solchen Einstellungen rum.

Mainform schließen = Anwendung beenden
Mainform minimieren = Anwendung minimieren
...

[stifflersmom]

Zitat:

Zitat von dstein (Beitrag 1516285)

Ja Danke,
aber mit hide ist das Mainformular nicht mehr greifbar, bei minimiert kann ich immer noch auf das Mainformular zugreifen

Natürlich kannst Du noch auf die Mainform zugreifen.

Im OnClose der Form2 ein MainForm.Show und schon stehst Du wieder am Anfang.

[dstein]

Vieleicht hilft das weiter warum mich frage. In meinem Beispiel habe ich ein simples PostIT Tool gebaut. Das Programm und Basisverhalten entspricht meiner Vorstellung wie ohne Kopfzeile und Rahmenloses Clientformular das per Maus halten verschoben werden kann, kleine Feature StayOnTop Farben für Font und Background, zentrales speichern der Notizen in einer einfachen SQLite Tabelle usw..
Nur das Mainform minimieren, weil es zum normalen Gebrauch ausser per Doppelklick oder PopupMenu einen neuen PostIT-Zettel erstellen, nicht benötigt wird, bekomme ich nicht hin. Das im Mainform ein Grid mit allen PostIT-Zettel enthalten ist, ist nur eine Spielerrei.
Am Rande bemerkt; Alles was ich mit Delphi mache ist Hobby weil es mir Spaß macht ohne kommerzielle Ambitionen.

[KodeZwerg]

Ich weiß nicht genau ob es das ist wonach Du suchst aber zumindest kannst Du hiermit Dein Hauptfenster minimieren/verstecken und all Deine anderen Fenster bleiben offen.

Delphi-Quellcode:

{ -----------------------------------------------------------------------------
  Unit Name: frClient
  Unit Pfad: C:\DelphiSourceXE\PostIt_2022
  Projekt  : PostIt
  Plattform:

  Uses: CodeSiteLogging, DsUnitXE3,
  ### ChangeLog
  28.01.2021
  28.01.2021 Createdatum
  ----------------------------------------------------------------------------- }
unit frClient;

interface

uses //CodeSiteLogging,
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, System.Types,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.Menus, Vcl.DBCtrls, Data.DB, DBAccess, Uni, MemDS;

type
  TfrmClient = class(TForm)
    PopMnu: TPopupMenu;
    nmuDelete: TMenuItem;
    DBMmo: TDBMemo;
    Qry: TUniQuery;
    ds: TUniDataSource;
    QryIDNR: TIntegerField;
    QryFrmName: TStringField;
    QrysNotiz: TStringField;
    QryBKColor: TStringField;
    QryclTop: TIntegerField;
    QryclLeft: TIntegerField;
    QryclHeight: TIntegerField;
    QryclWidth: TIntegerField;
    QryiStayOnTop: TIntegerField;
    nmuStayOnTop: TMenuItem;
    dlgColor: TColorDialog;
    nmuColor: TMenuItem;
    QryftColor: TStringField;
    nmuFtColor: TMenuItem;
    procedure nmuDeleteClick(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure DBMmoChange(Sender: TObject);
    procedure FormCloseQuery(Sender: TObject; var CanClose: Boolean);
    procedure nmuStayOnTopClick(Sender: TObject);
    procedure DBMmoMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
    procedure DBMmoMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer);
    procedure DBMmoMouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer);
    procedure nmuColorClick(Sender: TObject);
    procedure nmuFtColorClick(Sender: TObject);
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
  protected
    procedure CreateParams(var Params: TCreateParams); override;
  private
    FInitialPos: TPoint;

    procedure SaveSetUp;

    { Private-Deklarationen }
  public
    PubiIDNR: Integer;

    bDel: Boolean;

    procedure SetData(iIDNR: Integer);

  end;

var
  frmClient: TfrmClient; // frClient

implementation

uses frPostIt;

{$R *.dfm}

procedure TfrmClient.CreateParams(var Params: TCreateParams);
begin
  inherited CreateParams(Params);
  Params.ExStyle := Params.ExStyle or WS_EX_APPWINDOW;
  Params.WndParent := 0;
end;

CodeSiteLogging habe ich nicht, deine eigene DsUnitXE3 fehlt leider auch im Download.
Wenn ich beides auskommentiere und entsprechende Zeilen ändere kann ich Dein Projekt starten.

[KodeZwerg]

Ps: Zum testen hatte ich Deiner Hauptform einen Style mit minimieren Button ausgestattet :lol:

[Rolf Frei]

Bin nicht sicher ob das auf einfache Art lösbar ist. Bin auch nicht sicher, ob das normales Windows- oder Delphi Verhalten ist (Minimierung des Hauptfensters). Ein Lösungsansatz könnte aber eventuell sein, ein spezielles unsichtbares Hauptformular zu untzen (ev. W=0/H=0, wenn Visble False nicht geht), welches dann das Anwendungshautpformular ist. Dein aktuelles Hauptformular würde dann auch zu einem "normalen" Formular und hätte keinen Einfluss mehr auf die anderen PostIt Fenster. Das ist mal so ein Ideenansatz, habe es selber aber nicht ausprobiert.

[KodeZwerg]

Zitat:

Zitat von Rolf Frei (Beitrag 1516344)

Bin nicht sicher ob das auf einfache Art lösbar ist. Bin auch nicht sicher, ob das normales Windows- oder Delphi Verhalten ist (Minimierung des Hauptfensters). Ein Lösungsansatz könnte aber eventuell sein, ein spezielles unsichtbares Hauptformular zu untzen (ev. W=0/H=0, wenn Visble False nicht geht), welches dann das Anwendungshautpformular ist. Dein aktuelles Hauptformular würde dann auch zu einem "normalen" Formular und hätte keinen Einfluss mehr auf die anderen PostIt Fenster. Das ist mal so ein Ideenansatz, habe es selber aber nicht ausprobiert.

Das ding ist, solange es nur ein button auf der taskbar gibt, verhalten sich alle fenster entsprechend des hauptfensters, mit meiner obigen methode wird dieses verhalten auf den kopf gestellt und jedes weitere fenster von dieser klasse bekommt sein eigenen taskbar button spendiert, entkoppelt vom hauptfenster, das einzige was die noch zusammenhält ist ein schließen des hauptfensters.

[peterbelow]

Zitat:

Zitat von dstein (Beitrag 1516281)

Die Älteren von euch werden bestimmt das ein oder andere Delphi Buch aus dem Hanser Verlag, C&L oder mitip kennen.
Auch das Internet ist recht spärlich zu diesem Thema.
Leider finde ich zu meiner Frage keine für mich verständliche Antwort.
Also traue ich mich hier in die Runde eine Anfängerfrage zustellen.

Ich habe Hauptformular(SDI) und ein Childformular, vom Hauptformular aus erzeuge ich ein Childformular per:
frmClient := TfrmClient.create(self);
frmClient.show;

Nun möchte ich das Hauptformular minimieren (evtl. später nur in der Taskleiste) aber das frmClient sollen weiterhin auf dem Desktop sichtbar bleiben. Leider verschwinden das frmClient ebenfalls wenn das Hauptformular minimiert wird.
Ich habe verschiedenes ausprobiert, aber das ist ein stochern im Dunkeln.
Habt ihr Literaturhinweise und Stichworte wo ich von lernen kann. Oder sogar praktische Beispiele wie so etwas gemacht wird?

Seit etlichen Delphi-Versionen ist das Mainform der Anwendung (das erste mit Application.CreateForm erzeugte Form im DPR-File) der API-Owner aller weiteren Forms, und das ist die Ursache des beschriebenen Verhaltens. Windows stellt dadurch sicher, daß alle sekundären Forms versteckt werden, wenn das Mainform minimiert oder selbst versteckt wird.

Man kann dieses Verhalten ändern, in dem man im DPR-File die Zeile

Delphi-Quellcode:

Application.MainformOnTaskbar := true;

auf false ändert, aber das hat unschöne Nebenwirkungen (seit Windows Vista); das Taskbar-Icon funktioniert dann nicht mehr richtig.

Besser ist es, wie in KodeZwerks Beispiel die CreateParams-Methode des sekundären Forms zu überschreiben.

Delphi-Quellcode:

Params.ExStyle := Params.ExStyle or WS_EX_APPWINDOW;

Das gibt dem Form einen eigenen Taskbar-Button.

Delphi-Quellcode:

**Params.WndParent := 0;

Und das entkoppelt das Form vom Mainform, es steht damit auf der gleichen Ebene in der Z-Ordnung wie dieses. Nachteil: Damit kann das Mainform auch das sekundäre Form überdecken, was nicht unproblematisch ist...

[Rolf Frei]

Aber ist das wirklich das, was er will? Also ich möchte bei mir nicht für jedes einzelne PostIt ein eigenes Symbol auf der Taskabar haben.

[peterbelow]

Zitat:

Zitat von Rolf Frei (Beitrag 1516369)

Aber ist das wirklich das, was er will? Also ich möchte bei mir nicht für jedes einzelne PostIt ein eigenes Symbol auf der Taskabar haben.

Schon richtig, man kann die Zeile auch weglassen. Aber dann kommt man nicht mehr an das Fenster, wenn es von sichtbaren Hauptfenster überdeckt wird.

[dstein]

Erstmal Danke; Jeder Tipp ist willkommen.
Auf den ersten Blick sind die vielen Items in der Taskbar unschön.
Aber es ist ein Schritt weiter. Nun habe ich einen Ansatz in welche Richtung ich mich schlau machen kann.

[Rolf Frei]

Zitat:

Zitat von peterbelow (Beitrag 1516371)

Zitat:

Zitat von Rolf Frei (Beitrag 1516369)

Aber ist das wirklich das, was er will? Also ich möchte bei mir nicht für jedes einzelne PostIt ein eigenes Symbol auf der Taskabar haben.

Schon richtig, man kann die Zeile auch weglassen. Aber dann kommt man nicht mehr an das Fenster, wenn es von sichtbaren Hauptfenster überdeckt wird.

Wenn er doch aber meinen Vorschlag nutzt, ist das Hauptfenster ja garnie sichtbar (Dimension 0x0) und ein normales Child Fenster übernimmt die Funktion des Hauptfensters. Will man die ganze App minimieren, müsste dieses Fenster die Befehle an das unsichtbare Hauptformular senden nud so ein Hauptformular imitieren. Müsste doch so gehen.

[Bernhard Geyer]

Zitat:

Zitat von freimatz (Beitrag 1516294)

Aber zurück zum Thema: ich sehe nicht dass er irgendwo MDI nutzt.

Schande über mein Haupt. Irgendwie habe ich SDI mit MDI zusammen geworfen.