Form in DLL (Text in Titelleiste zu kurz)

[ringli]

Ich habe da ein kleines Problem mit einer Form in einer DLL. Der Aufruf der Form selber klappt soweit problemlos, aber die Titelzeile der Form bereitet mir Kopfzerbrechen.

Eigentlich sollte in der Titelleiste "Einstellungen" erscheinen (ist auch so im OI eingetragen), seltsamerweise erscheint dort aber nur "E". Auch wenn ich zur Laufzeit über
Form.Caption := 'blubb'; die Titelleiste ändere erscheint da nur ein "b" anstatt von "blubb".

Ich habe auch schon probiert die Titelleiste über SetWindowTextW zu ändern, aber das funktioniert leider auch nicht.

Hat schon mal jemand einen Lösungsansatz für mich?

[ringli]

Hat keiner ein Idee woran es liegen könnte?

[Luckie]

Wird die Caption dynamisch in der DLL gesetzt? Wenn ja, zeig mal etwas Code.

Noramlöerweise hat man diesen Effekt wenn man eine Unicode-Zeichenkette einem Kontrol zuweist, das nur Ansi versteht. Unicode-Zeichenketten sehen nämlich so aus: #00xx#00xx bei Ansizeichen. #0 ist aber unter Windows das Stringendezeichen. Castet man den Unicode String vorher nicht nach Ansi ist eben nach dem ersten Zeichen schluss mit der Ausgabe.

[ringli]

Hallo Luckie!

Die Caption wird eigentlich nicht dynamisch gesetzt sondern im OI festgelegt. Aber auch wenn ich die Caption zur Laufzeit ändere wird nur ein Zeichen in der Titelleiste angezeigt.
Die Anwendung (stammt nicht von mir) in der später das AddIn laufen soll ist übrigends auf Unicode ausgelegt wenn das wichtig ist.

Delphi-Quellcode:

// Aufruf des Formulars in der Mainunit des AddIns
function TDelphiConnect.ShowConfigDialog(hWndOwner: LongWord): HResult;
begin
  // Form erstellen wenn nicht vorhanden
  if frmSettings = nil then
    begin
      frmSettings := TfrmSettings.Create(nil);
    end;

  // Eigenschaften des Einstellungen-Formulars setzen
  with frmSettings do
    begin
      // Dialog modal anzeigen
      ShowModal;
    end;
end;

// Unit für das Formular
procedure TfrmSettings.FormCreate(Sender: TObject);
begin
  BorderIcons := [biSystemMenu];
  BorderStyle := bsSingle;
  Caption     := 'Einstellungen'; // <-- Es macht keinen Unterschied ob ich das hier setze 
                                  // oder direkt im OI, das Ergebnis ist dasselbe
  // Fensterposition setzen
  Position    := poMainFormCenter;
end;

Zitat von Luckie:

Castet man den Unicode String vorher nicht nach Ansi ist eben nach dem ersten Zeichen schluss mit der Ausgabe.

Ich fürchte genau das passiert bei mir. Wie caste ich denn einen Unicode-String? Versucht habe ich es bereits mit PChar(), PWideChar(), PAnsiChar() und noch ein paar anderen Varianten...

Gruss
Dieter

[Sepp]

Hallo Ringli

Zitat:

Wie caste ich denn einen Unicode-String? Versucht habe ich es bereits mit PChar(), PWideChar(), PAnsiChar() und noch ein paar anderen Varianten...

Versuch es mal so

Delphi-Quellcode:

// Aufruf des Formulars in der Mainunit des AddIns
function TDelphiConnect.ShowConfigDialog(hWndOwner: LongWord): HResult;
begin
  // Form erstellen wenn nicht vorhanden
  if frmSettings = nil then
    begin
      frmSettings := TfrmSettings.Create(Application);
    end;

  // Eigenschaften des Einstellungen-Formulars setzen
  with frmSettings do
    begin
      // Dialog modal anzeigen
      ShowModal;
    end;
end;

// Unit für das Formular
procedure TfrmSettings.FormCreate(Sender: TObject);
begin
  BorderIcons := [biSystemMenu];
  BorderStyle := bsSingle;
  Caption     := Widestring('Einstellungen'); // <-- Es macht keinen Unterschied ob ich das hier setze
                                  // oder direkt im OI, das Ergebnis ist dasselbe
  // Fensterposition setzen
  Position    := poMainFormCenter;
end;
(*
//oder mit Umwandlung nach Ansi String
// Unit für das Formular
procedure TfrmSettings.FormCreate(Sender: TObject);
Var
s : String;
begin
  BorderIcons := [biSystemMenu];
  BorderStyle := bsSingle;
  s := 'Einstellungen'; // Durch die Zuweisung wandelt Dephi im Hintergrund einen Widstring zu Ansi
  Caption     := s; // <-- Es macht keinen Unterschied ob ich das hier setze
                                  // oder direkt im OI, das Ergebnis ist dasselbe
  // Fensterposition setzen
  Position    := poMainFormCenter;
end;*)

Grüße

Sepp

[ringli]

Hallo Sepp!

Weder
Caption := Widestring('Einstellungen'); noch

Delphi-Quellcode:

s       := 'Einstellungen'; 
Caption := s;

sind die Lösung des Problems.

Gruss
Dieter

[EDIT]
Habe das hier völlig übersehen:
frmSettings := TfrmSettings.Create(Application); Wenn ich diese Zeile entsprechend von nil auf Application geändert habe bekomme ich nur diesen Fehler:

Code:

[Fehler] Connect.pas(164): E2010 Inkompatible Typen: 'TComponent' und 'TGUID'

[Sepp]

Hallo Ringli

das deutet drauf hin, dass dein Formular wohl kein von TForm abgeleitetes ist.
Um da mehr zu sagen müsste man den Aufbau kennen.

Grüße
Sepp

[ringli]

Inzwischen bin ich mit Sepp's Hilfe der Lösung des Problems etwas näher gekommen. Anscheinend ist der verwendete Compiler schuld.

Das Projekt ist ursprünglich mit Delphi 2005PE erstellt worden und verursacht hier auch die beschriebenen Probleme. Der selbe Code läuft aber unter D6 Pro und Delphi 7 PE problemlos, d.h. die Caption des Fensters ist komplett sichtbar.

Die Vermutungen gingen erst in Richtung des Delphi 2005 Pro-Importers für die Typbibliothek. Daraufhin habe ich die für das Projekt benötigte Typbibliothek auch mal mit D7PE importiert und anschliessend das Projekt auch hiermit kompiliert. Und siehe da die Anzeige der Titelleiste passte.

Habe ich die mit D7PE importierte Typbibliothek in D2005 verwendet und das Projekt neu erzeugt, passte die Titelleiste wieder nicht.

Ein Diff-Vergleich der importierten Typbibliotheken (D7PE/D2005Pro) brachte nur zwei unterschiedliche Zeilen hervor die bei einer Anpassung das Problem auch nicht gelöst haben.

Der Code in der D7PE-Typelib sieht so aus:

Code:

dtlServerPage = 'ActiveX'; 
dtlOcxPage = 'ActiveX';

Und das Gegenstück in der D2005-Typelib:

Code:

dtlServerPage = '(none)'; 
dtlOcxPage = '(none)';

Es scheint sich also um einen Bug in Delphi 2005-Compiler zu handeln und ich kann nur hoffen das es hierfür noch einen Bugfix geben wird...