Formular mit eigenem, nicht gruppierten Taskbar-Eintrag erzeugen?

[a.def]

Meine Standardlösung für das Erzeugen eines eigenen Eintrags für Formular X in der Taskleiste war bisher immer

Delphi-Quellcode:

protected
 procedure CreateParams(var Params: TCreateParams); override;

// 

procedure TForm1.CreateParams(var Params: TCreateParams);
begin
 inherited; // CreateParams(Params);

 with Params do
  begin
   ExStyle := ExStyle or WS_EX_APPWINDOW;
   WndParent := GetDesktopWindow;
  end;
end;

Doch leider gruppiert Windows den Button meines Hauptformulars und den meines zweiten Formulars.
Gibt es einen Weg, um das mit Delphi zu umgehen?

[himitsu]

Fenster der selben "EXE" werden gruppiert, also wenn man das nicht guppiert haben will, dann in eine andere EXE.
https://www.microsoft.com/resources/....mspx?mfr=true

GetDesktopWindow sollte unnötig sein?
In die Taskleiste kommen Top-Level-Fenster mit der entsprechenden Kennung, dass sie da rein wollen (WS_EX_APPWINDOW).
Und Top-Level ist alles ohne Parent.

[a.def]

Verflickst das dachte ich mir schon, dass Windows hier mehr zu sagen hat als ich.
Denn sonst wäre die Option "Gruppieren" in der Windows-Taskleiste ja unnötig.

Das von mir angesprochene Formular hat ein paar Labels und 2 Buttons.
Die Labels werden von woanders (N Threads) sehr häufig gesetzt. Das ist mittlerweile alles so abgesichert, dass da nichts schief gehen kann (tat es früher, jetzt nicht mehr).

Wenn ich dieses Formular in eine eigene Exe auslagere, wie lasse ich dann diese beiden Exe'n kommunizieren? Da fällt mir gerade nur WMCopyData ein. Aber ist das "performant" genug, um
die Labels auf dem ausgelagerten Formular etwa alle 250 Millisekunden zu verändern?

Im Grunde genommen könnte ich mir diesen ganzen Käse sparen, würde TTaskBar seinen Dienst so tun wie ich gerne hätte.
Packe ich TTaskBar auf eben dieses zweite Formular was zur Laufzeit erzeugt wird und ändere Value, wird der Fortschritt von TTaskBar immer nur im Eintrag des Hauptformulars angezeigt.
Auch ein manuelles Erzeugen von TTaskBar mit Owner eben dieses zweite Formular zeigt den Fortschritt im Eintrag des Hauptformulars an.
Und zu guter letzt: selbst das Setzen des zweiten Formulars als MainForms zeigt den Fortschritt im ersten Eintrag an.

[jaenicke]

Hast du mehrere Fortschrittsanzeigen parallel?
Denn eigentlich ist das schon gut so, dass es nur eine Fortschrittsanzeige in der Taskleiste gibt und nicht für jedes Fenster uns jeden Tab einzeln. Da würde man ja wahnsinnig werden.

Gedacht ist das so, dass du mehrere "Unterfortschritte" zu einem bündelst und den dann anzeigst. Denn für den Benutzer ist ja normalerweise der Gesamtfortschritt vor allem relevant.

Interprozesskommunikation ginge hier sogar recht einfach, wenn du TStaticText statt TLabel benutzt. Das hat nämlich glaube ich ein Handle, so dass du aus der anderen Anwendung heraus direkt WM_SETTEXT benutzen könntest.

[a.def]

Ich habe 2 ProgressBars.
Einmal eine auf dem Hauptformular und einer in meinem zweiten Formular.
Es wird aber immer nur eine benutzt und die andere ist Visible := False.

Die Verlagerung in eine weitere Exe-Datei könnte tatsächlich die Lösung sein, ist aber wieder viel Aufwand.

Bedeutet das also, dass die TTaskBar immer die erste ProgressBar nimmt die gefunden wird? Wofür übergibt man denn dann einen Owner?
oder muss der Owner die ProgressBar sein anstatt das Formular?

Ich habe folgende Notlösung parat... keine Lösung aber für den notfall eben
- ich erzeuge TTaskBar im Hauptfomular und sobald ich mich im zweiten Formular im OnShow befinde, rufe ich FreeAndNile(TaskBarMgr1_); auf.
Dann habe ich meinen zweiten, nicht-gruppierten Taskbar-Eintrag und keine Fortschrittsanzeige im ersten Formular.

[himitsu]

Zitat von a.def:

Denn sonst wäre die Option "Gruppieren" in der Windows-Taskleiste ja unnötig.

Das ist eine "andere" Gruppierung.
Wenn die Taskleiste voll ist, werden die vielen Buttons in "einem" Button zusammengefasst.

Du meinst ja das, wo die nebeneinander liegen und der Absand fehlt.

[jaenicke]

Das Formular hat mit der Business Logik ja nicht viel zu tun. Das dient ja nur zur Anzeige, egal wer das benötigt.

Wir haben nur eine Fortschrittsanzeige, die als Interface durch das Hauptfenster bereitgestellt wird. Dieses Interface kann dann überall in der GUI-Logik der Anwendung verwendet werden.

[a.def]

Genau. Da liegt dann der eine Button auf dem anderen um ein paar Pixel nach rechts versetzt (nach Priorität geordnet nehme ich an).
Ich glaube ich werde absolut nicht drum rumkommen, eine zweite Exe zu erstellen.

TStaticText kann ich nur leider nicht verwenden, da ich TLabels und dann noch andere (andere Komponente) verwende.
Ich bastle mir gleich oder heute Abend mal eine kleine Demo und gucke wie oft und wie schnell ich mit WMCopyData Daten schicken kann.
Dann schicke ich nämlich immer alles in einem Rutsch (natürlich nur, wenn es eine Änderung gab).

Zitat:

Dieses Interface kann dann überall in der GUI-Logik der Anwendung verwendet werden.

Interfaces schön und gut. Ist mir aktuell aber zu kompliziert und möchte ich nicht unbedingt lernen, wenn es aktuell auch anders geht

[a.def]

Ich habe hier mal eine kleine Demo gebaut wie ich das realisieren würde.
Das geht sicher noch viel viel besser.

Test ist der Sender, Test2 ist der Empfänger

3 Buttons:
1: setzt das Formular Receiver zurück (ProgressBar.Position := 0; Label1.Caption := '-'
2: sendet 100x einen einen String und einen Integer an Receiver, dort wird eine ProgressBar gesetzt (dauert bei mir zwischen 5ms und 18ms)
3: sendet 50.000x einen String und einen Integer an Receiver, dort wird ein Label.Caption gesetzt (dauert bei mir zwischen 15 und 17 Sekunden)

Wenn man |exit an den zu sendenden String anfügt, stopt die Prüfung in Receiver > TForm1.WMCopyData nach dem ersten String.

Kann man das mit WMCopyData noch verbessern?