Jede Komponente in EIGENER Unit

[Pseudemys Nelsoni]

Moin moin,

ich möchte gern jede Komponente die ich schreibe in einer eigenen Unit, da es einfach übersichtlicher ist als alles in einer zu haben.

Das Problem: Die eine Klasse braucht die andere und umgekehrt, d.h Klasse1 hat ein Feld "FOwner" das die Komponente des Besitzers angeben soll. In Klasse2 wiederum(Hauptklasse) ist ein Feld von Klasse1.

Ist es denn gar nicht möglich das irgendwie in 2 Units unterzubringen? D.h ich müsste Die eine unit in der Anderen im uses-teil haben und umgekehrt. (was aber ja nicht geht)

Das macht mich fertig :cry:

[SirThornberry]

du musst die unit unter implementation eintragen (da in die uses, bzw. eine neue uses dort anlegen).

Bei der Deklaration gibst du dann oben TObject als Owner an und überprüfst dann in der funktion ob der typ stimmt.

Delphi-Quellcode:

type
  TMyClass1 = class;
  public
    procedure OwnerSetzen(AOwner: TObject);
  end;

implementation

uses
  unitMitTMyClass2;

procedure TMyClass1.OwnerSetzen(AOwner: TObject);
var LOwner: TMyClass2;
begin
  //Hier ist TMyClass2 dann bekannt, deshalb kannst du jetzt prüfen ob AOwner vom Typ "TMyClass2" ist
  if AOwner is TMyClass2 then
  begin
    LOwner := TMyClass2(AOwner);
    //do something with LOwner
  end;
end;

[Pseudemys Nelsoni]

Moin SirThornberry,

das mit dem implementationstail hab ich mir auchschon überlegt,aber ich brauche die andere Unit ja schon bereits im Interface teil, da ich dort ja den "FOwner: MyClass2" festlegen muss


EDIT: ah ich seh schon, danke ich teste das mal :)

[Robert_G]

Zitat:

Zitat von SirThornberry

du musst die unit unter implementation eintragen (da in die uses, bzw. eine neue uses dort anlegen).

Bei der Deklaration gibst du dann oben TObject als Owner an und überprüfst dann in der funktion ob der typ stimmt.

Dann könnte er ja genausogut den Owner von TComponent übernemhmen. Ich denke mal, er findet dieses Rumgecaste ziemlich hässlich. ;)
Ohne Interfaces bzw. abstrakte Klassen wirst du da nicht weiter kommen. ;)

[Pseudemys Nelsoni]

Du hast recht, ich finde es hässlich, aber von Interfaces habe ich nicht wirklich Ahnung ;)

Solange es funktioniert und die Komponente fertig ist und ich sie mir nichtmehr angucken muss ist mir das egal *g*

@Thornberry: wofür steht das L deiner Variablen? "Local" ? Eigentlich ne gute Idee, dann können sich Argumente mit Lokalen Variablen nicht "ersetzen".(Gleicher name z.b)

[Hansa]

Zitat:

Zitat von Robert_G

Ohne Interfaces bzw. abstrakte Klassen wirst du da nicht weiter kommen. ;)

Fange nicht schon wieder damit an. :mrgreen: Aber im Ernst : was ich so gesehen habe und es auch selber so mache : in jedem Package sind Komponenten, die vom gleichen Vorfahren abstammen. Dadurch fällt die Fehlerquelle weg, gleich mehrere Units, also Komponenten registrieren zu müssen. Und abstract ist dann auch in diesem Falle überflüssig.

Beispiel :

ich habe 2 Komponentengruppen in 2 Units. Das sind jeweils 3 Stück. Die eine ist abgeleitet von TEdit, die andere von TDBEdit. Leider ging das mit vertretbarem Aufwand nicht anders, aber mit .NET soll sich das ja ändern. Die eine Unit sieht nun ungefähr so aus : (abgeleitet von TEdit) -> MeinEdit -> MeinIntEdit -> MeinRealEdit. Mit etwas Phantasie kann man sich ausrechnen, was da gemacht wird : im OnKeyPress werden die zulässigen Zeiechen geprüft, bei Zahlen steht das Default-Alignment auf rechts und und.

