Merkwürdiger TFontDialog

[Ghostwalker]

Servus,

ich hab folgende Funktion (abgespeckt):

Delphi-Quellcode:

function EditFont(AFont:TFont):boolean;
var
  dlg : TFontDialog;
begin
  result := false;
  dlg := VCL.Dialogs.TFontDialog.Create(NIL);
  if (dlg.Execute) then
    result := true;
  dlg.Free;
end;

Sobald ich das Teil aufrufe, semmelt mir das ganze mit einer Zugriffsverletzung beim dlg.execute.

Kann sich das einer erklären ????????

[FaTaLGuiLLoTiNe]

Schonmal versucht dem Create entweder das aufrufende Formular oder einfach

Delphi-Quellcode:

Application

mitzugeben?

[himitsu]

oder Screen.ActiveForm

Und dem Execute vieler VCL-Dialoge kann man auch noch ein Handle mitgeben. (der Form, vor welcher es liegen soll)
z.B. Screen.ActiveForm.Handle oder Application.MainForm.Handle (wäre aber blöd, wenn da gerade ein anderer Dialog/ShowModal aktiv ist und die MainForm sperrt) oder Self.Handle (aus einer EventMethode eines Formulars)

[Ghostwalker]

Jup....alles schon probiert.

Interressanterweise funktioniert das ganze mit einem TColorDialog.....

[MichaelT]

Geht. Allein wenn man dlg.Font:=nil setzt dann kommt bei mir eine Exception 'cannot assign nil to a TFont'

Ansonsten läuft das bei mir hier einwandfrei.

Ich gehe jetzt mal davon aus, dass du Tokyo nimmst. Arbeitest du mit Styles?

Zitat:

Zitat von Ghostwalker (Beitrag 1398092)

Servus,

ich hab folgende Funktion (abgespeckt):

Delphi-Quellcode:

function EditFont(AFont:TFont):boolean;
var
  dlg : TFontDialog;
begin
  result := false;
  dlg := VCL.Dialogs.TFontDialog.Create(NIL);
  if (dlg.Execute) then
    result := true;
  dlg.Free;
end;

Sobald ich das Teil aufrufe, semmelt mir das ganze mit einer Zugriffsverletzung beim dlg.execute.

Kann sich das einer erklären ????????

[Ghostwalker]

Sowohl mit also auch ohne Styles bekomme ich den Fehler.

Wie du siehst, weiße ich dlg.font nix zu, steht also auf dem Default-Wert des Dialogs beim erzeugen.

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1398109)

Sowohl mit also auch ohne Styles bekomme ich den Fehler.

Wie du siehst, weiße ich dlg.font nix zu, steht also auf dem Default-Wert des Dialogs beim erzeugen.

ka.. vielleicht geht das?

Delphi-Quellcode:

dlg := VCL.Dialogs.TFontDialog.Create(self);

eventuell holt er sich dann die Font Informationen aus der Main Class bzw. deiner Form.
Ist aber auch möglich das ich quatsch rede ;)

Einen Font zuweisen bevor du den Dialog(Execute) ausführst?

Delphi-Quellcode:

dlg.Font := Form1.Font;

gruss

[Delphi.Narium]

Kann den Fehler hier nicht nachvollziehen.

Bau bitte mal ein Minimalprogramm mit reproduzierbarem Fehler und hänge die Exe hier an. (Und eventuell den Source, damit man, bei auftretendem Fehler in der Exe, es mal mit 'nem anderen Delphi kompilieren kann.)

Eventuell ist es ja kein Programmierfehler, sondern irgendwie systemabhängig. Das könnte man dann so mal testen.

Frei nach dem Motto: Kracht die Exe nur bei Dir oder bei allen, die sie mal starten.

Wer testet schreibt hier dann kurz:

Geht mit Windowsversion.

oder eben:

Geht nicht mit Windowsversion.

oder:

kompiliert mit Delphi xy, Windowsversion, Fehler tritt auf / tritt nicht auf

[MichaelT]

War allein ein Hinweis, wenn bei mir überhaupt eine Exception auftritt.

Dann brauchen wir ein Cut Down und eine Executable bei der das Problem auftritt.

Ich kann man nur erinnern, Forum Github. Es gibt einen Hinweis ganz unten auf 10.2.2.

Du sagst bei anderen Dialogen tritt das Problem nicht auf? Das kommt mir seltsam vor. Sonst würde ich auf die Registrierung der Hooks tippen.

High DPI?

Zitat:

Zitat von Ghostwalker (Beitrag 1398109)

Sowohl mit also auch ohne Styles bekomme ich den Fehler.

Wie du siehst, weiße ich dlg.font nix zu, steht also auf dem Default-Wert des Dialogs beim erzeugen.

[jaenicke]

An welcher Stelle kommt denn die Exception im Execute? Wie sieht der Stacktrace dazu aus?

[KodeZwerg]

Bevor ich wieder mit Kanonen auf Spatzen schieße, ich kenne TFontDialog noch nicht aber ich weiß wie ich alle registrierten Fonts in eine Auswahl-Box bekomme, falls das helfen kann pieps einmal.

[Ghostwalker]

Zitat:

Zitat von jaenicke (Beitrag 1398133)

An welcher Stelle kommt denn die Exception im Execute? Wie sieht der Stacktrace dazu aus?

An welcher Stelle im Execute kann ich nicht sagen, da in der Starter keine Sourcen da sind :)

