Entwickler-Ecke
Grafische Benutzeroberflächen (VCL & FireMonkey) - Standardeigenschaften von Label ändern
raidy - Do 24.01.13 23:12
Titel: Standardeigenschaften von Label ändern
hi,
hab mal ne Frage, und zwar ob man wenn man ein Label erzeugt hat die Standardeigenschaften die im Objektinspector angezeigt werden ändern kann.
Also das zB bei AutoSize wo normalerweise True der Standardwert ist immer wenn man ein neues Label erstellt false angezeigt wird.
hoffe hier kann mir einer helfen ;)
MfG
Moderiert von
Narses: Topic aus Sonstiges (Delphi) verschoben am Fr 25.01.2013 um 15:13
bummi - Do 24.01.13 23:53
Eine eigene Komponente angeleitet von TLabel im Constructor, andere Optionen wird es IMHO nicht geben.
elundril - Fr 25.01.13 00:06
Je nach Delphi-Version ist glaub ich der Quelltext der Komponenten-Units dabei. Da könnte man dann den speziellen Wert ändern und die Unit kompilieren. Wenn man dann die .dcu-Datei ersetzt sollte auch die Komponente in der IDE geändert sein, glaub ich.
lg elundril
Blawen - Fr 25.01.13 00:29
elundril hat folgendes geschrieben : |
Je nach Delphi-Version ist glaub ich der Quelltext der Komponenten-Units dabei. |
Der Nachteil wäre allerdings, dass nach einem Update die Komponente wiederum angepasst werden müsste.
raidy - Fr 25.01.13 00:55
danke erst mal ;)
ich hab noch delphi 7 enterprise da wir des in der schule benutzen :DD
könnte mir einer sagen wo ich den Quelltext der Komponenten-Units finde? :S
WasWeißDennIch - Fr 25.01.13 08:21
<Delphi>\Source\Vcl\StdCtrls.pas, da sollte TLabel (und auch TCustomLabel) zu finden sein.
Gerd Kayser - Fr 25.01.13 10:26
Erstelle Dir eine eigene Label-Komponente, bei der Autosize auf false gesetzt ist. Siehe z. B. hier:
http://www.delphi-treff.de/tutorials/vcl/komponenten-entwicklen/objekthierarchie/
In den Originalsourcen würde ich nicht herumpfuschen.
Aber ob sich der Aufwand dafür lohnt? Man kann schließlich auch ein Label auf dem Formular platzieren, die gewünschte Eigenschaft ändern und anschließend das Label mehrfach auf das Formular kopieren. Oder man platziert mehrere Labels auf dem Formular, selektiert dort alle und ändert die Eigenschaft für alle ausgewählten Labels auf einen Schlag im Objektinspektor mit gerade mal zwei oder drei Mausklicks ...
WasWeißDennIch - Fr 25.01.13 12:28
In den Originalsourcen sollte man eigentlich tunlichst nicht herumpfuschen. Entweder leitet man sich wie bereits erwähnt eine eigene Komponente von TLabel ab und benutzt dann diese, oder man behilft sich zur Laufzeit, indem man entweder mit einer Schleife über die entsprechenden Komponenten iteriert oder auch eine Cracker-Klasse schreibt. Beispiel für die Schleife:
Delphi-Quelltext
1: 2: 3:
| for i := 0 to ComponentCount - 1 do if Components[i] is TLabel then TLabel(Components[i]).Font.Color := clRed; |
Und die Cracker-Klasse:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16:
| type TLabel = class(StdCtrls.TLabel) public constructor Create(AOwner: TComponent); override; end;
TDeinForm = class(TForm) Label1: TLabel; ... end;
constructor TLabel.Create(AOwner: TComponent); begin inherited; Font.Color := clRed; end; |
Ich habe unter Win 8 kein Delphi installiert, daher ungetestet, nach meinem Dafürhalten sollte das aber funktionieren.
jaenicke - Fr 25.01.13 13:15
Funktionieren schon, aber das funktioniert nicht immer, wenn man dann mit TLabel aus anderen Units arbeitet, weil es plötzlich nicht kompatibel ist... Dann muss man überall den Unitnamen davorschreiben. Das Vorgehen hat also nicht nur Vorteile. ;-)
WasWeißDennIch - Fr 25.01.13 13:45
Loriot hat folgendes geschrieben: |
Achwas. |
Es gibt IMO hier keinen "Königsweg", daher muss sich der TE für die eine oder andere gezeigte Vorgehensweise entscheiden. Ich wollte nur weitere Alternativen aufzeigen.
raidy - Fr 25.01.13 16:11
Dankeschön ;)
Werds heute Abend mal ausprobieren
hansa - Fr 25.01.13 16:37
WasWeißDennIch hat folgendes geschrieben : |
Es gibt IMO hier keinen "Königsweg"... |
Doch, würde zumindest mal sagen, eigene Komponente wäre der Königsweg. Zumindest wenn hier schon Fummelei an den Original-VCL-Quellen zur Sprche kommt. Das sind auch nur ein paar Zeilen, ist unabhängig von Delphi Versionen etc.
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22:
| type TMeinLabel = class (TLabel) public constructor Create(AOwner: TComponent); override; end;
procedure Register;
implementation
constructor TMeinLabel.Create(AOwner: TComponent); begin inherited; Height := 33; Color := clRed; end;
procedure Register; begin RegisterComponents('Eigene', [TMeinLabel]); end; |
Ungefähr das in eine Unit schreiben, diese in Package verfrachten, compilieren, installieren und fertig. Aber ohne Gewähr ! Das ist nur aus Kopf raus getippt und nicht getestet.
WasWeißDennIch - Fr 25.01.13 17:01
Nur um bereits vorhandene Eigenschaften zu ändern eine eigene Komponente (die ansonsten keinerlei weitere Funktionalität mitbringt) schreiben und installieren? Bei der überfrachteten Komponentenpalette dürfte Delphi dann irgendwann Stunden zum Laden brauchen, aber Könige haben ja Zeit :roll:
Lemmy - Fr 25.01.13 17:05
hansa hat folgendes geschrieben : |
WasWeißDennIch hat folgendes geschrieben : | Es gibt IMO hier keinen "Königsweg"... |
Doch, würde zumindest mal sagen, eigene Komponente wäre der Königsweg. |
sicher? Und bei der Weitergabe des Projekts an einen anderen Entwickler bekommt der nen Krampfanfall, weil zig "eigene" Komponenten fehlen? Und komm mir nicht mit: dann gibt man die halt weiter. Vergiss es. Das klappt einfach nicht. Kann ich so aus mind. 2 Projekten inzwischen nachweisen: Kein Mensch weiß so recht warum da überhaupt eigene Komponenten entworfen wurden - funktionell unterscheiden die sich nicht von den Standarddingern...
Wegen einer handvoll Einstellungen würde sich eine Funktion anbieten, d.h. man definiert ein Basisformular (Hansa, da kannst Du jetzt auf deinen Artikel über Formvererbung hinweisen :-)) und erbt von dem. Im Basisformular kommt ne Methode rein, die die Komponenten auf dem Formular durchgeht und die entsprechenden Eigenschaften setzt und die wird einmal beim Create aufgerufen. Kann zudem jederzeit beliebig geändert werden...
Grüße
Tranx - Fr 25.01.13 17:22
[quote="
Lemmy"(672707)]
hansa hat folgendes geschrieben : |
WasWeißDennIch hat folgendes geschrieben : | Es gibt IMO hier keinen "Königsweg"... |
Wegen einer handvoll Einstellungen würde sich eine Funktion anbieten, d.h. man definiert ein Basisformular (Hansa, da kannst Du jetzt auf deinen Artikel über Formvererbung hinweisen :-)) und erbt von dem. Im Basisformular kommt ne Methode rein, die die Komponenten auf dem Formular durchgeht und die entsprechenden Eigenschaften setzt und die wird einmal beim Create aufgerufen. Kann zudem jederzeit beliebig geändert werden...
Grüße |
Genau wie Lemmy schrieb:
Entweder das mit der Methode, was auch u.a. den Vorteil bietet, dass man z.B. in Programmoptionen diese Vorgaben definiert und diese dann in der Funktion umgesetzt werden, oder indem man in der Entwurfsphase schon definierte Objekte einfach kopiert. Allerdings würde ich diese Methode im private-Bereich des Formulars extra, außerhalb von Create, definieren und dann in Create aufrufen, damit man ggfs. darauf auch später (manuelle Optionsanpassung) darauf zugreifen kann. Eigene Komponenten sollten wirklich nur wesentliche neue Eigenschaften haben (z.B. TLabelEdit statt TEdit, oder TDBCombobox statt TCombobox, damit die notwendige Anpassung der IDE auf ein Minimum reduziert wird.
hansa - Fr 25.01.13 17:33
Wer ohne Erklärungen Projekt weitergibt, der gehört in der Tat zuerstmal geteert und gefedert. Wo zieht man aber jetzt die Grenze ? Lemmy meint so :
Delphi-Quelltext
1: 2: 3: 4:
| for i := 0 to ComponentCount - 1 do begin c := Components [i]; if c is TMeinLabel then begin (c as TMeinLabel).Caption := (c as TMeinLabel).Caption + ' '; |
Das geht auch. Aber : man merkt zur Designtime nichts davon und das kann schon ein Nachteil sein. Mit ComponentCount und Co., das habe ich mal so gemacht aus folgendem Grund : Touchscreen. Man stelle sich mal vor, man müsste da hunderte Labels (besser gesagt : unbekannte Anzahl) von Hand auf Form platzieren und da einzeln Einstellungen ändern. Geht wohl nicht, also wird das Zeugs zur Laufzeit erst erzeugt und dann kann man die Grundeinstellungen direkt gleich richtig setzen. Allerdings : wenn ich das hier jetzt sehe. Eigene Komponente hätte ja noch den Vorteil, dass man mit
is TMeinLabel irgendwelche Aktionen ja selektiv nur auf die eigene Komponente eingrenzen könnte.
WasWeißDennIch - Fr 25.01.13 17:40
Das kann man aber auch, indem man die entsprechenden Komponenten in eine Liste oder ein Array verfrachtet und das dann durchgeht. Ich bleibe bei meiner Meinung: eine eigene Komponente, die überhaupt keine weitere Funktionalität mitbringt, ist Mumpitz.
raidy - Sa 26.01.13 19:19
mmh sorry wenn ich nochmal frag
aber was muss ich denn bei TLabel im Quellcode hinschreiben damit es standardmäßig auf false ist?
WasWeißDennIch - Sa 26.01.13 23:32
Wie, wo? In welcher Unit? Für welchen der gezeigten Wege hast Du Dich entschieden?
raidy - So 27.01.13 01:00
nja wenn ich die datei öffne <Delphi>\Source\Vcl\StdCtrls.pas
und da bei TLabel des so einstellen will das bei Autosize false standard is ;)
WasWeißDennIch - So 27.01.13 01:27
Willst Du das wirklich? Wie in diesem Thread schon öfter erwähnt ist das die schlechteste aller Möglichkeiten.
hansa - So 27.01.13 02:23
Und das war so zu befürchten. Schreibe da jetzt in den Constructor einfach :
Und denke immer daran : Deine Delphi-Version ist nicht mehr komplett original.
WasWeißDennIch - So 27.01.13 11:49
Sicher, dass das ausreicht? Ich würde zumindest vermuten, dass die enthaltende *.bpl neu kompiliert werden muss.
raidy - So 27.01.13 16:41
mmh also wenn ich nur := false dahinter schreibe ändert sich nix :S
Blawen - So 27.01.13 16:43
raidy hat folgendes geschrieben : |
mmh also wenn ich nur := false dahinter schreibe ändert sich nix :S |
Hast Du die Komponente auch neu kompiliert und eingebunden?
--> Siehe Hinweis von
WasWeißDennIch
raidy - So 27.01.13 19:48
wie mach ich das denn?
sorry hab grad echt kein plan :S
WasWeißDennIch - So 27.01.13 20:42
Du müsstest Dir ein Package erstellen, das dieselben Dateien enthält wie das Original. Wahrscheinlich müsste das dann per Kommandozeile kompiliert werden, da die IDE wohl die Meldung bringen wird, dass die Units bereits in einem geladenen Package enthalten sind. Hast Du das hinbekommen, musst Du sicherheitshalber die originale *.bpl umbenennen und Deine eigene ins selbe Verzeichnis (das müsste {$Delphi}\bin sein) kopieren. Da ich so etwas niemals tue kann es sein, dass das alles noch nicht einmal ausreicht. Daher noch einmal die Warnung: ich würde das auf keinen Fall tun, dabei kann eine Menge schiefgehen, außerdem wundert man sich evtl. später, dass sich Komponenten ganz anders verhalten, als man das kennt. Eine Alternative hätte ich noch: Erstell Dir einfach eine Unit (ich nenne sie hier mal NonAutoSizeLabel.pas) irgendwo im Delphi-Suchpfad mit folgendem Inhalt.
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23:
| unit NonAutoSizeLabel;
interface
uses Classes, StdCtrls;
type TLabel = class(StdCtrls.TLabel) public constructor Create(AOwner: TComponent); override; end;
implementation
constructor TLabel.Create(AOwner: TComponent); begin inherited; AutoSize := false; end;
end. |
So, überall, wo Du das Autosize für Labels initial abstellen möchtest, bindest Du diese Unit als letzte (oder zumindest nach StdCtrls) in der uses-Klausel des interface-Abschnitts ein.
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7:
| unit Main;
interface
uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, NonAutoSizeLabel; |
Das erfüllt im Prinzip denselben Zweck, ohne dass man die Original-Sourcen patchen müsste.
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!