Als Faustregel würde ich mal sagen : alles was in der Komponentenpalette in einen eigenen Registerreiter gehört, das gehört auch in eine eigene Unit.

[stoxx]

wie würde sich dieses Problem denn da mit abstrakten Klassen lösen lassen ?
So ganz klar is mir das noch nicht jetz ? :nerd:

[sakura]

Auch wenn Du es nicht willst, so möchte ich es zumindest gesagt haben. Wenn Du zwei Komponenten / Klassen hast, welche so eng miteinander verbunden sind (z.B. TreeView und TreeItem), dann sollten diese auch in einer Unit sein und somit deren Zusammengehörigkeit direkt verdeutlichen.

...:cat:...

[Hansa]

Indem Du etwas da definierst, ohne es zu impemetieren, wo es eigentlich nicht hingehört und dann anderwo sagst, wo es her kommt und die Implementierung dann da machst. Für so Spaghetti-Code dürfte dir Robert_G helfen können. :mrgreen:

[Edit] Sakuras Beispiel ist noch krasser als meins. Vor allem sollte man noch bedenken, daß es um OOP geht. Man also wirklich nur die Unterschiede zwischen den Klassen neu machen muß. Für meine RealEdit-Klasse, die vom IntEdit kommt und nur den DecimalSeparator abhandelt, mache ich doch keine eigene Unit.

[Robert_G]

Zitat:

Zitat von stoxx

wie würde sich dieses Problem denn da mit abstrakten Klassen lösen lassen ?
So ganz klar is mir das noch nicht jetz ? :nerd:

Wenn du Benachrichtigungen so standardisierst dass du zum Bleistift mit einem Interface INotifiable und einem INotifier auskommst, kannst du schon einige Owner/Child - Probleme lösen.
Dabei würdest du weder den Owner noch das Child fest aneinander koppeln.
Aber bei so loser Kopplung wirst du um einen TypCast bei den Benachritungen nicht vorbeikommen*.

Wenn du jetzt eine Basisklasse für den Owner hast**, die du in beiden Units benutzen kannst, könntest du so virtuelle/abstrakte Methoden des Owners ohne TypCasting ausführen.
Aber etwas Gewurschtel wird es eigentlich immer werden. ;)

@mieze
In dem Fall würde es auch nicht viel Sinn machen. ;)
Aber ich fange jetzt ganz sicher nicht mit dem internal und den fehlenden forward declarations aus C# an. :mrgreen:

@Hansa
Dass du absolut keine Peilung von OOP hast dürfte man in Pseudos anderem Thread gemerkt haben. :mrgreen:

*Irgendwas spezielles wird der INotifier ja dem INotifiable mitteilen wollen. ;)
**die keinen direkten Verweis auf die Childklasse hat

[Pseudemys Nelsoni]

* ** hmm...sieht nachSpaghetti-Post aus *g*

Zitat:

[Edit] Sakuras Beispiel ist noch krasser als meins. Vor allem sollte man noch bedenken, daß es um OOP geht. Man also wirklich nur die Unterschiede zwischen den Klassen neu machen muß. Für meine RealEdit-Klasse, die vom IntEdit kommt und nur den DecimalSeparator abhandelt, mache ich doch keine eigene Unit.

Ich rede ja auch nich von sonem popeligem 2-Zeiler ;) Sondern mehrere 1000 Lines und da kann man eben schon mal die Übersicht verlieren

[Hansa]

Zitat:

Zitat von Pseudemys Nelsoni

...Ich rede ja auch nich von sonem popeligem 2-Zeiler ;) Sondern mehrere 1000 Lines und da kann man eben schon mal die Übersicht verlieren

Das Problem ist, daß anscheinend keiner weiß von was er redet. Das Problem hier lautet ganz einfach : "warum einfach, wenn es auch kompliziert geht ?" :mrgreen: Und wer in der Lage ist, mit 2 Zeilen das zu machen, wozu ein anderer 1000 Zeilen braucht, der ist eben der bessere Programmierer. 8) Habe mal nachgesehen, was in meiner Unit los ist : es sind 400 Zeilen für 3 Edit Komponenten. Inkl. Deklarationen ist das nicht sehr viel. Und das wichtigste : das funktioniert sogar alles und wird auch konkret in mehreren Projekten benutzt.

[Pseudemys Nelsoni]

Zitat:

Und wer in der Lage ist, mit 2 Zeilen das zu machen, wozu ein anderer 1000 Zeilen braucht, der ist eben der bessere Programmierer.

Du vergisst nur das ich mit meinen 1000 Zeilen nich die gleichen Kompos mache wie du. Also hat das damit nichts zu tun... Bei sonem Edit-Kram brauch ich sicher auch nicht mehr als du geschrieben hast ;)

[Hansa]

Das Problem ist, daß Du nicht mal gesagt hast, um was es genau geht. Insofern helfen bei so einer Frage eben nur Beispiele, wenn überhaupt. Einiges sollte man bei der Komponentenentwicklung aber doch beachten :

Es ist mehr oder weniger mühsam, diese selber zu machen. Gehen tut das aber schon. Ist sie fertig, dann besteht kein großer Bedarf mehr, sie zu ändern. Aber nur, wenn sie gut geplant wurde und tatsächlich funktioniert. Dies bedeutet dann aber auch, daß man lange nichts damit zu tun hat, eben erst dann, wenn man doch wieder etwas ändern muß wegen schlechter Planung. Und dann fängt man eben wieder an sich reinzudenken.

Jetzt gibt es verschiedene Methoden, sich das Leben schwer zu machen : man schreibe eigene Units für jede Komponente, selbst wenn sie aufeinander aufbauen. Das ist das, was du vorhast. Verfeinern kann man das Spaghetti-Gericht dann noch mit diversen abstracten Zutaten. 8) Als Krönung der Mahlzeit könnte man diese Units dann noch in eigene Unterverzeichnisse packen und im Endeffekt den Compiler zur Kapitulation zwingen. :lol:

[Pseudemys Nelsoni]

Die indys etc sind für dich spaghetticode? :\ :roll: :mrgreen:

[stoxx]

Delphi-Quellcode:

Jetzt gibt es verschiedene Methoden, sich das Leben schwer zu machen : man schreibe eigene Units für jede Komponente, selbst wenn sie aufeinander aufbauen.

Hallo Hansa,

aber was ist, wenn die Komponenten zwar aufeinander aufbauen, aber nix miteinander zu tun haben ?
Ich kann mich daran erinnern, dass ich aus einer alten Jedi VCL mal den JVCaption Button seperat herausgelöst habe. ( weil ich ohne die Jedi Installation auskommen wollte)
Das ging sehr gut, eins, zwei Units.

In der neuen Jedi wird auch der XP Style untersützt.
Und auch deswegen muss Du neuerdings halb Jedi einbinden, um diesen einen Button in der Titelleiste zu bekommen :mrgreen:

Aber muss Jedi nun denn alle Komponenten in einer Unit schreiben, nur weil sie alle den Win XP Style untersützen ?
Es gibt da wahrscheinlich keine so richtig optimale Art und Weise, obwohl es sich die Informatik sehr gern wünschen würde sicherlich.

[Hansa]

Zitat:

Zitat von stoxx

...aber was ist, wenn die Komponenten zwar aufeinander aufbauen, aber nix miteinander zu tun haben ?...

Genau das ist fast die exakte Definition von Spaghetti-Code. :mrgreen:

Edit : sich eine solch große Komponenten-Sammlung wie Indy oder gar Jedi zum Vorbild zu nehmen ist von Anfang an der falsche Weg. Und @Pseudo : was soll jetzt deine Kompo eigentlich machen ? Funktioniert sie überhaupt ?

[stoxx]

Zitat:

sich eine solch große Komponenten-Sammlung wie Indy oder gar Jedi zum Vorbild zu nehmen ist von Anfang an der falsche Weg.

Warum wieso weshalb ?
Ich persönlich finde es auch besser, wenn benötigte Klassen in einer Extra Unit stehen, da weiss ich, wer auf was aufbaut.
Ich behalte die Übersicht und muss mich nicht unnötig in einer einzigen Unit hin und herhangeln.
Die Zeit, die ich einspare, wenn ich nicht in einer riesigen Quelltext Datei entwickeln muss, kann ich dann gut und gern dazu verwenden, um meine Spagetti Code wieder zusammenzufügen :-)

[Pseudemys Nelsoni]

