Standardeigenschaften von Label ändern

raidy · Hält's aus hier Beiträge: 7

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 · Verfasst: Do 24.01.13 23:53

Eine eigene Komponente angeleitet von TLabel im Constructor, andere Optionen wird es IMHO nicht geben.

_________________
Das Problem liegt üblicherweise zwischen den Ohren H₂♂
DRY DRY KISS

elundril · Verfasst: 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

_________________

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

Blawen · Verfasst: 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.

_________________
Es kompilert, wir können ausliefern.
Und es kompiliert wieder - das Update ist fertig - bitte 100 Euro ;-)

raidy · Hält's aus hier Beiträge: 7

danke erst mal

ich hab noch delphi 7 enterprise da wir des in der schule benutzen

D
könnte mir einer sagen wo ich den Quelltext der Komponenten-Units finde? :S

WasWeißDennIch · Beiträge: 653 Erhaltene Danke: 160

<Delphi>\Source\Vcl\StdCtrls.pas, da sollte TLabel (und auch TCustomLabel) zu finden sein.

Gerd Kayser · Verfasst: Fr 25.01.13 10:26

Erstelle Dir eine eigene Label-Komponente, bei der Autosize auf false gesetzt ist. Siehe z. B. hier: www.delphi-treff.de/...en/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 · Beiträge: 653 Erhaltene Danke: 160

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:

markieren

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:

markieren

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 · Verfasst: 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 · Beiträge: 653 Erhaltene Danke: 160

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 · Hält's aus hier Beiträge: 7

Dankeschön

Werds heute Abend mal ausprobieren

hansa · Beiträge: 3079 Erhaltene Danke: 9

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.

markieren

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;
// usw.
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.

_________________
Gruß
Hansa

WasWeißDennIch · Beiträge: 653 Erhaltene Danke: 160

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 · Verfasst: 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 · Verfasst: 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.

_________________
Toleranz ist eine Grundvoraussetzung für das Leben.

hansa · Beiträge: 3079 Erhaltene Danke: 9

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 :

markieren

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.

_________________
Gruß
Hansa

WasWeißDennIch · Beiträge: 653 Erhaltene Danke: 160

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 · Hält's aus hier Beiträge: 7

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 · Beiträge: 653 Erhaltene Danke: 160

Wie, wo? In welcher Unit? Für welchen der gezeigten Wege hast Du Dich entschieden?

raidy · Hält's aus hier Beiträge: 7

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

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme