Antialiasing, Kantenglättung für Memo, Edit und Label

[FarAndBeyond]

Hi,
weis jemand von euch wie man aus diesen 3 Prozeduren eine machen kann?
Ich dachte das geht mit Obj: TObject oder Obj: TComponent oder const Obj: TComponentname oder irgendetwas in dieser Richtung...

Delphi-Quellcode:

Procedure Tform_XYZ.AAFontEdit(Obj: TEdit);
   Var
    Font    : TFont;
    LogFont : TLogFont;
 Begin
  Try
   Font := TFont.Create;
   Font.Assign(Obj.Font);
   GetObject(Font.Handle, SizeOf(LogFont), @LogFont);
   LogFont.lfQuality := ANTIALIASED_QUALITY;
   Font.Handle := CreateFontIndirect(LogFont);
   Obj.Font := Font;
   Font.Free;
  Except
   Exit;
  End;
 End;


Procedure Tform_XYZ.AAFontMemo(Obj: TMemo);
   Var
    Font    : TFont;
    LogFont : TLogFont;
 Begin
  Try
   Font := TFont.Create;
   Font.Assign(Obj.Font);
   GetObject(Font.Handle, SizeOf(LogFont), @LogFont);
   LogFont.lfQuality := ANTIALIASED_QUALITY;
   Font.Handle := CreateFontIndirect(LogFont);
   Obj.Font := Font;
   Font.Free;
  Except
   Exit;
  End;
 End;


Procedure Tform_XYZ.AAFontLabel(Obj: TLabel);
   Var
    Font    : TFont;
    LogFont : TLogFont;
 Begin
  Try
   Font := TFont.Create;
   Font.Assign(Obj.Font);
   GetObject(Font.Handle, SizeOf(LogFont), @LogFont);
   LogFont.lfQuality := ANTIALIASED_QUALITY;
   Font.Handle := CreateFontIndirect(LogFont);
   Obj.Font := Font;
   Font.Free;
  Except
   Exit;
  End;
 End;

Schöne Grüsse
Martin

[baumina]

Ich würd TControl nehmen.

[FarAndBeyond]

Danke für deine Antwort.
Ich bekomme aber genau wie bei TObject immer die Fehlermeldung das Obj.Font nicht bekannt ist, also Font nicht bekannt ist.
Ich hab' jetzt folgende Möglichkeit entdeckt:

Delphi-Quellcode:

Procedure AAFont(ObjFont: TFont);
   Var
    LogFont: TLogFont;
 Begin
  Try
   GetObject(ObjFont.Handle, SizeOf(TLogFont), @LogFont);
   LogFont.lfQuality := ANTIALIASED_QUALITY;
   ObjFont.Handle := CreateFontIndirect(LogFont);
  Except
   Exit;
  End;
 End;


Procedure TForm1.FormCreate(Sender: TObject);
 Begin
  AAFont(Button1.Font);
  AAFont(Label1.Font);
  AAFont(Memo1.Font);
  AAFont(Edit1.Font);
 End;

Das funktioniert unter Delphi7 sehr gut und ist deutlich weniger Quelltext.

Gruß
Martin

[Medium]

Für die Zukunft: Wenn du nochmal auf eine gemeinsame Eigenschaft verschiedener Klassen so zugreifen willst, ist es oft sehr wahrscheinlich, dass all diese Klassen irgendwo einen gemeinsamen Vorfahren haben, der die Eigenschaft erstmals eingeführt hat.
Herausfinden kannst du das entweder über die Hilfe (F1 drücken wenn der Cursor z.B. über dem Wort "TEdit" ist), und dann die Vererbungshierachie immer weiter zurück gehen (der Vorfahre ist in der Hilfe meine ich angegeben), bis es den Member "Font" (als Beispiel) nicht mehr gibt. Die Klasse davor notieren, und gucken ob es für alle dieselbe Vorfahrklasse ist.
Eine weitere Möglichkeit ist es direkt im Quellcode der VCL zu wühlen, so man den den hat. (Ab professional Versionen imho.) Dazu einfach Strg-Klick auf z.B. "TEdit" im Codeeditor, und schon springst du zur Deklaration von TEdit, wo auch gleich der direkte Vorfahre mit angegeben ist. (TCustomEdit in diesem Fall.) Dann auf den Vorfahren Strg-Linksklicken - so lange, bis du eine Klasse erreicht hast, in der "Font" hingeschriebenerweise in der Litanei von Properties zu sehen ist. Ebenfalls für alle gewünschten Klassen durchprobieren um sicherzustellen, dass alle von dieser wirklich abstammen.

