Komponenten Programmieren.... wie geht das???

[Andidreas]

hi @ all

ich hab hier im forum gerade nach beispielen bzw. nach turtorials gesucht wo es um komponeneten programmierung geht...

leider bin ich nicht wirklich fündig geworden...

wollt mal nach fragen ob jemand nen link zu nem turtorial kennt bzw. mir ein beispiel hätte indem ich mir das mal anschauen kann wie die komponenten programmierung funktioniert...


mfg
andidreas

[Bernhard Geyer]

Unsere Kollegen von DSDT haben da ein Tutorial

[Andidreas]

danke für denn link...

hab des ganz auch gleich mal überflogen und hab schon ne frage...

ich würd mir gern ne komponente programmieren in die ich ein paar eigen entwickelte funktionen und prozeduren einbinden möchte...
hierbei handelt es sich um funktionen und prozeduren für die text verarbeitung...

um ne komponente anlegen zu können, muss ich ja so zusagen ne mutter komponente anlegen...

kann ich auch ne komponente machen ohne "mutter"???

[Die Muhkuh]

hmm?

Delphi-Quellcode:

TTextverarbeitung = class(TComponent)
private

public
  function Textmarkieren(const Pos, Laenge: Integer): String;
end;

sowas? :-?

[mkinzler]

Nein, da Komponenten alle von TComponent abgeleitet sein müssen.
[Edit: Heute bin ich zu langsam]

[Andidreas]

@spider

joa halt z.B. ne eigene funktion für zeichen suche in nem string etc...

sowas könnte ich dann also mit TComponente als "Mutter" machen????

@mkinzler
heute sind glaub alle etwas langsam bei der hitze :zwinker:

[mkinzler]

TComponent ist nur ne Basis-Komponente. Es ist aber besser von TWinControl oder TGraphicControl abzuleiten oder von der Ciustom-Variante einer passenden Komponente (wenn vorhanden).

[Hansa]

Zitat:

Zitat von mkinzler

Nein, da Komponenten alle von TComponent abgeleitet sein müssen.

Ist das da Dein Ernst ? :shock:

[xaromz]

Hallo,

Zitat:

Zitat von Hansa

Zitat:

Zitat von mkinzler

Nein, da Komponenten alle von TComponent abgeleitet sein müssen.

Ist das da Dein Ernst ? :shock:

Warum nicht?

Gruß
xaromz

[DP-Maintenance]

Dieses Thema wurde von "Christian Seehase" von "Object-Pascal / Delphi-Language" nach "VCL / WinForms / Controls" verschoben.
Mehr ein VCL-Problem

[Hansa]

Weil es so nicht stimmt. Besser gesagt : die Vorgehensweise ist völlig falsch, hat zumindest mit OOP nichts konkretes zu tun. Weil wieder mal bei Adam und Eva angefangen wird, so daß kaum was dabei raus kommt. 8)

[mkinzler]

Zitat:

Zitat von Hansa

Weil es so nicht stimmt. Besser gesagt : die Vorgehensweise ist völlig falsch, hat zumindest mit OOP nichts konkretes zu tun. Weil wieder mal bei Adam und Eva angefangen wird, so daß kaum was dabei raus kommt. 8)

Un waru soll das nichts mit OOP zu tun haben? Eine Komponente muß ein Nachfahre von TComponent sein. das ist Fakt, besser ist es natürlich, wie ich oben auch schon geschrieben habe zu weit unten wie möglich im Vererbungsschema anzusetzen.

[Hansa]

Du mußt das aber wesentlich deutlicher sagen. Gerade bei solchen Sachen :

Delphi-Quellcode:

TTextverarbeitung = class(TComponent)

Was soll das denn werden ? Und dann noch von TComponent ableiten ? Ohje. :wall:

[3_of_8]

Wieso nicht? Wenn ich eine KOMPONENTE brauche, leite ich von TComponent ab. Wenn ich ein CONTROL brauche, leite ich von TWinControl, TGraphicControl oder TCustomControl ab.

[Hansa]

Ja richtig, genau so macht man das, wenn OOP unbekannt ist.

[Jens Schumann]

Zitat:

Zitat von Hansa

Ja richtig, genau so macht man das, wenn OOP unbekannt ist.

Wie macht man es denn wenn OOP bekannt ist?
Du scheinst Dich ja richtig gut im Reich der OOP auszukennen. Bitte bitte zeige uns wie man es richtig macht. Führe uns heraus aus dem Jammertal der Unwissenheit. Noch halte ich die Beiträge von Bernhard Geyer und mkinzler für korrekt und absolut stimmig und was ganz entscheidend ist für 100% OOP konform.