Ich hab mal einige weitere Tests gemacht:

1. Extra Testprogrämmchen -> TFontDialog drauf -> Button drauf -> funktioniert
2. Extra Testprogrämmchen -> Button drauf -> funktion reinkopiert -> funktioniert.

Ok...das Problem tritt also nur im Haupprojekt auf. Also dacht ich, ok...vielleicht ein Resourcen/Speicherpropblem.

Hab dann das Programm außerhalb der IDE gestartet -> Der TFontdialog funktioniert !!!

Das problem tritt also nur im Projekt innerhalb der IDE auf. was das ganze noch merkwürdiger macht.

@MichaelT

Der Kommentar bezieht sich auf die zusätzlichen Style-Utils, die ich aber hier nicht verwende. :)

@KodeZwerg

Wenn alle Stricke reisen muss ich mir da wohl einen eigenen Font-Dialog bauen. Ich hatte eigentlich
gehofft, das vermeiden zu können.

[jaenicke]

Zitat:

Zitat von Ghostwalker (Beitrag 1398149)

An welcher Stelle im Execute kann ich nicht sagen, da in der Starter keine Sourcen da sind :)

Das nicht, aber wenn du dort anhältst, solltest du eine Fehlerposition im Assemblercode und mit aktivierten Debug-DCUs auch einen passablen Stacktrace bekommen.

[uligerhardt]

Ist's ein Konsolen-, VCL- oder sonst ein Projekt? Und wann im Ablauf wird die Funktion aufgerufen? Ich hatte mal das Problem, dass ich einen OpenDialog vorm Anzeigen der MainForm gebraucht habe. Da musste ich irgendwas mit CoInitialize oder uses ComObj rumtricksen. KA, wieweit das den FontDialog betrifft.

[Ghostwalker]

Callstack:

Code:

:529ad236 ; C:\WINDOWS\SysWOW64\fms.dll
:529b5e2e ; C:\WINDOWS\SysWOW64\fms.dll
:529ac9f4 ; C:\WINDOWS\SysWOW64\fms.dll
:529abfc4 ; C:\WINDOWS\SysWOW64\fms.dll
:529abead ; C:\WINDOWS\SysWOW64\fms.dll
:529abe3d ; C:\WINDOWS\SysWOW64\fms.dll
:529abab4 ; C:\WINDOWS\SysWOW64\fms.dll
:529ab942 ; C:\WINDOWS\SysWOW64\fms.dll
:529a85bc ; C:\WINDOWS\SysWOW64\fms.dll
:529a84bd ; C:\WINDOWS\SysWOW64\fms.dll
:529b287e ; C:\WINDOWS\SysWOW64\fms.dll
:77aee904 ; C:\WINDOWS\SysWOW64\comdlg32.dll
:77aaefe6 ; C:\WINDOWS\SysWOW64\comdlg32.dll
:77aaeef0 comdlg32.ChooseFontW + 0x40
:00559d47 TCommonDialog.TaskModalDialog + $5B
:0055a494 TFontDialog.Execute + $184
:00559be8 TCommonDialog.Execute + $38
devvst.TForm9.Button5Click($7FDC9810)
:005298c1 TControl.Click + $79
:0052df38 TWinControl.WndProc + $640
:00545905 TButtonControl.WndProc + $71
:0052e09c DoControlMsg + $28
:0052df38 TWinControl.WndProc + $640
:0052d503 TWinControl.MainWndProc + $2F
:004c865a StdWndProc + $16
:75a6e0bb USER32.AddClipboardFormatListener + 0x4b
:75a78849 ; C:\WINDOWS\SysWOW64\USER32.dll
:75a7b145 ; C:\WINDOWS\SysWOW64\USER32.dll
:75a7a89c ; C:\WINDOWS\SysWOW64\USER32.dll
:75a5b95b USER32.SendMessageW + 0x5b
:72036934 ; C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.16299.309_none_5d7d0b9ba7da9417\COMCTL32.dll
:7204c14b ; C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.16299.309_none_5d7d0b9ba7da9417\COMCTL32.dll
:75a6e0bb USER32.AddClipboardFormatListener + 0x4b
:75a78849 ; C:\WINDOWS\SysWOW64\USER32.dll
:75a7b145 ; C:\WINDOWS\SysWOW64\USER32.dll
:75a7833a ; C:\WINDOWS\SysWOW64\USER32.dll
:75a5fbab USER32.CallWindowProcW + 0x1b
:0052e047 TWinControl.DefaultHandler + $EB
:0052df38 TWinControl.WndProc + $640
:00545905 TButtonControl.WndProc + $71
:004c865a StdWndProc + $16
:75a6e0bb USER32.AddClipboardFormatListener + 0x4b
:75a78849 ; C:\WINDOWS\SysWOW64\USER32.dll
:75a7b145 ; C:\WINDOWS\SysWOW64\USER32.dll
:75a690dc ; C:\WINDOWS\SysWOW64\USER32.dll
:75a68c20 USER32.DispatchMessageW + 0x10
:005df964 TApplication.ProcessMessage + $F8

