Eigene Ereignisse auslösen

[Jonas Shinaniganz]

akurka, poste doch mal bitte wo du den Record befüllst, wenn das möglich ist.

Ich empfehle dir nochmals (weil es eine wirklich durchdachte Implementation ist) einen Blick in die AsyncPro Bibliothek zu werfen (speziell Datapackages). Es gibt auch eine gute Dokumentation dazu.

[Sir Rufo]

Zitat von Jonas Shinaniganz:

akurka, poste doch mal bitte wo du den Record befüllst, wenn das möglich ist.

Ich empfehle dir nochmals (weil es eine wirklich durchdachte Implementation ist) einen Blick in die AsyncPro Bibliothek zu werfen (speziell Datapackages). Es gibt auch eine gute Dokumentation dazu.

Es ist völlig unerheblich, wie er den Record befüllt. So sollte man das definitiv nicht machen (es sei denn man möchte sich unkontrollierte Probleme einhandeln).
Wenn du dem Record einen Event spendierst und dann den Record aus einem Stream lädst, dann ist auch die Zuweisung für den Event entweder leer (im besten Fall) oder der Event zeigt irgendwo ins Nirwana und die Hütte fliegt dir um die Ohren.

Betrachte einen Record so, wie du einen einfachen Typen wie z.B. integer betrachtest (als einen einfachen Wert).

[Sir Rufo]

@akurka

Im OOP-Geschäft muss man etwas abstrakter denken (damit das auch Sinn macht und das Leben vereinfacht).

z.B. Die Komponente für den Com-Port sorgt für den Datenaustausch (Protokoll) und nicht mehr.
Sie weiß, wie groß die Pakete sind (ist Bestandteil des Protokolls) und übergibt diese Pakete an eine weitere Instanz, die weiß, wie man aus diesen Paketen (eine Handvoll Bytes) sinnvolle Strukturen erzeugt.

Etwas Ähnliches (mit Klassen) gibt es hier http://www.delphipraxis.net/180297-b...iebereien.html

Delphi-Quellcode:

unit BaseDataFactory;

interface

uses
  System.Generics.Collections,
  System.Classes,
  System.SysUtils,
  BaseData;

type
  TBaseDataClass = class of TBaseData;

  TBaseDataFactory = class
  private
    class var _Types : TDictionary<Byte, TBaseDataClass>;
  protected
    class constructor Create;
    class destructor Destroy;
  public
    class function CreateFromStream( AStream : TStream ) : TBaseData;
    class procedure RegisterType( AType : Byte; AClass : TBaseDataClass );
  end;

implementation

{ TBaseDataFactory }

class constructor TBaseDataFactory.Create;
begin
  _Types := TDictionary<Byte, TBaseDataClass>.Create;
end;

class function TBaseDataFactory.CreateFromStream( AStream : TStream ) : TBaseData;
var
  LType : Byte;
  LSize : Byte;
  LData : TBytes;
  LClass : TBaseDataClass;
begin
  AStream.Read( LType, SizeOf( LType ) );
  AStream.Read( LSize, SizeOf( LSize ) );
  SetLength( LData, LSize );
  AStream.Read( LData, LSize );

  LClass := _Types[LType]; // Bei einem unbekannten Typen wird hier eine Exception geworfen
  Result := LClass.Create( LData );
end;

class destructor TBaseDataFactory.Destroy;
begin
  _Types.Free;
end;

class procedure TBaseDataFactory.RegisterType( AType : Byte; AClass : TBaseDataClass );
begin
  _Types.AddOrSetValue( AType, AClass );
end;

end.

In die andere Richtung geht es genauso (nur umgekehrt).

Einer weiß, wie man aus einer Informationsstruktur (z.B. ein Record) eine Byte-Folge machen kann, übergibt diese Byte-Folge an jemand anderes, der Byte-Folgen versenden kann, der wiederum weiß, dass das über den Com-Port erfolgen muss.

[Jonas Shinaniganz]

Okay vielleicht fällt es mir auch nur zu schwer, mich da in etwas hineinzudenken was ich nicht sehe In dem was du sagst stimme ich zu.

akurka, schau einmal hier in den Guide. In der Sektion Datapackages. http://tpapro.sourceforge.net/docs/A...renceGuide.pdf

Diese Bibliothek ist so mächtig das der serielle Stream vor ihr erzittert :]

[Sir Rufo]

Betrachten wir das doch mal ganz abstrakt aus der Sicht der Anwendung:

Es gibt da so einige Daten-Pakete, die empfangen und gesendet werden können. Mehr interessiert die Anwendung an diesem Punkt nicht. Wann und warum ist egal. Wenn, dann muss die Anwendung reagieren und wenn die Anwendung etwas senden will, dann muss das auch einfach passieren. Wie das passiert, ist der Anwendung an diesem Punkt auch egal.