Hiermit bekenne ich öffentlich: Auch ich habe schon TComponent als Vorfahren verwendet um mir eine Komponente (Kontext der VCL) im zu basteln.

[Hansa]

Zitat:

Zitat von Jens Schumann

..Führe uns heraus aus dem Jammertal der Unwissenheit. Noch halte ich die Beiträge von Bernhard Geyer und mkinzler für korrekt...

Tu ich doch glatt. :mrgreen: Korrekt sind die Kommentare schon, aber was soll ich von einer quasi "leeren" Komponente denn groß ableiten ? :shock: TComponent ist von einer Textverarbeitung ungefähr so weit entfernt, wie Alpha Centauri von der Erde. Von einer Komponente was ableiten heißt doch wohl nicht bei Null neu anzufangen ?

[3_of_8]

Es ging hier um allgemeine Komponentenentwicklung. Und du hast dazu gesagt, dass man keine Ahnung hat, wenn man jemals von TComponent ableitet. Und diese Aussage ist absolut falsch.

In diesem Fall sollte man natürlich von TWinControl ableiten, aber sei doch bitte so nett und weite diese Aussage nicht aufs Allgemeine an.

[Hansa]

Zitat:

Zitat von 3_of_8

Es ging hier um allgemeine Komponentenentwicklung. Und du hast dazu gesagt, dass man keine Ahnung hat, wenn man jemals von TComponent ableitet...

Es ging nicht um was "Allgemeines", sondern um eine Textverarbeitung. Sorry, aber da bei TComponent anzufangen ? Das ist echt Wahnsinn. :P

[3_of_8]

Schau dir noch mal ganz genau das Topic an...

Dann das Posting:

Zitat:

Nein, da Komponenten alle von TComponent abgeleitet sein müssen.

Stimmt, müssen sie.

Und dann das:

Zitat:

Wieso nicht? Wenn ich eine KOMPONENTE brauche, leite ich von TComponent ab. Wenn ich ein CONTROL brauche, leite ich von TWinControl, TGraphicControl oder TCustomControl ab.

Das ist allgemein formuliert, genauso wie das Topic. Ich schätze mal, Textverarbeitung war nur ein Beispiel. Und selbst wenn es das nicht war, dann entsprechen alle Antworten der Fragestellung und die Aussage, man dürfe nicht von TComponent ableiten, ist schlichtweg falsch. Genaugenommen sind alle Komponenten von TComponent abgeleitet, nur eben auf verschiedenen Stufen.

BTW: TTextverarbeitung ist nicht gerade ein sonderlich schöner Bezeichner, oder?

[McLane]

Ok, "zerfleischt" euch doch bitte nicht.

1. Komponenten sind Objekte, somit sind wir in der OOP und jedes Objekt braucht immer einen Vorfahren (Ausnahme: TObject, Mutter aller Objekte) um die ursprüngliche Frage zu beantworten.
[edit] Ergänzung: Mutter aller Komponenten ist natürlich wie schon beschrieben TComponent[/edit]
2. Such dir die Komponente raus, die am ehesten an dem dran ist, was du entwickeln willst. Also wo die meisten Methoden und Eigenschaften mit einem "das soll meine Komponente auch können/haben" Kommentar versehen werden könnten. Leite deine Komponente dann von dieser ab.

MfG McLane

[mkinzler]

Zitat:

Zitat von Hansa

Zitat:

Zitat von 3_of_8

Es ging hier um allgemeine Komponentenentwicklung. Und du hast dazu gesagt, dass man keine Ahnung hat, wenn man jemals von TComponent ableitet...

Es ging nicht um was "Allgemeines", sondern um eine Textverarbeitung. Sorry, aber da bei TComponent anzufangen ? Das ist echt Wahnsinn. :P

@Hansa lies dir mal den kompletten Thread durch, es ging um die Frage:

Zitat:

um ne komponente anlegen zu können, muss ich ja so zusagen ne mutter komponente anlegen...

kann ich auch ne komponente machen ohne "mutter"???

Und auf diese frage bezog sich die Antwort mit der Ableitung von TComponent. Es wurde auch immer wieder erwähnt, daß die Ableitung so spät wie möglich im Vererbungsschema stattfinden sollte.

http://www.delphipraxis.net/internal...=574208#574208

[3_of_8]

Zitat:

Zitat von McLane

Ok, "zerfleischt" euch doch bitte nicht.