CPU:

Zitat:

529AD236 663978FC cmp [eax-$04],di
529AD23A 7525 jnz $529ad261
529AD23C 668B48FE mov cx,[eax-$02]
529AD240 8AF1 mov dh,cl
529AD242 8AD5 mov dl,ch
529AD244 0FB7DA movzx ebx,dx
529AD247 83FB01 cmp ebx,$01
529AD24A 0F85EC000000 jnz $529ad33c
529AD250 0FB710 movzx edx,[eax]
529AD253 8B4DF0 mov ecx,[ebp-$10]
529AD256 2355F4 and edx,[ebp-$0c]
529AD259 234DF4 and ecx,[ebp-$0c]
529AD25C 663BD1 cmp dx,cx
529AD25F 741C jz $529ad27d
529AD261 83C00C add eax,$0c
529AD264 83EE01 sub esi,$01
529AD267 75CD jnz $529ad236
529AD269 3975FC cmp [ebp-$04],esi
529AD26C 0F8496900000 jz $529b6308
529AD272 33C0 xor eax,eax

Wobei er im Quelltext beim Routinen-Aufruf steht.

[Ghostwalker]

Zitat:

Zitat von uligerhardt (Beitrag 1398165)

Ist's ein Konsolen-, VCL- oder sonst ein Projekt? Und wann im Ablauf wird die Funktion aufgerufen? Ich hatte mal das Problem, dass ich einen OpenDialog vorm Anzeigen der MainForm gebraucht habe. Da musste ich irgendwas mit CoInitialize oder uses ComObj rumtricksen. KA, wieweit das den FontDialog betrifft.

Normales VCL-Projekt, wird bei einem Button-Click ausgeführt. Es ist also alles bereits am Laufen :)

[uligerhardt]

Zitat:

Zitat von Ghostwalker (Beitrag 1398167)

Normales VCL-Projekt, wird bei einem Button-Click ausgeführt. Es ist also alles bereits am Laufen :)

Was du wieder für Zeug findest. :mrgreen:

[KodeZwerg]

Da ich vorgegebene Dialoge meist eh meide, hier kleine Schnippsel zum selber basteln.

Delphi-Quellcode:

// Style der Listbox sollte lbOwnerDrawVariable sein damit jeder Eintrag eine eigene Schrift hat

procedure TForm1.ListBox1DrawItem(Control: TWinControl; Index: Integer;
  Rect: TRect; State: TOwnerDrawState);
begin
 With ListBox1 do
 begin
   canvas.fillrect(rect);
   canvas.font.Style := [fsbold];
   canvas.font.Name := Listbox1.items[index];
   canvas.textout(rect.left,rect.top, Listbox1.items[index]);
 end;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  ListBox1.Items := Screen.Fonts;
end;

procedure TForm1.ListBox1Change(Sender: TObject);
begin
  Label1.Font.Name := ListBox1.Items[ListBox1.ItemIndex];
end;

Zweite Variante wo man selbst per Callback durchiteriert.

Delphi-Quellcode:

function EnumFontClBack(var lp:TEnumLogFont;
                      var tm: TNewTextMetric;
                      dwType:DWord;
                      lpData:LParam): integer; stdcall;
begin
  result:=1;
  with TForm1(lpData),Combobox1 do
  begin
    items.add(lp.elfLogFont.lfFaceName);
  end;
end;

procedure TForm1.FormShow(Sender: TObject);
begin
  EnumFontFamilies(canvas.Handle,nil,@EnumFontClBack,Integer(self));
end;

procedure TForm1.ComboBox1Change(Sender: TObject);
begin
 Label1.Font.Name:=Combobox1.Text;
end;

[Sherlock]

