Konzeptionsfrage zu Komponente mit dynamischen Propertys

[BAMatze]

Hallo und guten Tag an alle DP´ler,

Ich hab mal eine Frage, die sicherlich schon mal gestellt wurde, die ich aber warscheinlich nicht finden kann, weil ich die richtigen "Schlagwörter" nicht kenne (dynamisch + Property gab 1 Fund).
Ich möchte für mein Programm eine Art Oszilloscope zur Anzeige von analogen Signalen programmieren (ich weiß hier wird oft die Komponente TChart empfohlen), möchte dies aber aus übungstechnischen Gründen gerne selber in einer Klasse, später vieleicht Komponente, selber programmieren. Derzeit muss ich zwar nur 1 Signal anzeigen (dies kann sich aber noch ändern) aber da man sowas ja vieleicht mal wieder gebrauchen kann, wollte ich eigentlich eine variable Anzahl an "Eingängen" für die Klasse/ Komponente vorsehen. Dies bedeutet natürlich, dass ich je nachdem, wieviele Signale ich habe, ja auch Eingänge (Propertys) zur Verfügung stellen muss. Sehe das derzeit wie eine Stringlist, bei der mit Add ein neues String angehängt wird.

Welche Konzepte zur Realisierung gibt es da? Ich hatte mir überlegt, eventuell eine Unterklasse zu erstellen, die rein die Werte für einen Eingang speichert, wenn ein neuer Eingang gebraucht wird, Added man diesen und es wird automatische eine neue Komponente des Typs der Unterklasse erzeugt und in einer Property kann man dann mit dem Index auf die jeweiligen Komponenten zugreifen. Ist dies eventuell umsetzbar? ich sehe da derzeit noch ein paar Fragezeichen, wie man die Zugriffe über den Index auf die jeweilige Unterkomponente regelt oder ist dies so einfach, wie der Zugriff auch ein Klasseninternes Array?

Hoffe ihr könnt mir bei diesem Problem mit ein paar Antworten oder Lösungsansäten helfen.

Vielen Dank
BAMatze

[Medium]

Komponenten sind technisch genau das selbe wie Klassen, nur dass sie noch einen Verweis auf eine Icon-Ressource, und die RegisterComponent-Funktion irgendwo stehen haben. Ansonsten kannst du mit einer Komponente genau das selbe machen wie mit einer Klasse - sie sind halt bis auf o.g. identisch.

[mkinzler]

Komponenten sind Klassen, welche von einer bestimmten Basisklasse abgeleitet sind.

[himitsu]

Zitat von mkinzler:

Komponenten sind Klassen, welche von einer bestimmten Basisklasse abgeleitet sind.

> TComponent oder einer dessen Nachfahren

oder such hier einfach mal nach RegisterComponent, da wirst du bestimmt auf einige Komponenten stoßen und kannst dir etwas abgucken

[BAMatze]

Naja meinte grob, dass ich sie auf Arbeit in die Toolpalette integrieren kann und per Ziehen auf die Form bringe = Komponente. Denke da sicherlich noch etwas zu kompliziert wegen Unterscheidung Klasse und Komponente. Aber wie sieht es mit meinem Konzept aus? ist dies prinzipell machbar oder empfiehlt sich eventuell ein einfacherer Weg?
eine weitere Frage wäre, von welcher Komponente wäre das ableiten der Unterklasse sinnvoll? Ich meine bisher habe ich meistens von TComponent abgleitet, welches (wie ich mir vorstellen kann) dem Spruch "Mit Kanonen auf Spatzen schießen" nahe kommen könnte. Hier mal kurz eine Grobstruktur, wie ich mir das Vorstelle:

Delphi-Quellcode:

unit Unit1;

interface

uses Controls, Classes;

Type TOsziloscopKanal = class(TWinControl)
  private
    xWert, yWert: Array of Integer;
    iXMax, iYmax: integer;
    procedure SetXWert(iWert: integer);
    procedure SetYWert(iWert: integer);
    function GetXWert: integer;
    function GetYWert: integer;
    procedure moveArray(temparray: array of integer);
  protected
  published
  public
    property EingangX: integer read GetXWert write SetXWert;
    property EingangY: integer read GetYWert write SetYWert;
    constructor create(AOwner: TComponent; DisplayWide, DisplayHeight: integer); reintroduce;
    destructor destroy; override;