Damit kann man jetzt eine abstrakte Klasse definieren, die diese Anforderungen (Senden von Daten und Events beim Empfang von Daten) erfüllt.

Delphi-Quellcode:

type
  TCNC_Data1 = record
  ...
  end;

  TCNC_Data2 = record
  ...
  end;

  TCNC_Command1 = record
  ...
  end;

  TCNC_Command2 = record
  ...
  end;

  TCNC_Data1_Event = procedure ( Sender : TObject; Value : TCNC_Data1 ) of object;
  TCNC_Data2_Event = procedure ( Sender : TObject; Value : TCNC_Data2 ) of object;

  TAbstractCNC_Talker = class abstract
  private
    FOnReceiveData1 : TCNC_Data1_Event;
    FOnReceiveData2 : TCMC_Data2_Event;
  public
    procedure Send( Value : TCNC_Command1 ); overload; virtual; abstract;
    procedure Send( Value : TCNC_Command2 ); overload; virtual; abstract;

    property OnReceiveData1 : TCNC_Data1_Event read FOnReceiveData1 write FOnReceiveData1;
    property OnReceiveData2 : TCNC_Data2_Event read FOnReceiveData2 write FOnReceiveData2;
  end;

[Sir Rufo]

In diesem Zuge wäre es auch interessant zu wissen, was exakt über die serielle Schnittstelle hineinkommt und welche Records (Struktur/Inhalt) dabei rauskommen sollen. Das gleiche auch für den umgekehrten Fall (die Anwendung sendet).

Daraus kann man sich dann auch sehr schön Test-Szenarios bauen, wo man den Com-Port durch etwas ersetzt, was diese Daten liefert/entgegennimmt und dann schaut, ob das Erwartete auch am anderen Ende herauskommt. Dann spart man sich den Aufbau einer kompletten CNC-Maschine mit Com-Anschluss

[akurka]

Hallo
Vielen Dank für Euere Bemühungen aber meine Verwirrung ist jetzt definitiv
komplett.
Ich glaube am besten statt tropfenweise Informationen, sende ich
zugleich die Beschreibung der gesammte Programmstruktur wie es jetzt im altem Pascal Programm ablauft. Siehe Beilage(Globale Variablen :NC__09= hier sollen die div.Meldungen von der CNC gespeichert, CNC_PC_comm.txt = Gesamtbeschreib der Kommunikation CNC zu PC).
Mein Ziel ist das ganze in Delphi zu portieren. Was nicht geändert werden kann sind die Meldungen von der CNC (ist zwahr auch von mir(grosste Teil VHDL) aber das möchte ich lieber nicht anfassen).
Ich habe einige der Async Pakete angeschaut und u.a das ProfAsync, damit auch einige Testprogramme gemacht. Jetzt bin anfänglich bei der Version 7 aber immer noch nicht brauchbars.
Ich wäre froh, wenn eine von Euch Experten mir ein Vorschlag macht für das Gesamtkonzept, weil ich langsamm überzeugt bin das es an dem mangelt.
Gruss Anton

[Sir Rufo]

Zitat von akurka:

Ich glaube am besten statt tropfenweise Informationen, sende ich
zugleich die Beschreibung der gesammte Programmstruktur wie es jetzt im altem Pascal Programm ablauft. Siehe Beilage(Globale Variablen :NC__09= hier sollen die div.Meldungen von der CNC gespeichert, CNC_PC_comm.txt = Gesamtbeschreib der Kommunikation CNC zu PC).

Es fehlt eigentlich die Beschreibung, was wirklich über die Com-Schnittstelle ankommt.
Ich würde ja mal vermuten, dass da ein Header (wie groß?) kommt und danach die Daten, oder wie erkennst du, was für Daten du gerade bekommst?

[akurka]

Hallo ,
Noch ein Zusatz : Das ZBETR im Status Meldung (Record Status) entscheidet darüber in welchem Menü man sich befindet (es hat 16 mögliche Betriebswahl
stellungen). Bei der Aenderung von ZBETR soll möglist schnell in ein anderes
Menü gewechselt werden. Darum meine Frage wegen eigene Ereignisse.
Gruss Anton

[akurka]

Hallo Sir Rufo,
So kompliziert ist es nicht :
im erste Byte (MldgTyp) wird definiert, um was für Meldung es sich handelt (ist eine Nummer). Diese entscheidet darüber, wie lang die Meldung sein wird.
Siehe getblk, Putblk, Hauptprogr.
Diese Meldungen werden in verschiedenen Records gespeichert und sollen
aus allen Menüs zugreiffbar sein (Global var)
In der Beilage eine kurze Beschreibung der Empfangs/Sende proceduren.
Gruss Anton