String Entscheidungen mit case treffen!!!

[Hansa]

Zitat von Hawkeye219:

...Die Tag-Lösung ist eigentlich auch nur eine halbe, weil der Objektinspektor mit den mühsam definierten Konstanten leider nichts anfangen kann. Fehler sind da bei der nächsten Änderung/Erweiterung vorprogrammiert...

So sehe ich das auch. Ein Dritter würde zuletzt drauf kommen, daß die Tags zweckentfremdet werden, bzw. plötzlich eine reale Bedeutung erhalten. Nur, wer hindert einen daran, sich selber was quasi identisches zu bauen ? Eine published property "Menuepunkt", die per OI einzustellen ist ? Abgeleitet von geeignetem Control. Das sind im Prinzip max. 5 Zeilen. Dieser könnte man auch gleich mit SetSubcomponent (also das + im OI) eine Caption verpassen und fertig.

[alzaimar]

Leicht OT: Wozu sind die Tags denn dann gut, wenn nicht für sowas?

[Hansa]

Die sind für den absoluten Ausnahmefall da, aber IMHO nicht dafür, einen zu hindern so was einfaches selber einzubauen :

Delphi-Quellcode:

  TMenuelbl = class(TLabel)
    procedure SetMenueEbene (Value: integer);
  private
    FMenueEbene : integer;
  public
    constructor Create(AOwner: TComponent); override;
  published
    property MenueEbene : integer read FMenueEbene write SetMenueEbene;
  end;

constructor Tlbl.Create(AOwner: TComponent);
begin
  inherited;
  MenueEbene := 0;  // Standard
end;

procedure TlblRealEdit.SetMenueEbene (Value: integer);
begin
  FMenueEbene := Value;
end;

wie gesagt, wenn ich dem Teil noch eine eigene Caption/SubComponent verpassen will, dann wirds eben mehr (aber nicht viel). Vorteil : habe nicht irgendein "Tag", sondern das was nötig ist.

[alzaimar]

Nee, nee der Vorteil is klar. Wie viele Komponenten hast Du denn dann so installiert?

[Hansa]

Ein paar, verteilt auf 2 Registerreiter "Eigene" und "DB-Eigene". Das lohnt sich auf jeden Fall zu wissen wie das geht !

[alzaimar]

Na ja, dafür bastel ich mir aber keine Komponente. Aber Jedem das Seine.

[marabu]

Hi folks,

nicht immer ist eine spezielle Komponente eine gute Lösung. Im vorliegenden Fall wäre es nach meiner Erfahrung der falsche Weg, weil erstens Object Pascal eine Hybridsprache ist und zweitens die von Hansa gezeigte Komponente einen clone des tag properties schafft nur um jenes ungenutzt zu lassen.

Eine Komponente muss universell einsetzbar sein und eine deutliche Bereicherung im Vergleich zu ihrem Vorgänger darstellen. Diesen Leitgedanken drückt Steve Teixeira in seinem Kommentar zum tag property so aus:

Zitat von Steve Teixeira and Xavier Pacheco:

This property should not be used by component writers - it is intended to be used by application writers. Because this value is an integer type, pointers to data structures - or even object instances - can be referred to by this property.

Der Entwurf eines Application Framework ist gut gelungen, wenn ich für Kleinigkeiten keine eigene Komponente entwickeln muss - egal wie geringfügig der Aufwand dafür sein mag.

marabu

[Hansa]

Das zitierte Zitat paßt aber nicht so recht. Wie der richtig schreibt, sollte man das Tag eben nicht für eigene Zwecke (hier allerdings Komponente) mißbrauchen. Verwendet man es im nur Programm, dann steht es eben später und zwar auch in abgeleiteten Typen nicht mehr so zur Verfügung. Darauf wollte ich hinweisen. Insbesondere darauf, wie einfach man so was selber machen kann und aus allem Ungemach raus ist. Alllerdings ist das konkrete Thema tatsächlich recht einfach mit der Verwendung eines Tags zu machen. Das gibt nicht so viel her. Der Mini-Source enthält auch noch einen Fehler. Da steht irgendwo mittendrin noch was von TRealEdit. Und von da ist das als kleines Beispiel auch abgekupfert und vieles gelöscht worden, sonst wärs unverständlicher. Im Original habe ich keine Property MenueEbene, sondern eine die heißt Nachkommastellen. Die können im OI leicht eingestellt werden. Dies bedeutet, den Constructor dementsprechend anzupassen (auf Standardwert : 2), also eine einfache Zuweisung. In einem Abwasch kann ich nun gleich taRightJustify (wegen Zahl) beim Create setzen.

Also weiß der OI bereits ohne was ändern zu müssen, was in 99% der Fälle richtig ist und somit ist es auch überflüssig das jedesmal zu ändern. Und weils so schön ist wird natürlich noch das OnKeyPress gleich mitbehandelt. Das läßt eben nur zugelassene Zeichen zu. Und da gibts noch einiges mehr. Ist alles mit ein paar Zeilen direkt in Delphi einzubauen und keineswegs Hexerei ! Das Problem ist eben nur die Scheu vor "eigener Komponente". Siehe die geposteten 2 Zeilen (ohne Deklarationen). Schon habe ich meine MenueEbene im OI und kann die Tags in Ruhe lassen. Oft wird auch Komponente mit OI gleichgesetzt, weil viele nicht wissen was published eigentlich aussagt. Tja, wurde wieder mehr als geplant, aber ich gehe davon aus, daß weit über 90% der User nicht in der Lage wären eine einzige Eigenschaft richtig in den OI zu bekommen.

[alzaimar]

Ich finde, ein Thema, für einen eigenen Thread:
"Komponenten und anderes Geflügel"
wegen der Compon-Ente .

[Hansa]

Stimmt ! Aber das ist hoffnungslos. Hier herrscht ohne Widerstand C+P. Das Geflügel wird dabei gnadenlos abgeschossen. Besonders gerne mit Kanonen oder Atombomben, also WinApi, Operatorüberladung, DLLS und sonstigen Massenvernichtungswaffen. Sogar goto habe ich schon gesehen.