Bin ganz deiner Meinung, stoxx :)

Zitat:

Edit : sich eine solch große Komponenten-Sammlung wie Indy oder gar Jedi zum Vorbild zu nehmen ist von Anfang an der falsche Weg.

Wieso sollte es? Kommt nur drauf an ob der Jenige das alles kann.

Zitat:

Und @Pseudo : was soll jetzt deine Kompo eigentlich machen ? Funktioniert sie überhaupt ?

Ersteres ist egal ;) Zu Letzerem kann ich nur sagen: Natürlich, denn ich mach den Code ja nicht zum Spass :mrgreen:

[stoxx]

Mein Warum, wieso und weshalb man sich Jedi nicht zum Vorbild nehmen sollte, war eine ernstgemeinte Frage, falls dies nicht so rübergekommen ist.
Man kann jeden Tag neue Dinge lernen, nur wie macht man es besser ?
Ich code auch manchmal so, wie man es eigentlich nicht machen sollte, aber oft fällt mir eben keine bessere und elagantere Lösung ein. Daher interessiert mich das schon :)

[jbg]

Zitat:

Zitat von stoxx

Mein Warum, wieso und weshalb man sich Jedi nicht zum Vorbild nehmen sollte, war eine ernstgemeinte Frage, falls dies nicht so rübergekommen ist.

Würde mich auch interessieren.

[Hansa]

ich habe nicht gesagt, daß man sich das nicht ansehen soll. Unter Vorbild verstehe ich etwas, das so gut ist, daß man möglichst alles davon nachmachen sollte, um mindestens genauso weit zu kommen.

Wenn ich wissen will, wie Licht besser gesagt Energie erzeugt wird, so kann ich einem Fahrradfahrer abends beim Fahren zusehen. Ich kann auch ein Atomkraftwerk besichtigen und lasse mir das erklären. Jetzt will ich selbst Licht erzeugen und baue deshalb einen vorhandenen Fahrrad-Dynamo so als meinen Dynamo um, daß er nicht während der Fahrt geht, sondern mit stationärem Handbetrieb. Wenn ich das hier so lese, dann kommt es mir fast vor, als würden Pläne geschmiedet, eher ein Atomkraftwerk im Vorgarten aufzubauen. :lol:

Zitat:

Zitat von Pseudemys Nelsoni

Wieso sollte es? Kommt nur drauf an ob der Jenige das alles kann.

So siehts aus. Und ihr könnt das alles ganz sicher ? Seltsam ist nämlich, daß es meistens heißt : "das tut nichts zur Sache", o.ä. sofern man nach dem genauen Zweck fragt.

Wieso hat sich eigentlich noch keiner die Jedi Komponenten einfach angesehen ? Die Frage wäre langst abgehakt. 8)

[Pseudemys Nelsoni]

Zitat:

So siehts aus. Und ihr könnt das alles ganz sicher

Jo (Wenn ich für mich spreche), sonst würde ich soetwas gar nicht erst anfangen.

Zitat:

"das tut nichts zur Sache", o.ä. sofern man nach dem genauen Zweck fragt.

Der Zweck ist ja auch egal, die Frage hier war ja vielmehr wie es ist, jede Komponente in eine eigene Unit zu packen und nicht was die Selbige kann. ;)

[stoxx]

Zitat:

Wenn ich das hier so lese, dann kommt es mir fast vor, als würden Pläne geschmiedet, eher ein Atomkraftwerk im Vorgarten aufzubauen.

und ich komm mir manchmal so vor, als würde ich ein Atomkraftwerk mit dem Kenntnissen eines Fahrraddynamos bauen müssen ! ;-)

[jbg]

Zitat:

Zitat von Hansa

Wieso hat sich eigentlich noch keiner die Jedi Komponenten einfach angesehen ?

Das habe ich schon seit mehr als zwei Jahre.

Zitat:

Die Frage wäre langst abgehakt.

Aber die Frage hat sich deswegen immernoch nicht geklärt, weil du deine Argumente noch nicht offengelegt hast (Gedankenlesen ist nicht gerade eine meiner stärken ;-) . Ich weiß nicht mal, ob du das mit den JEDI Komponenten jetzt positiv oder negativ gemeint hast.

[Phistev]

