Laufzeit-Themes verwenden

[musicman56]

Hallo DP-Spezialisten,

vorab nochmals wie schon an manch anderer Stelle hier der Hinweis: ich hab noch keine Uni von innen gesehen und mir alles selber beigebracht. Also steinigt mich nicht gleich, wenn ich ein paar dumme Fragen von mir gebe.

Ausgangs-Situation: da ich den direkten Schritt von D7 auf XE2 gemacht habe, hat meine History über die VCL-Controls-Erweiterungen ein paar Löcher. Ich wollte jetzt mal den für mich neuen TButton mit dem Style "bsSplitButton" ausprobieren. Leere Form, Button drauf, Popupmenü dazu, als DropDownMenu des Buttons das Popupmenu zugewiesen, compiliert, die MiniApp laufen lassen, und....weit und breit kein TButton in Sicht.

Nach langem Ausprobieren habe ich dann festgestellt, es liegt an den Projekteigenschaften "Laufzeit-Themes". Wenn die aus sind, kein TButton in Sicht, sind sie aktiviert, ist der Button da. Online-Hilfe befragt und eine Menge Antworten gefunden, aber die Zusammenhänge irgendwie nicht kapiert.

In der Hilfe steht: Gibt an, ob die Anwendung, die Sie entwickeln, Laufzeit-Themes oder ein benutzerdefiniertes Manifest verwenden soll. Was zum Henker hat ein Manifest mit Laufzeit-Themes zu tun? Bzw. wie hängt das zusammen?

Ich dachte immer, ein Manifest brauche ich beispielsweise um eine App (die nicht "install", "setup" usw. im Exe-Namen enthält) als Admin auszuführen, bzw. über den UAC-Dialog dessen Ausführung als Admin zu bekommen.

"Laufzeit-Themes" und ähnliche Suchbegriffe bringen in der Delphi-Hilfe keine Erleuchtung. Himitsu's Manifest-Creator hab ich mir auch angesehen, aber nicht wirklich verstanden um was es geht.

Prinzipiell verstanden habe ich, wenn ich die Laufzeit-Themes aktiviere, dann sieht mein Programm nicht mehr nach "Old Style" aus, sondern wie ein aktuelles Windows-Programm. Dann kann ich auch problemlos Windows-Styles verwenden. Auch das Aktivieren von Windows-Styles zur Laufzeit klappt via

Delphi-Quellcode:

 TStyleManager.SetStyle(TStyleManager.LoadFromFile('meine_style_datei.vsf'));

Aber dann - mein zweites Problem - sehen manche Formulare (die ich übrigens alle zur Laufzeit erzeuge) auf den ersten Blick richtig bescheiden aus. Labels sind nicht lesbar usw. siehe Bild. Wenn ich allerdings mit der Maus drüfer fahre, oder die [Alt]-Taste drücke, verschwindet das seltsame Verhalten. Aber wie gesagt nicht bei allen Formularen, sondern nur bei einigen wenigen.

Hat jemand ein paar Tipps/Links für mich, wo ich mich schlau lesen kann? Google spuckt soooo viel aus, das habe ich schon ein paar Stunden hinter mir.

[jaenicke]

Das Manifest beinhaltet welche Controls benutzt werden sollen. Ist so eine Angabe nicht da, werden die alten Controls benutzt, da Windows davon ausgeht, dass die Anwendung nicht kompatibel mit den aktuellen Windowsversionen ist. (Außerdem werden ohne Manifest auch die Umleitungen bei Schreibzugriffen auf c:\programme usw. aktiviert.)

Da es diverse Controls (so auch diesen Button) ausschließlich in den neuen Controls gibt, funktioniert der auch nur, wenn diese aktiv sind.

Was du mit Adminrechten meinst, kann mit in einem solchen Manifest stehen, muss aber nicht. Tipp: Schau dir ein solches Manifest einfach mal an, das ist eine simple XML-Datei, deren Inhalt mit Englischkenntnissen ganz gut lesbar ist.

[musicman56]

Hallo Sebastian,

bedeutet das, eine Komponente kann "nicht kompatibel" mit Laufzeit-Themes sein? Mein Hauptprogramm ist eine MDI-Anwendung, deren MdiChilds schon seit Jahren mit denselben Routinen erzeugt und wieder freigegeben werden. Da dürfte also normalerweise kein Fehler versteckt sein, und trotzdem habe ich ein Problem, das nur bei aktivierten Laufzeit-Themes auftritt. Hab's vorhin nicht dazu geschrieben, weil's ja kein Roman werden sollte.

In der Screen.OnActiveFormChange zugewiesenen prozedur werden abhängig von MdiChildCount auf dem Desktop befindliche Panels ein- bzw. ausgeblendet (Visible := MdiChildCount = 0). Funktioniert auch wunderbar, nur nicht bei einem einzigen Mdi-CHild. Da wird nach dem Erzeugen und Anzeigen des Formulares "Screen.OnActiveFormChange" nicht ausgelöst. Ursache könnte also ein "inkompatibles control" sein? Und womöglich auch das Phänomen auslösen, welches ich im Screenshot beschrieben habe?

[jaenicke]

Zitat:

Zitat von musicman56 (Beitrag 1231274)

Und womöglich auch das Phänomen auslösen, welches ich im Screenshot beschrieben habe?

Das sieht für mich eher danach aus, dass sich da Komponenten überlagern. Hast du vielleicht einen Text im RadioButton und daneben zusätzlich ein Label oder so?

[musicman56]

Nein, da überlagert sich (ganz sicher) nichts. Und wie gesagt, 1x [Alt] und alles ist ganz normal. Ich komme langsam zu der Überzeugung, dass irgendeine Komponente das Abarbeiten einiger Messages unterbricht/behindert. Es sind so viele unterschiedliche Phänomene in unterschiedlichen Formularen, da muss etwas gewaltig stinken.

[EWeiss]

Ich hatte das auch mal im zusammenhang mit MouseWheel.
Allerdings ohne Themes zu verwenden.

Es scheint bei dir dann ein problem mit "GetDlgItem" vorzuliegen.
Die Controls werden in dem Fall nicht richtig enumeriert..
Denke mal da kannst du selbst nichts fixen.

gruss

[stahli]

1/2 h gesucht ... und gefunden: http://www.delphipraxis.net/162251-d...n7-64-pro.html
Ich wusste nur noch, dass da mal etwas ähnliches war.

Ist zwar etwas älter, aber vielleicht hilft ja etwas davon.

[EWeiss]

Zitat:

Ist zwar etwas älter, aber vielleicht hilft ja etwas davon.

Kann man nur hoffen denn das hat ja etwas mit der IDE zu tun in deinem verlinkten link..
Während bei ihm das bei einer kompilierten Exe auftritt. (So wie bei mir damals (DLL)).

gruss

[Bernhard Geyer]

Zitat:

Zitat von EWeiss (Beitrag 1231281)

Kann man nur hoffen denn das hat ja etwas mit der IDE zu tun in deinem verlinkten link..
Während bei ihm das bei einer kompilierten Exe auftritt. (So wie bei mir damals (DLL)).

Die Delphi-IDE ist ja auch zu großen Teilen mit der VCL entwickelt, also mit dem gleichen GUI-Code der auch bei den mit der IDE erstellten Exes/DLLs verwendet wird.

[musicman56]

Hallo zusammen,

erst mal vielen Dank für die Rückmeldungen.

JVCL: hatte ich installiert. Jetzt mal testweise deinstalliert, brachte aber nichts.

IDE: In der IDE gibt's keinerlei (Anzeige-)Probleme

Auch das Deaktivieren einiger Packages die ich als potentiellen Verursacher in Verdacht hatte (Abbrevia, AsyncPro, dclAsyncPro, List&Label) hat nichts gebracht. Daraufhin habe ich mir mal einen Großteil der älteren Projekte (überwiegend kleinere Tools und Hilfsprogramme) vorgenommen und dort Laufzeit-Themes aktiviert. Bei einigen hatte ich ähnliche Effekte. Die Logik dahinter ist mir noch nicht klar, es sieht aber derzeit so aus, als wären nur Projekte betroffen, die mit einer älteren Delphi-Version (überwiegend D7) erstellt wurden. Ich ahne nichts Gutes :oops:

Derzeit bin ich dabei eines der MdiChilds neu zu erstellen, mit den selben Komponenten der ursprünglichen Form. Noch ein paar Stunden, dann werde ich mehr wissen.

[musicman56]

Hallo zusammen,

das Problem bzw. die Ursache ist gefunden: Delphi-Fehler oder VCL-Fehler.

Es passiert folgendermaßen: wenn im Formularereignis "OnPaint" oder "OnActivate" externe Aktionen durchgeführt werden, die sich nicht auf das Formular selbst beziehen, dann werden wohl irgendwelche VCL-Ereignisse/Messages nicht mehr korrekt abgearbeitet.

Hintergrund-Info: ich habe mehrere MDI-Anwendungen (ich weiß, MDI wird nicht mehr gerne gesehen, es ist aber aus Anwendersicht oftmals eine sehr elegante Angelegenheit) und dann passiert es zwangsläufig, dass beim Anzeigen einer Form neben den sonstigen Initialisierungen/Größenanpassungen usw. auch mal ein Datenbankzugriff erforderlich ist. Z.B. muss ich Filter/Ranges entfernen oder setzen. Bei modalen Fenstern könnte man das alles in "OnCreate" abarbeiten, nicht so bei MDI-Fenstern. Da ist es fast der Normalfall, dass ein und dieselbe Datenbank mit unterschiedlichen Anzeigekriterien (Filtern, Ranges) in mehreren Fenstern zur Anzeige kommt. Also braucht man OnPaint und OnActivate.

Sind Laufzeit-Themes deaktiviert, klappt das auch alles einwandfrei. Nicht jedoch, wenn Lauffzeit-Themes aktiviert sind, und wenn die aufgerufenen Ereignisse "länger dauern", CPU-Zeit beanspruchen, Datenbank-Aktionen durchführen, oder was auch immer der Auslöser ist. Hab ein paar Stunden mit dem Debugger verbraten, aber kann es nicht eingrenzen.

Lösung des Problems: strikte Trennung von Aktionen die nur das Formular betreffen und schnell abgearbeitet sind (da funktioniert OnPaint und OnActivate) und alles Andere aufgeteilt in "OnCreate" und "OnActivate". Hab es also prinzipiell so gelöst:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs;

type
  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
    procedure FormActivate(Sender: TObject);
  private
    { Private-Deklarationen }
    FFirstActivate: boolean;
  public
    { Public-Deklarationen }
    procedure InitDefaults(FirstActivate: boolean);
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
begin
  FFirstActivate := true;
  InitDefaults(FFirstActivate);
end;

procedure TForm1.FormActivate(Sender: TObject);
begin
  if FirstActivate
  then FirstActivate := false
  else InitDefaults(false);
end;

procedure TForm1.InitDefaults(FirstActivate: boolean);
begin
  if FirstActivate then begin
    ...
  end;
  ...
end;

end.

Nochmals vielen Dank für eure Anregungen.