Bei "Font" könnte es sein (habe kein Delphi hier gerade), dass es in TControl noch nicht, oder aber nicht "public" oder "published" deklariert ist. Alle deine hier gewünschten Klassen sollten aber von TWinControl abgeleitet sein (welches wiederum von TControl abgeleitet ist), und da sollte meiner Meinung nach ein public "Font" deklariert sein.

Deine jetzige Lösung finde ich allerdings noch besser als die ursprünglich gedachte, da du diese Prozedur wirklich für ALLE TFonts benutzen kannst, ganz egal aus welchem Kontext diese nun stammen. Aber mit der Ableitungshierache lohnt es sich trotzdem zu beschäftigen, vielleicht ist ein Büchlein über OOP auch nicht verkehrt, da sich das quer durch alle moderneren Programmiersprachen zieht, und die Grundfeste dieser ist. (Zumindest der OOP-Sprachen (Delphi, C++, C#, Java, etc.), die nicht umsonst so heissen )

(Ich benutze zu viele Klammern.)

[FarAndBeyond]

@Medium:
Hey, danke für die ausführliche Antwort...

Ja x Zwei...

Erstens: Ja, ich sollte endlich mal den Windows7 Patch installieren, damit ich die Hilfe nutzen kann. Bin kein Fan von Windows-Updates. Werd' morgen mal sehen wie gross das Ding ist.

Zweitens: Ja, ich sollte mir mal Klassen und OOP im Allgemeinen 'reinziehen, hab' das bisher geschickt links liegen gelassen...

Werd' STRG+Klick und F1 mal testen...
Hab' gerade angefangen mir mal ShortCuts anzusehen : STRG+Y, STRG+Space usw.

Nochmal Danke...

Gruß
Martin

[uligerhardt]

Zu deiner ursprünglichen Frage: Der Standardtrick in Delphi ginge so:

Delphi-Quellcode:

type
  TControlAccess = class(TControl);

procedure DoSomething(AControl: TControl);
begin
  TControlAccess(AControl).Font.Size := 12;
end;

[FarAndBeyond]

@uligerhardt
Hey, danke Mann...
Das funzt ja prächtig!!!
Dachte zuerst da fehlt doch was bei 'Type', sieht so nach gar nichts aus...
Irre praktisch...

Delphi-Quellcode:

//Type
// TControlAccess = Class(TControl);

Procedure AAFont(Obj: TControl);
   Var
    Font : TFont;
    LogFont : TLogFont;
 Begin
  Try
   Font := TFont.Create;
   Font.Assign(TControlAccess(Obj).Font);
   GetObject(Font.Handle, SizeOf(LogFont), @LogFont);
   LogFont.lfQuality := ANTIALIASED_QUALITY;
   Font.Handle := CreateFontIndirect(LogFont);
   TControlAccess(Obj).Font := Font;
   Font.Free;
  Except
   Exit;
  End;
 End;


Procedure TForm1.Button1Click(Sender: TObject);
 Begin
  AAFont(Label1);
  AAFont(Memo1);
 End;

Das wäre dann die Lösung für den ursprünglichen Quelltext...
ODER noch besser SO...

Delphi-Quellcode:

//Type
// TControlAccess = Class(TControl);

Procedure AAFont(Obj: TControl);
   Var
    LogFont: TLogFont;
 Begin
  Try
   GetObject(TControlAccess(Obj).Font.Handle, SizeOf(TLogFont), @LogFont);
   LogFont.lfQuality := ANTIALIASED_QUALITY;
   TControlAccess(Obj).Font.Handle := CreateFontIndirect(LogFont);
  Except
   Exit;
  End;
 End;


Procedure TForm1.Button1Click(Sender: TObject);
 Begin
  AAFont(Label1);
  AAFont(Memo1);
 End;

Klasse Sache... mit D7 geht's...

Gruß
Martin

[Dalai]

Und wenn du jetzt noch die Exceptions anzeigen lassen würdest (oder sie wenigstens protokollieren), statt sie komplett kommentarlos zu verwerfen, könnte man auch sehen, was genau schiefgeht, wenn etwas schiefgeht. Hat zwar mit dem Thema nichts zu tun, aber man kann es gar nicht oft genug sagen, dass man Exceptions bis auf ganz ganz ganz wenige Ausnahmen nicht unterdrücken/verwerfen sollte.

MfG Dalai

[FarAndBeyond]

@Dalai
Ja, das Thema Exception-Handling ist gerade voll mein Ding, da ich mein erstes richtiges Programm fertiggestellt habe und jetzt genau vor der Frage stehe was genau abgesichert werden sollte und was Overkill ist und wie ich das Ganze am besten anpacke.

Ich hab' leider kein einziges komplettes, ganzheitliches Tutorial zu dem Thema gefunden. Es gibt "try - except - end" und "try - finally - end" und ja man kann diese auch auf mehrfache, verschiedene Weise verschachteln... aber bezogen auf die echte Praxis bringen solche Tutorials gar nichts! Es bleiben viel zu viele Fragen offen und ein richtiges Programm besteht auch nicht aus nur einer Prozedur.

Beispiel:
1)Ich hab' in FormClose mehrere Dinge abzuarbeiten. Damit das möglichst maximal läuft muß ich alle Prozeduren in sehr kleine Prozeduren unterteilen. Nur so kann ich das maximal mögliche auch wirklich sichern. Wenn also 10 Dinge gespeichert werden sollen und es zu einer Exception kommt bei Ding Nr. 1 dann wird logischerweise gar nichts gespeichert.
Wenn ich allerdings jeden Schritt in kleine Prozeduren packe, die wiederum abgesichert sind, dann kann ich bei einer Exception bei Ding Nr. 1 immerhin noch 9 Dinge sichern.
Fazit: Kleine Prozeduren sich ganz offensichtlich besser, aber auch mehr Arbeit.

2)Nach einem Except sollte man wohl tunlichst nur abgesicherte Prozeduren einsetzen, denn was ist wenn nach einer Exception das was abgearbeitet werden soll wieder zu einer
Exception führt?
Fazit: Also wenn schon, dann auch ganzheitlich und überall, ansonsten kann man es auch gleich ganz lassen... oder was???

3)Ich unterteile grundsätzlich alles in zwei Kategorien: 1. Eine Exception würde die Grundfunktion des Programmes nicht beeinträchtigen und 2. Eine Exception würde die Programmausführung unmöglich oder unhandlich werden lassen. Und darüber hinaus stellt sich noch die Frage braucht mein Programm eine StatusBar oder einen ErrorLog, dann muß das logischerweise auch im Exception-Handling mit berücksichtigt werden.

4)Wie sieht das aus wenn ich in OnDestroy etwas freigeben möchte aber z.B. in OnClose nichts gemacht wird. Schreibe ich jetzt "try-except-end" in ein leeres OnClose nur um sicherzugehen, dass ich das OnDestroy auch in jedem Fall erreichen kann. Kann es sein, dass verschiedene Programme oder Treiber eine Exception verursachen während sich das Programm gerade in OnClose oder OnDeaktivate befindet. Klingt natürlich schräg, da ja gar nichts abzuarbeiten ist... die Prozeduren gibt es ja eigentlich gar nicht... !?
Aber als Anfänger sich das genau die Fragen die einen beschäftigen...

5)Ich hab' noch nie eine Fehlermeldung vom OS bekommen die mir tatsächlich wirklich weitergeholfen hätte, also verstehe ich logischerweise nicht warum ich diese nicht komplett verhindern sollte und gegen richtige, eigene austauschen sollte. Der Einzige, der vielleicht ein klein Wenig mit "Fehler in Adresse Blabla.. Read BlaBla" anfangen könnte, wäre wohl ein AssemblerProgrammierer, aber der kann mir dann auch nicht sagen in welcher Prozedur das passiert ist. Ich hab' mir 'ne Mini-Prozedur gebaut, die ein echtes NotifyWindow erstellt um dann eine schöne, verständliche und saubere ErrorMeldung ausgeben zu können.
Also :
1) Topmost, 2) Nur schließbar mit CTRL+ALT+O+K, 3) Kein Button, Kein Alt-F4, Kein X rechts oben zum Schliessen..., 4) Ordentliches Deutsch oder English das man auch versteht + die Prozedur ist mit angegeben (was aber wieder zu noch mehr Arbeit führt und noch kleinere Prozeduren hervorbringen würde bzw. hervorbringt).

Eine Meldung, die nicht topmost ist bekomme ich oft erst nachdem ich mehrere Fenster geschlossen habe zu Gesicht und eine Meldung, die weggeklickt werden kann oder durch einmal zu oft ALT+F4 drücken verschwindet ohne gelesen zu werden ist ebenfalls untragbar...
Es gibt zu viele Programmierer die das so machen und ich verstehe nicht was das soll. Sauber ist was anderes...

Solche und andere Fragen stellen sich logischerweise jedem, der mal ein Programm schreibt und das zum ersten Mal macht...
Wo ist jetzt das Tutorial das ganzheitlich auf diese Dinge eingeht???
Ich hatte bis jetzt noch kein Glück so eins zu finden, aber vielleicht hab' ich die falschen Suchbegriffe eingegeben...

Gruß
Martin

[Dalai]

Zitat von FarAndBeyond:

Es gibt "try - except - end" und "try - finally - end"

Das stimmt. Aber try..finally hat nichts mit Exceptions zu tun! Das ist ein Ressourcenschutzblock und wird immer ausgeführt, egal was zwischen try und finally passiert, auch dort auftretende Exceptions ändern daran nichts. Übliche Verwendung eines try..finally :

Delphi-Quellcode:

var Lobject: TObject;
begin
  Lobject:= TObject.Create;
  try
    MachWas(Lobject);
  finally
    Lobject.Free;
  end;
end;

Egal, was nun in MachWas passiert, das Objekt wird mit Sicherheit freigegeben.

Anders ist das bei try..except . Dieses Konstrukt ist zum Fangen von Exceptions da. shmia hat dazu ein IMO wunderbares Tutorial geschrieben, wie man mit dem Konstrukt und Exceptions an sich umgehen sollte. Wichtigster Rat daraus: Exceptions mit eigenen, wichtigen und nützlichen Informationen anreichern, die bei der Fehlersuche und dessen Ursache(n) helfen können.

Zitat:

4)Wie sieht das aus wenn ich in OnDestroy etwas freigeben möchte aber z.B. in OnClose nichts gemacht wird. Schreibe ich jetzt "try-except-end" in ein leeres OnClose nur um sicherzugehen, dass ich das OnDestroy auch in jedem Fall erreichen kann.

Nein. Warum sollte eine leere Funktion eine Exception werfen?

Zitat:

Kann es sein, dass verschiedene Programme oder Treiber eine Exception verursachen während sich das Programm gerade in OnClose oder OnDeaktivate befindet.

Ja, das kann passieren, wobei das nicht auf die genannten Funktionen/Events beschränkt ist. Und "verursachen" ist der falsche Begriff, denn verursacht werden können Exceptions (AFAIK) nicht von externer Seite, nur ausgelöst durch irgendwelche Zustände, mit denen der eigene Code nicht klarkommt und dieser dann eine Exception auslöst.

Ich hatte nun schon mehrfach den Fall, dass sich irgendein anderes auf einem fremden Rechner laufendes Programm in die Exceptionhandler-Kette reinhing, so dass mein eigener nicht auslöste. Das führte dummerweise zum Absturz meiner Software, und ich konnte noch nicht einmal diagnostizieren, wer dafür verantwortlich ist/war und wie ich es beheben sollte. Sowas ist richtig Scheiße. Ändert aber nichts an der Wichtigkeit eigener Exceptionhandler.

Zitat:

5)Ich hab' noch nie eine Fehlermeldung vom OS bekommen die mir tatsächlich wirklich weitergeholfen hätte

Glaub mir: Du wirst diese (vermeintlich) nichtssagenden Dinger irgendwann zu schätzen wissen, denn nur damit kann man sich auf die Suche begeben, sei es nun im eigenen Code oder im Internet. Oft ist es so, dass andere Leute bereits etwas zu einer bestimmten Meldung geschrieben haben, wodurch sie ausgelöst werden kann, und - mit etwas Glück - wie man sie vermeiden bzw. beheben kann.

Zitat:

Der Einzige, der vielleicht ein klein Wenig mit "Fehler in Adresse Blabla.. Read BlaBla"

Ja, nun, mit dieser Art von Meldungen kann ich auch nichts anfangen. Deswegen ja: Exceptions beim Auftreten mit eigenen nützlichen Infos anreichern und erneut werfen; das kann auch den Funktionsname beinhalten, so dass man genau weiß, wo man suchen muss.

Oh, jetzt hab ich so viel dazu geschrieben, dass es wohl sinnvoll wäre, meinen Beitrag (und den beantworteten) in ein neues Thema zu verschieben. Könnte man "Exceptions, die Xte" nennen .

MfG Dalai