Es gibt noch einen einfachen Weg, zwei Komponenten in einer Unit zu haben und die Sache ist trotzdem übersichtlich. In so einem Fall wären Includes ganz praktisch, mit denen kann man zumindestens die Implementation einer Komponente in einer Datei ablegen und totzdem hat man keine Probleme mit zirkulären Referenzen. Und für alle, die meinen: "Dann kann ich das Interface aber nicht mehr sehen"(solche Typen habe ich aber hier noch nicht gefunden): Entweder öffnet man zwei Editorfenster in Delphi oder man benutzt seinen Drucker und druckt den Interface-Teil aus. Damit könnte man sogar das lästige Wiederfinden der Stelle, an der man gerade arbeitet, umgehen.

[Hansa]

Jetzt auch noch Include-Files und zirkuläre Geschichten ? :shock: Die Spaghettis sollen also zum Schluß auch noch verknotet werden ? :lol: Tolle Idee, aber seit den ersten ca. 5 Beiträgen kann man die anderen mehr oder weniger vergessen. 8)

Allerdings hätte ich noch eine Frage : wer von denen, die hier was gesagt haben, hat eine einzige eigene fertige Komponente, bei der im OI etwas eigenes eingestellt werden kann und die in der Komponenten-Palette sichtbar ist ? Funktionieren muß sie natürlich auch.

Handelt es sich um streng geheimen Code, nicht schlimm. Mich interressiert der nicht, sondern nur von welcher Standard Delphi-Komponente abgeleitet wurde.

[stoxx]

oohr Hansa, ich mag Dich eigentlich ziemlich sehr und lese Deine Beiträge immer sehr gern und respektvoll.
Nur was hat die Größe einer Quelldatei in der sich vielleicht 3 Klassen befinden, die man aus Übersichtsgründen gern in extra Dateien haben möchte mit Spagetticode zu tun ??
Darf man jetzt keine großen Klassen mehr schreiben ?
Vieles hat sich ja auch in Delphi2005 mit dem Codefolding gelöst, hab mir da schon ein eigenes übersichtliches System ausgedacht.
Dein letzter Beitrag war Müll, sorry :-)
So wie im Anhang sieht dann meine Interface Teil aus ( is erstmal nur da Grundgerüst, experimentiere noch etws damit herum, mal sehen, ob es sich bewährt)
liebe Grüße von mir

[Hansa]

Zitat:

Zitat von stoxx

...Dein letzter Beitrag war Müll, sorry :-) ...

Meinst Du ? 8) Nun denn, ich habe mir mal alles nach Sakuras Beitrag nochmals kurz angesehen und komme zu der Erkenntnis, daß es sich überwiegend um Trash handelt. Insofern lohnt es sich nicht, weiter darauf einzugehen. Auf konkrete Rückfragen kommen sowieso nur keine oder verschwommene Antworten.

Wer tatsächlich ernsthaft bemüht ist, bei Komponenten einzusteigen, der soll sich mal noch das hier ansehen, sofern er das notwendige Grundwissen denn mittlerweile hat :

http://www.delphipraxis.net/internal...ight=trealedit

[stoxx]

Zitat:

Auf konkrete Rückfragen kommen sowieso nur keine oder verschwommene Antworten.

Da ich mich hier nur eingemischt habe, wollte ich nicht drauf antworten. Nein, ich habe noch keine visuellen Komponenten entwickelt, alles Nichtvisuell was ich mache. (mit Objekten)
Mir hat der Thread trotzdem was gebracht. Habe das mit dem abstrakten Klassen mal durchdacht.
Das ist eine gute Idee, Events können dadurch so allgemein wie möglich gehalten werden.
Nun ja .. HAtte nur ständig das gefühl, dass Du nicht so richtig zum Punkt gekommen bist, weiss bis heute nicht, was an Jedi schlecht sein soll, hätte aber gern Deine Meinung dazu gehört.

viele Grüße

[jbg]

Da bekomme ich ja Augenkrebs :-) Ne, wenn es dir so gefällt und du mit den Farbeeinstellungen keine Probleme hast, ist alles in Ordnung. Über Geschmack lässt sich ja bekanntlich (nicht) streiten.

Zitat:

wer von denen, die hier was gesagt haben, hat eine einzige eigene fertige Komponente