1. Komponenten sind Objekte, somit sind wir in der OOP und jedes Objekt braucht immer einen Vorfahren (Ausnahme: TObject, Mutter aller Objekte) um die ursprüngliche Frage zu beantworten.
[edit] Ergänzung: Mutter aller Komponenten ist natürlich wie schon beschrieben TComponent[/edit]
2. Such dir die Komponente raus, die am ehesten an dem dran ist, was du entwickeln willst. Also wo die meisten Methoden und Eigenschaften mit einem "das soll meine Komponente auch können/haben" Kommentar versehen werden könnten. Leite deine Komponente dann von dieser ab.

MfG McLane

Falsch. Eine Komponente ist kein Objekt. Eine Komponente ist eine Klasse und abgeleitet von TObject. Objekte sind was ganz anderes, siehe OH.

[McLane]

Zitat:

Zitat von 3_of_8

Falsch. Eine Komponente ist kein Objekt. Eine Komponente ist eine Klasse und abgeleitet von TObject. Objekte sind was ganz anderes, siehe OH.

Argh, jetzt hab ich mich doch glatt zu solch einer Aussage hinreissen lassen. Sorry...
Um mich selber zu korrigieren: Ein Objekt ist eine Instanz einer Klasse. Eine Klasse beschreibt wie sich das instanzierte Objekt verhällt und was es für Eigenschaften hat. Man programmiert also die Klasse und nutzt dann nachher das Objekt (Ausnahme: Klassenmethoden und Klasseneigenschaften). Die Klasse wird von einem Vorfahren abgeleitet usw. (was ich oben beschrieben habe).

Tut mir tausendmal leid, dass ich vorhin doch glatt diesen Fehler gemacht hatte (man solte halt nebenbei kein Fußball hören) :)

[Der_Unwissende]

[Schon vom roten Kasten behandelt]

Zitat:

Zitat von 3_of_8

Falsch. Eine Komponente ist kein Objekt. Eine Komponente ist eine Klasse und abgeleitet von TObject

Hi, seit doch alle mal etwas entspannter.
Die Instanz einer Klasse ist ein Objekt (im ganz Allgemeinen in der OOP). Geh ich hier von einer Delphi-Komponente aus, so müsste ich jetzt noch die Klasse (also das was von TComponent erbt) und die Instanz (ich würde das Ding auch Komponente nennen) unterscheiden, dass eine ist dann eine Klasse und das andere ein Objekt.
[/Schon vom roten Kasten behandelt]

Aber ist das hier wichtig? Wohl kaum.


Ihr solltet ausserdem diesen lächerlichen Streit lassen, was alles OO ist und was nicht. Also klar, alle Ansätze sind nicht OO denn Delphi ist es schon nicht.
Die OOP beschreibt doch nur einen Interaktionsstil. Da steht nirgendwo (in der einen offiziellen und einzigst wahren Definition :mrgreen: ) dass man nur sinnvolle Programme schreiben darf, bei der immer vom Idealen Vorfahren abgeleitet wird. Den gibt es in der Regel einfach nicht. Und wenn man einen direkten Vorfahren hat, dann hat man den wahrscheinlich schon selbst geschrieben und ob der dann irgendwann mal direkt von TComponent oder von einem Nachfahren abstammt, dass ist doch nun echt egal.
Etwas größere Komponenten bestehen in der Regel eh aus einer Menge von Interfaces und Klassen (teilweise noch abstrakt), also aollte mit etwas Glück eine ganze Vererbungshierachie entstehen und letztlich wird keinen interessieren wie stark OOP das ganze ist (jeder primitive Datentyp ist z.B. schon nicht mehr in der OOP).

Wenn man es also zu ernst mit der OOP nimmt, sollte man vielleicht auf SmallTalk zurückgreifen (oder Ähnliches!)

Gruß Der Unwissende

[Hansa]

Zitat:

Zitat von McLane

...Eine Komponente ist kein Objekt. Eine Komponente ist eine Klasse und abgeleitet von TObject. Objekte sind was ganz anderes, siehe OH...
Eine Klasse beschreibt wie sich das instanzierte Objekt verhält und was es für Eigenschaften hat. Man programmiert also die Klasse und nutzt dann nachher das Objekt

...und zwar so abstrakt, daß nichts dabei herauskommt. :mrgreen:

[Andidreas]

wenn ich mir hier jetzt euer geplänkel so durchless, dann komm ich wieder total durcheinander... :wall:
und dabei wollt ich doch nur mal wissen wie man ne komponente selber schreibt :|

naja aber jetzt nochmal zu meinem verständnis (und bitte zerreist mich nicht in der luft wenn ich was falsches schreib *gg*)

wenn ich ne komponente schreib z.b. ein total abstraktes ding was es bisher noch nie gab... dann nehm ich als "mutter" tcomponent