Oh je, das ist ein wenig OT, aber ich würde gerne eine Lanze für "vorgefertigte Dialoge" brechen: Die Dinger gibt es, damit sich Anwender nicht in jedem Programm an neue Dialoge für das gleiche Ding gewöhnen müssen. Ausserdem muß auch der Entwickler nicht bei jeder Änderung an diesem Ding (die selbstverständlich bei jedem OS-Update oder auch jedem Sprach-Update geschehen können) um ein eventuell anfallendes Redesign kümmern. Es ist Merkmal eines jeden guten Frameworks diese Arbeit abzunehmen, damit der Entwickler sich auf das eigentliche Rad konzentrieren kann, daß er da erfinden möchte, und nicht alle anderen bereits erfundenen Räder dutzendfach neuinterpretiert.

Sorry Daniel, das musste sein.

Sherlock

[himitsu]

Da es in der VCL knallt, würde ich auch mal die Debug-DCUs in den Projektoptionen aktivieren ... dann sieht man im Debugger auch ein Bissl mehr.

[uligerhardt]

Zitat:

Zitat von Sherlock (Beitrag 1398173)

Oh je, das ist ein wenig OT, aber ich würde gerne eine Lanze für "vorgefertigte Dialoge" brechen: Die Dinger gibt es, damit sich Anwender nicht in jedem Programm an neue Dialoge für das gleiche Ding gewöhnen müssen. Ausserdem muß auch der Entwickler nicht bei jeder Änderung an diesem Ding (die selbstverständlich bei jedem OS-Update oder auch jedem Sprach-Update geschehen können) um ein eventuell anfallendes Redesign kümmern. Es ist Merkmal eines jeden guten Frameworks diese Arbeit abzunehmen, damit der Entwickler sich auf das eigentliche Rad konzentrieren kann, daß er da erfinden möchte, und nicht alle anderen bereits erfundenen Räder dutzendfach neuinterpretiert.

Sorry Daniel, das musste sein.

Sherlock

Full ACK

[uligerhardt]

Zitat:

Zitat von himitsu (Beitrag 1398175)

Da es in der VCL knallt, würde ich auch mal die Debug-DCUs in den Projektoptionen aktivieren ... dann sieht man im Debugger auch ein Bissl mehr.

Die hat man doch immer aktiv. :cyclops:

[KodeZwerg]

Zitat:

Zitat von uligerhardt (Beitrag 1398176)

Zitat:

Zitat von Sherlock (Beitrag 1398173)

Oh je, das ist ein wenig OT, aber ich würde gerne eine Lanze für "vorgefertigte Dialoge" brechen: Die Dinger gibt es, damit sich Anwender nicht in jedem Programm an neue Dialoge für das gleiche Ding gewöhnen müssen. Ausserdem muß auch der Entwickler nicht bei jeder Änderung an diesem Ding (die selbstverständlich bei jedem OS-Update oder auch jedem Sprach-Update geschehen können) um ein eventuell anfallendes Redesign kümmern. Es ist Merkmal eines jeden guten Frameworks diese Arbeit abzunehmen, damit der Entwickler sich auf das eigentliche Rad konzentrieren kann, daß er da erfinden möchte, und nicht alle anderen bereits erfundenen Räder dutzendfach neuinterpretiert.

Sorry Daniel, das musste sein.

Sherlock

Full ACK

Naja, bei mir war es Delphi 6/7 mit seinem TOpenFileDialog (o.ä.), dieses Rad war noch aus Holz wenn nicht gar Stein und ich wollte lieber ein Rad der Neuzeit, so mit Bereifung und Rillen für's Aquaplaning, also weg vom original und Api Dialog der sich dem Betriebssystem anpasst.

[Ghostwalker]

@Himitsu

Jap, die sind an (Debug-DCU). Aber mehr infos hab ich da auch nicht :)

[Ghostwalker]

So...ets schlägts 13.

Wenn ich die Exception ignoriere (Fortfahren -> Bestätigen) und dann den Aufruf wiederhole, funktionierts.

Es ist also immer nur der 1. Aufruf nach dem Programmstart.

Im Anhang noch die Exception-Meldung.

[jaenicke]

Die Meldung bringt nicht viel, aber wenn du dann auf anhalten gehst, wo landest du dann?

[Ghostwalker]

Beim Aufruf von Execute des Dialoges. Ins CPU-Fenster geht er da nicht. :(

[jaenicke]

Sind Debug-DCUs angehakt in den Projektoptionen?

Dann bliebe nur noch manuell in die Assembleransicht zu gehen und mit F7 bis zum Fehler zu steppen.

[Ghostwalker]

Debug-DCU's ist drinn. Bringt aber mit bezug auf die VCL's herlich wenig.

Das ergebnis des zweiten Tipps findest im Anhang.

Die Addresse für den Call ist beim 1. (fehlerhaften) Aufruf und beim zweiten (der dann funktioniert) die gleiche.