Mit "einer einzigen eigenen fertigen Komponente" kann ich nicht dienen, aber reichen dir auch mehr als eine?

Zitat:

Mich interressiert der nicht, sondern nur von welcher Standard Delphi-Komponente abgeleitet wurde.

Dann fang ich einfach mal mit den OpenSource Komponenten von mir an.

Delphi-Quellcode:

TJvAppInstances = class(TComponent);
TJvEditListAutoComplete = class(TJvBaseEditListAutoComplete); -> TComponent
TJvEditListBoxAutoComplete = class(TJvBaseEditListAutoComplete); -> TComponent
TJvComboBoxAutoComplete = class(TJvControlAutoComplete); -> TComponent
TJvLookupAutoComplete = class(TComponent);
TJvEx(Hier alle VCL Controls einsetzen) = class(VCL Control); // eine ganze Menge
TJvImageList = class(TImageList);
TJvMultiStringHolder = class(TComponent);
TJvTabBar = class(TCustomControl);
TJvTabBarPainter = class(TComponent);
TJvModernTabBarPainter = class(TJvTabBarPainter); -> TComponent
TJvXPProgressBar = class(TJvCustomXPProgressBar); ->  TGraphicControl

Das sind zumindest die, wo ich es noch genau weiß. Da sind mit Sicherheit noch ein paar weitere von mir in der JVCL 3. Nur will ich keine Komponente als meine ausgeben, wenn ich es nicht mit 100% sagen kann, dass es meine ist.

Und jetzt ein kleiner Auszug der nicht OpenSource Komponenten

Delphi-Quellcode:

// Delphi 1 bis 3
TExtendedBevel = class(TBevel);
TStartMenuListView = class(TCustomListView);
TTipTrickDlg = class(TCommonDialog);
TURLLabel = class(TLabel);
TKachelPaintBox = class(TPaintBox);
TPreviewPaper = class(TPanel);
TAboutDlg = class(TCommonDialog);
TGradient = class(TGraphicControl);
TSBtnImageList = class(TSpeedButton);
TPanelImageList = class(TPanel);
TMSEdit = class(TCustomControl);
TZLibPackage = class(TComponent);
TXPMenuDrawer = class(TComponent);
TMenuBar = class(TToolBar);
TAHShellListView = class(TCustomListView);

// neuere:
TAHCompBrowseFolderDialog = class(TCommonDialog);
TAHCompRegistryWriter = class(TComponent);
TAHCompOneInstance = class(TComponent);
TAHCompImageList = class(TImageList);
TAHCompPrintObject = class(TComponent);
TAHCompPrintPreview = class(TGraphicControl);
TAHCompFormHeader = class(TCustomControl);
TAHCompComponentBar = class(TCustomControl);

THtHintWindow = class(THintWindow); // in der JVCL ebenfalls vorhanden, aber nicht in der KompPal.

Ich hoffe das reicht fürs erste Mal. Die CLX Komponenten habe ich außen vor gelassen.

[jbg]

Zitat:

weiss bis heute nicht, was an Jedi schlecht sein soll, hätte aber gern Deine Meinung dazu gehört.

Das er etwas an JEDI schlecht findet, kann man nicht wirklich aus den Postings herauslesen.

[Hansa]

In diesem Nonsense Thread kann man jetzt nur noch sagen : "neue Frage, neuer Thread". 8) Zu Jedi habe ich lediglich gesagt, daß ich es für absolut nicht gut halte, sich an einer Riesen-Komponentensammlung zu orientieren, wenn man nicht mal selber eine kleine Komponente hinkriegt bzw. sich zuerst mal mit Fragen über Aufteilung von Units, Abstract, Include-Files usw. Gedanken macht.

An Komponenten hat offensichtlich noch keiner eine fertige. Was bisher hier gesagt wurde, wird deshalb wohl relativ früh nur durch den Task-Manger gestoppt werden können, oder sogar durch den Ein-Aus Schalter. :lol:

[Edit] @jbg : wieso kein Edit ? Zuerst habe ich nur den letzten Beitrag gesehen. Was machen denn diese Komponenten ? Und warum das J ?

[Pseudemys Nelsoni]

Zitat:

Handelt es sich um streng geheimen Code, nicht schlimm. Mich interressiert der nicht, sondern nur von welcher Standard Delphi-Komponente abgeleitet wurde.

Doch fertige gibts natürlich. Die Klassen selbst sind von TComponent abgeleitet, deren Klassen von TPersistent.

Zitat:

daß ich es für absolut nicht gut halte, sich an einer Riesen-Komponentensammlung zu orientieren, wenn man nicht mal selber eine kleine Komponente hinkriegt

Und woher weisst Du das wir das alle nicht können? Kannst Du etwa Hellsehen?

Ich glaub du bist der (einzige) Jenige der sowas nicht kann und bist nur neidisch, ein anderer Grund fällt mir nicht ein :wink:

[Sharky]

Hai ihr alle.

Bleibt doch bitte beim Thema der Frage.

Eure privaten Meinunsverschiedenheiten könnt ihr via PM, im Sandkasten oder an anderen, dafür geeigneten Stellen, lösen. :roll:

Danke.

[jbg]

Zitat:

Zitat von Hansa

An Komponenten hat offensichtlich noch keiner eine fertige.

Ach und was habe ich dann gepostet?

Zitat:

Was bisher hier gesagt wurde, wird deshalb wohl relativ früh nur durch den Task-Manger gestoppt werden können, oder sogar durch den Ein-Aus Schalter. :lol:

Interessant. Also meine Komponenten sich auch in kommerziellen Anwendungen drinnen, und die laufen jetzt schon seit Jahren, ohne das das Programm wegen diesen abstürzt.

Zitat:

@jbg : wieso kein Edit ?

Weil TJvEdit und TJvValidateEdit mir alles bietet, was ich brauche. Und was denkst du ist TMSEdit?

Zitat:

Was machen denn diese Komponenten ?

Muss ich jetzt alle Beschreiben?

TAHCompBrowseFolderDialog sollte selbsterklärend sein.
TAHCompRegistryWriter erlaubt beliebige Daten in die Registry zu schreiben und zu lesen mit einem einzigen EventHandler, in dem man die Felder an eine Add()-Methode übergibt.
TAHCompOneInstance erlaubt das Ausführen von nur einer Programminstanz, alle anderen Instanzen schicken ihre Parameter an die erste, die auch automatisch aktiviert werden kann.
TAHCompPrintObject und AHCompPrintPreview: Druckfunktion mit Vorschau.
TAHCompFormHeader: Du kennst den MSI Installer? Das weiße Header-Panel wird durch diese Komponente nachgebildet.
TAHCompComponentBar: Ein Screenshot, erlaubt unterschiedliche Painter. Ich hatte mal angefangen einen anderen Painter dafür zu schreiben, der die CompBar wie die von Delphi 2005 aussehen lässt, das aber aus "nicht nützlich für das Projekt" abgebrochen.
TJvTabBar: Ein Screenshot, erlaubt unterschiedliche Painter.

Für den Rest kann man entweder die JVCL Hilfe konsoltieren, oder sich die Funktionalität aus dem Komponentennamen ableiten. Was wird wohl eine TAHCompImageList machen?

Zitat:

Und warum das J ?

Weil es JVCL Komponenten sind, und die alle mit TJv beginnen ;-)


Es ist mir aber immernoch unklar, warum du von der JVCL als Orientierungspunkt abrätst. Ohne genaue Gründe, kann man daran ja auch nichts ändern.

[Hansa]

Zitat:

Zitat von Hansa

...[Edit] @jbg : wieso kein Edit ? Zuerst habe ich nur den letzten Beitrag gesehen. Was machen denn diese Komponenten ? Und warum das J ?

Ist daraus nicht zu erkennen, daß das Editieren des Beitrages gemeint war und keine Edit-Komponente ? :shock: Den Rest muß ich mir später mal angucken.

[jbg]

Zitat:

Zitat von Hansa

Ist daraus nicht zu erkennen, daß das Editieren des Beitrages gemeint war

Ich war halt noch bei den Komponenten, und da ich keine von TEdit/TCustomEdit abgeleitete eigene Komponente habe, schloss ich eben auf das meinem Gedankengang näheste.

Aber den Grund warum du von der JVCL als Orientierungspunkt abrätst hast du immernoch nicht preisgegeben.