wenn ich jetzt z.b. ne komponente schreib in der ich strings texte etc. formatier, dann könnt ich das auch von tcomponent ableiten oder mir eine bestehende komponente suchen die weiter unten in der hirarchie ist und näher an meiner geplanten komponente liegt... stimmts????


dann noch gleich ne frage... welche "mutter" komponente würdet ihr nehmen für "textverarbeitung"???

[mkinzler]

Zitat:

wenn ich ne komponente schreib z.b. ein total abstraktes ding was es bisher noch nie gab... dann nehm ich als "mutter" tcomponent

TComponent bietet sich eigentlich nur an , wenn due eine non-visuelle Komponenet schreibst. Besser ist wie schon öfters erwähnt TWinControl, TGraphicControl, TGraphicControl.

Zitat:

wenn ich jetzt z.b. ne komponente schreib in der ich strings texte etc. formatier, dann könnt ich das auch von tcomponent ableiten oder mir eine bestehende komponente suchen die weiter unten in der hirarchie ist und näher an meiner geplanten komponente liegt... stimmts????

Diese Vorgehensweise würde ich immer anwenden.

Zitat:

dann noch gleich ne frage... welche "mutter" komponente würdet ihr nehmen für "textverarbeitung"???

Diese Frage kann ich so nicht beantworten, weil ich nich weiß was die Komponente können soll.

[xaromz]

Hallo,

Zitat:

Zitat von Andidreas

dann noch gleich ne frage... welche "mutter" komponente würdet ihr nehmen für "textverarbeitung"???

da antworte ich doch gleich mit einer Gegenfrage: Was soll denn die Komponente "Textverarbeitung" können? Das ist ein weites Feld...

Gruß
xaromz

[freak4fun]

Stimmt. :mrgreen: Such dir eine Komponente raus, die so dicht wie möglich an dem dran ist, was du machen willst.
Da man unter Textverarbeitung sehr viel verstehen kann, kann ich da keine genaue Antwort geben. Wie wäre es denn mit einem TEdit oder TMemo/TRichEdit? :gruebel:

MfG
freak

[Andidreas]

wenn ichs mal fertig hab bzw. es mal hinbekommen hab meine routine ohne fehler zu haben, dann soll das ding nen string erstellen in dem die anzhal der buchstaben eines anderen stings aufgelistet sind, in der reihenfogle wie die buchstenb im string stehen z.B.

String 1 = AndreasSchulze
String 2 = 21112211111 <-- Ergebnis string

[freak4fun]

Wieso möchtest du das als Komponente machen? Reicht da nicht eine einfache Funktion? :)

MfG
freak

[Andidreas]

sicher vorerst mal wirds ne funktion...

aber da ich eh in letzter zeit schon ziemlich viele funktionen für string bearbeitungen gemacht hab, is mir halt die idee gekommen das ich des ganze ja mal in ne komponente packen könnte (also jetzt nicht nur die eine funktion die ich oben kurz erklärt hab)

dies hätte für mich 2 vorteile:

a) ich muss die funktion nicht jedes mal in meinem programm programmieren bzw. reinkopieren etc...
b) ich lern auch mal bischen die komponenten programmierung was sicherlich auch kein fehler is...

[s14]

zu a)
Für eine Sammlung von Funktionen würde ich eine eigene Unit erstellen und diese dann in die Uses-Klausel einfügen.

Gruß
s14

[Thorben77]

Oder Du bastelst eine "Textverarbeitungs"-Klasse.

[Andidreas]

joa aber dann hätte ich die übung mit ner eigenen komponente programmieren net :zwinker:

[mkinzler]

Wenn du aber nichts komponenten-spezifisches verwendest hält sich der Lerneffekt aber auch in Grenzen. ;-)

[3_of_8]

Nebenbei, für mich war eine Klasseninstanz immer eine Klasseninstanz und ein Objekt dieses "Zwischendings" zwischen record und class, object. Dass man eine Klasseninstanz als Objekt bezeichnen kann (in Delphi) ist mir neu.

[mkinzler]

Zitat:

Zitat von 3_of_8

Nebenbei, für mich war eine Klasseninstanz immer eine Klasseninstanz und ein Objekt dieses "Zwischendings" zwischen record und class, object. Dass man eine Klasseninstanz als Objekt bezeichnen kann (in Delphi) ist mir neu.

In der OOP-Theorie bezieht sich der Begriff Instanz immer auf eine Klasse und ein Objekt im Allgemeinen.

Das Objekt Form1 ist eine Instanz der Klasse TForm1.

[3_of_8]

Aha... Wie gesagt, ich kannte Objekt bisher nur als Sprachelement, das ich noch nie brauchte.