end;

implementation

constructor TOsziloscopKanal.Create;
begin
  inherited create;
  SetLength(xWert, DisplayWide);
  iXmax := DisplayWide - 1;
  SetLength(yWert, DisplayHeight);
  iYmax := DisplayHeight -1;
end;

destructor TOsziloscopKanal.Destroy;
begin
  SetLength(xwert, 0);
  SetLength(yWert,0);
  inherited destroy;
end;

//Procedure verschiebt ein Array so, dass die letzte Stelle überschrieben werden kann
procedure TOsziloscopKanal.moveArray(temarray: array of integer);
var i: integer;
begin
  for i := 0 to Length(temparray)-2 do temparray[i] := temparray[i+1]
end;

// Es werden immer nur die letzen Werte gesetzt
procedure TOsziloscopKanal.SetXWert(iWert: Integer);
begin
  moveArray(xwert);
  xWert[iXmax] := iWert;
end;

// Es werden immer nur die letzen Werte gesetzt
procedure TOsziloscopKanal.SetYWert(iWert: Integer);
begin
  moveArray(yWert);
  YWert[iYmax] := iWert;
end;

function TOsziloscopKanal.GetXWert;
begin
  // muss noch überdacht werden, da man je nach angabe eines y einen x-Wert bekommen soll
end;

function TOsziloscopKanal.GetYWert;
begin
  // muss noch überdacht werden, da man je nach angabe eines x einen y-Wert bekommen soll
end;

end.

[Code ist komipilierfähig, aber hab es noch nicht eingebunden, könnten sicherlich noch Fehler drin sein]

Wie gesagt, die Frage ist, ob von der Klasse TComponent abgleitet werden muss (hat ja viele Dinge z.B. Wnd, was ich nicht wirklich brauche) oder gibt es dort Klassen, die geeigneter sind?

[Edit]Die Frage ist jetzt eigentlich genau, wie creiere ich das jetzt genau in meiner nächsten Klasse/ wie halte ich das ganze EINDEUTIG, so das die Unterscheidbarkeit gewahrt bleibt? Wie erzeuge ich namen, denn ich brauche ja wieder MyComponentX := TOsziloscopKanal.Create(...)? Da hänge ich jetzt. Also mir ist schon klar, dass ich die Eindeutigkeit über die Namen behalte, aber ich muss das ja auch der höheren Funktion vorher sagen, dass ich dies will. Oder kann ich dort einfach ein Array of TOsziloscop machen?[/Edit]

[Blup]

Warum sollte der Kanal ein WinControl sein, die Ausgabe erfolgt doch durch das eigentlichen Oszilloskop-Steuerelement.

Ich würde von TCollection bzw. TCollectionItem ableiten und dem Oszilloskop ein Property der abgeleiteten TCollection-Klasse geben.

[BAMatze]

@Blup ah genau sowas hab ich gesucht. Werde jetzt mal schauen, was ich da finde zu.

[sx2008]

Ich würde das anderst angehen.
TCollection & TCollectionItem sind dafür konzipiert, um zur Entwicklungszeit im Objektinspektor editiert zu werden.
Für die volatilen Eingangsdaten eines Oszi eher vielleicht nicht so gut geeignet.

Du brauchst doch für jeden Kanal einen Ringspeicher mit einen bestimmten Tiefe (z.B. 1024 Samples).
Für ein einzeles Samples würde ich den Datentyp Single voschlagen; benötigt 4 Bytes und hat ausreichend Genauigkeit
für den Zweck.
Was muss der Ringspeicher können?
Es hat einen Index für das Dateneinspeichern.
Es gibt eine Methode AddSample(value:Single), die einen neuen Wert einschreibt und den Index weiterbewegt.
Das Lesen ist etwas kniffliger.
Man möchte das Lesen bei einem bestimmten Index beginnen (function ReadFirstSample(index:integer):Single) und dann weiter in die Vergangenheit lesen (function ReadNextSample:Single).
Dann gibt es noch Clear() zum Löschen aller Werte und vielleicht noch eine Methode um nachträglich die Speichertiefe zu ändern.
So, das soll als Anregung mal reichen.