Moin !

Ich habe da ein ListView im Virtuellen Modus. Zudem eine Liste mit dem Typ String:

private List<string> list;
private int maxList = 100;

Der Liste füge ich derzeit Pseudetexte hinzu:

list.Add("Item " + DateTime.Now.ToUniversalTime());
if (list.Count > maxList)
  list.RemoveAt(0);

Später soll in der Liste ein Teil des Logging stehen.

Die Liste ist also immer 100 Einträge lang. Bei 101 Einträgen wird der erste gelöscht ...

Das Darstellen der Liste im ListView klappt halbwegs ...

        private void ListView_RetrieveVirtualItem(object sender, RetrieveVirtualItemEventArgs e)
        {
            var lvi = new ListViewItem();
            lvi.Text = list[e.ItemIndex];
            e.Item = lvi;
        }

Wenn ich nun den Scrollbalken bewege dann wird das ListView mit den neuen Einträgen gefüllt.

Aber wie kriege ich es hin das nach einem Eintrag die aktuelle Ansicht gescrollt wird / mit den neuen Strings gefüllt wird. Die Einträge sollten ja automatisch nach oben wegscrollen.

Moin !

Danke. Ich werde das mal testen.

Moin !

wie/wo wird denn das Bild erzeugt? In der gleichen Anwendung

In der gleichen Anwendung.

Im Gunde habe ich folgende Anwendung:

App
 + CHART
 + MINI WEBSERVER

Das Chart wird halt regelmäßig mit neuen Daten gefüttert. Und alle 4-5 Minuten soll sich das Chart auf Platte abspeichern als Bild.

Dieses Bild soll dann der Mini Webserver zur Verfügung stellen.

Nur brauche ich eben irgend einen Block damit der Webserver nicht die Datei ausließert und / oder das Chart gerade das Bild schreibt.

Moin !

Hiergibt es ein schönes tutorial zum Thema httplistener und Mini Webserver:
http://www.java2s.com/Tutorial/CSharp/0580__Network/HttpListenerDemo.htm

Das tut auch alles ausgezeichnet, aber ich frage mich gerade wie ich folgendes Problem in den Griff bekomme.

Nehmen wir einen Chart die oft mit neuen Werten gefüttert wird. diesen Chart lasse ich als Bild speichern und den möchte ich nur mit dem Webserver "hosten".
Nun kommt man aber irgendwann auf ein Problem. der Webclient will lesen und parallel versucht die Anwendung die Grafik neu zu schreiben.

Kann mir jemand einen Tip geben wie man diesen Umstand am besten lösen könnte? Würde sowas über einen Mutex gehen und wenn ja wie?

Moin !

So ich habe die Serielisierung soweit am laufen. 👍

allerdings hät ich da noch ne kleine Frage zu ...
Ich habe in meinem Formular eine Liste die ich Serialisieren will:

    public partial class Form1 : Form
    {
        public List<Mapping> Liste = new List<Mapping>();
....

Die Seialisierung klappt, aber die Namensgebung nicht so richtig ...

Es fängt an mit der Liste. Im XML steht dann:

<ArrayOfMapping xmlns:x....

Wie kann ich denn den Namen anpassen? Ist jetzt nur Kosmetik, aber das klappt nicht so Recht ...
Ich habe es so probiert:

    [XmlArray("products")]
    [XmlArrayItem("product")]
     public List<Mapping> Liste = new List<Mapping>();

Das ändert aber nix.

Auch die elemente der Liste heissen <Mapping> also so wie meine Mapping Instanzen die ich in der Liste ablege.
Kann man den Namen evtl. auch beeinflussen?

Grüße Dominik

Ok Danke derweil. 👍

Werde mich mal durchbeissen und ggf. nochmal nachfragen.

Moin !

Das habe ich mir fast gedacht ...

Muss ich dann das ISerializable Interface bedienen um anzugeben was ich serialisieren will und was nicht?

Moin !

Ich habe in meiner Anwendung eine Klasse die ich als eine Art Container nutze:

    class Mapping
    {
        public IOType EntityType;
        public TableNode Entity   { get; set; }
        public IInOut    EBC      { get; set; }
        public Input_Serial InputSer { get; set; }
        public Input_TCP InputTCP { get; set; }

        public SyncQueue<DATA> InputQueue { get; set; }
        public SyncQueue<DATA> OutputQueue { get; set; }

        public ChartForm OutForm { get; set; }
    }

Von dieser Klasse erzeuge ich Instanzen die ich gerne abspeichern würde (bzw. die wichtigen Teile davon).

Einige Elemente wie das Entity müssen nicht gespeichert werden und bei einigen (z.B. InputSer) müsste ich nur den Port (InputSer = SerialPort) abspeichern.

Wie würde man da am besten ran gehen?

Meine derzeitige Idee wäre, dass alle Elemente (die meisten sind ja selber Klassen) ein Interface mitbekommen. Durch das Interface müsste dann jedes Element eine Save Methode implementieren. Diese rufe ich dann für alle Elemente auf und dort wird eben alles relevante gespeichert.

Aber evtl. kann man das auch eleganter lösen?

Grüße Dominik

Moin !

Also wir werden wohl das hier nutzen:
http://www.mindfusion.eu

Moin !

Wichtig ist, aus welchem Thread der Anstoß kommt, die eigentliche Verarbeitung durchzuführen

Genau. Und du hast Recht ... das Code Beispiel an sich macht noch nichts. Erst wenn ich eine Verarbeitung anstoße.

Vielleicht denkst du nur zu kompliziert.

Kann schon sein 👅

Warum sollte das speziell bei EBC passieren? Ob du nun normal objektorientiert arbeitest oder mit EBCs: einfrieren tut eine Anwendung immer, wenn du zu lang an etwas arbeitest. herbivore hat das ja auch schon gesagt.

Hmm evtl. habe ich mich da falsch ausgedrückt. Das es speziell bei EBC passiert dem ist natürlich nicht so. Klar kommt jede Anwendung unter Last zum stocken.
Was ich eigentlich beschreiben / fragen wollte war das Zusammenspiel von den Threads und dem EBC. Wie gesagt, hab mich da mitunter missverständlich ausgedrückt.

Wieso sollte das im Allgemeinen passieren?

So ist es halt bis dato in meiner EBC Demo. Dort gibt es noch keine Threads. Und das will / muss ich nun ändern.

Da verstehe ich nicht, warum du den "fork" vor Add12 machst.

Das war nur ein ganz triviales Beispiel. Klar macht es so keinen richtigen Sinn. Ich wollte damit nur ein Beispiel zeigen wo ein Eingang auf 2 Ausgänge geleitet wird und vor jedem Ausgang eine Berechnung erfolgt. In dem Beispiel sind die Berechnungen gleich ... Ok. Ich hätte besser Add12 und Add23 genommen. Dann wäre es eindeutiger gewesen.

Die Daten kommen von einem Input, laufen durch einen Asyncer, der die Verarbeitung auf einen Hintergrundthread hebt (ob das immer derselbe oder immer verschiedene sind, ist ein Detail), dann die Verarbeitung, dann das Ergebnis mit Sync wieder auf den UI-Thread zurückheben, dann Split und das Ergebnis an mehrere Outputs fließen lassen.

Das beschreibt es genau und entspricht ja im Grunde auch meiner Überlegung.

Ok ich werde mich nun mal ran machen und das alles in Code fassen. Grundlegend scheine ich ja auf dem richtigen Weg zu sein =)

Melde mich dann später mal bezüglich der Ergebnisse. Danke jedenfalls für eure Hinweise.

Moin !

Ok, so falsch scheint meine Idee also nicht zu sein 😃

Wenn du verhindern willst, dass dein GUI blockiert, brauchst du nur zwei Threads

Ok, gehen wir mal von 2 Threads aus. Ein Input Thread und ein Workerthread. Im Code würde im Normalfall ja sowas stehen:

IInput  _Inp   = new EBC.Input.Inp();
IOutput _Out1  = new EBC.Output.Out();
// Bind 
_Inp.OnX += _Out1.ProcessOut;

Das funktioniert ja dann mit einer Queue so gar nicht mehr, oder? Zudem (wenn ich die Queue mal aussen vor lasse) würde ProcessOut ja dann im Kontext des Inputthread ausgeführt, oder? Letzteres soll nicht passieren.

Muss ich es dann so machen wie ich am Ende geschrieben habe, also Input und Output unabhängig von meiner normalen EBC Kette zu betrachten?

Moin !

Ich habe mich ja in den letzten Tagen und Wochen etwas mehr mit dem Thema EBC (Event based components) befasst. Ich habe inzwischen auch eine Demo wo ich beliebige Verarbeitungsketten aufbauen kann. Allerdings muss ich mir jetzt mal Gedanken zum Generellen Konzept machen und da wollte ich euch um eure Meinung bitten.

Doch zunächst noch ein Problem:
Ich erstelle in meiner Demo eine Datenklasse:

     class DATA
    {
        public double dValue { get; set; }
    }

Diese Klasse übergebe ich denn jeweils dem folgenden Element. Das führt aber zu Problemen wenn man mehrere Ausgaben definiert. Bsp:

Input -> Add12 -> Output1
   |---> Add12 -> Output2

Hier gibt es ein Input element das z.B. einen Wert liefert - sagen wir mal 10. Dann kommen zwei Ausgabestränge. In jedem wird 12 hinzuaddiert. Das führt dazu das bei Output 1 eine 22 rauskommt (OK) und bei Output 2 eine 34. Denn beide nutzten nunmal die gleiche Instanz der Datenklasse.
Wie ändert man das am sinnvollsten?
Derzeit würde ich es so versuchen, das jede "Box" eine Kopie der vorherigen Daten erhält. Bedeutet ... die beiden Add12 bekommen jeweils eine Kopie der Struktur von Input. Und Output bekommt dann jeweils die Struktur von dem davor platzierten Add12.
Damit könnte jeder Zweig autark seine Berechnungen machen.

Aber evtl. gibt es da auch eine bessere Lösung?

So nun zu meiner grundlegenden Idee ...
Problem:
Das grundlegende Problem meiner EBC Datenverarbeitung ist, das alle Berechnungen im Mainthread der Anwendung erfolgen. Und das führt über kurz oder lang dazu das die Anwendung einfriert.

Szenario:
Nehmen wir mal obiges Beispiel als Grundlage:

Input (RS232) -> Add12 -> Output1 (Chart)
           |---> Add12 -> Output2 (Gauge)

Unser Eingang sei mal (das is bei uns später auch so) ein serielles Gerät das daten liefert. Add12 macht jeweils eine Berechnung/Umformung mit den empfangenen Daten. Und Output sei mal ein Chart und ein Zeigerinstrument.

Umsetzung:
Zunächst mal arbeitet die serielle Schnittstelle (bzw. die Komponente) mit einem eigenen Thread. Hier würde ich auch immer versuchen - egal von wo die Daten kommen - das über einen Thread zu lösen. So ist mal sichergestellt das eine hängende Anwendung nicht Daten verliert.
Um nun die Daten unabhängig vom Rest sauber empfangen zu können würde ich jedem Input eine Queue spendieren. Inspiriert von dem hier:
SyncQueue <T> - Eine praktische Job-Queue
Wie ich gelesen habe ist die Queue threadsicher.

Als nächstes gibt es einen Part mit Berechnungen. Also im Beispiel 2x Add12. Hierfür würde ich einen eigenen Thread vorsehen. Und zwar je Eingang ein Berechnungsthread. Dieser holt sich aus der Input Queue die ältesten Daten ab und übergibt die Daten an die Berechnungsmodule.

Die Ausgaben sollten jeweils wieder eine Queue haben. Dort werden die Daten eingetragen die von den Berechungen kommen. Jetzt brauchen wir noch einen Ausgabethread der aus den Ausgabequeues die Daten abholt und in die visuelle Ausgabe einträgt / anzeigt.

Das bedeutet unser Beispiel sieht schematisch nun so aus:

Input (RS232) > Queue -> Add12 -> Queue > Output1 (Chart)
                   |---> Add12 -> Queue > Output2 (Gauge)
---- In Thread ------
                ----- Calc Thread -----
		                  ---- Out Thread ------

Ist das so praktikabel? Kann man das evtl. besser umsetzen?

Ein Problem was ich jetzt mit diesem Konstrukt habe sind die Threads. Bis jetzt war meine EBC Kette immer in einem Thread. Nun müsste das aber threadübergreifend passieren. Als Bsp .. Ich übergebe dem Input die Methode CalcData von Add12. Dann würde doch diese Methode auch im Kontext des Input Thread laufen.
Oder sollte ich das EBC evtl. in anders betrachten ... Es gibt jeweils Eingänge und Ausgänge die mehr oder minder eigenständig arbeiten und es gibt dazwischen die Datenverarbeitung mittels EBC?

Ah ok.

Ich werde es aber erstmal einfach versuchen - also ohne Verbindungsobjekt.

Vielleicht noch eine abschließende Frage (auch wenn ich es jetzt noch nicht umsetze). Wie würde so ein Verdindungsobjekt ganz grundlegend aussehen?

So:

    class Connection
    {
        Inp Input;
        Out Output;
    }

?

Moin !

also z.B. an welchen Positionen die Verdrahtung abknicken bzw. welche Punkt sie durchlaufen soll, dann bräuchte man noch weitere Objekte, um diese Eigenschaften zu repräsentieren und dann wäre es besser, wenn sich jedes Objekt seine Verbindungsobjekte merken würde, statt direkt die Objekte, mit denen es verbunden ist

Der Part ist mir noch nicht so ganz klar. Aber bis ich da ankomme dauert es auch noch etwas 🙂

Ich komme jetzt erstmal weiter. Danke !

Moin !

Was ich derzeit schon habe ist eine generische List. Dort trage ich alle erzeugten Objekte ein.

Wenn ich nun jedem Objekt eine Liste hinzufüge und dort die Folgeobjekte eintrage, würde das dann nicht schon klappen? 🤔

Dann habe ich auf der einen Seite eine Liste mit Objektreferenzen und die Events sind eine ganz andere Schiene ...

Moin !

zu debugging Zwecken ganz nützlich sein kann

Dafür war / ist es auch gedacht.

Im Grunde habe ich ich noch folgendes Problem - denke das passt hier noch einigermassen zum Thema...

Ich progge ja gerade an einem EBC System. Und nehmen wir mal den ganz einfachen Fall : Input -> Output. Also nur 2 Objekte.

Im Code schaut das so:

    class Inp : General, IInput
    {
        public void Run(string text)
        {
            this.OnX(text);
        }
        public event Action<string> OnX;
    }

    class Out : General, IOutput
    {
        public void ProcessOut(string x)
        {
            Console.WriteLine(x);
        }
    }

Davon erstellt man sich zwei Instanzen und erstellt ein Binding:

Inp  _Inp   = new Inp();
Out _Out1  = new Out();
_Inp.OnX += _Out1.ProcessOut;

Das Konstrukt kann man nun am Input mir Run("...") anschubsen und es kommt was bei Output raus. Alles im Lot.

Nun möchte ich aber u.A. eine WinForms Anwendung oben drüber haben mit der ich
a) die Objekte binden kann
b) möchte ich dort natürlich anzeigen welches Element schon mit welchen verbunden ist.

Punkt a habe ich hinbekommen - noch nicht schön, aber es klappt 😉

Aber bei b ist mir noch nichts gutes eingefallen. Meine erste Idee war dann eben über die registrierten Events rauszukriegen, welche Objekte als nächstes in der Kette kommen. Fürs Debugging sicher ok, aber praktisch Unsinn.

Nur wie sonst tun? Meine derzeitige Idee wäre jedem Objekt noch eine Liste anzufügen wo sich die Folgeelemente eintragen. Dann könnte man sich rel. einfach durch die Listen vom Eingang bis zum Ausgang hangeln.

Bedeutet aber glaube ich auch einen ganz schönen Aufwand an Code!?

Hat jemand eine Idee wie man das elegant lösen könnte?

Moin !

geht dies ebenfalls mit GetInvocationList().

Ah, nu hab ichs auch kapiert. Danke 👍

Moin !

OnX!=null

Damit kriege ich ja nur raus ob es leer ist.
Kriegt man auch die Anzahl raus?

unsinnig dies zu tun

Das habe ich schon befürchtet. Das werde ich dann mal anders lösen.

Moin !

Bekommt man eigentlich raus wieviele Actions einer Klasse zugeordnet sind? Und kommt man über die Actions ggf. sogar auf das Objekt?

    class Inp : General, IInput
    {
        public void Run(string text)
        {
            this.OnX(text);
        }

        public event Action<string> OnX;
    }

Dies ist ein ganz simpeles Input Objekt (EBC). Diesem kann ich nun z.B. Ausgänge anhängen / binden:

_Inp.OnX += _Out1.ProcessOut;

Kann ich irgendwie raus bekommen

1. Ob überhaupt und wenn wieviele Actions dort angehängt sind?
2. Über die Action Einträge auf die Objekte kommen? (Also im obigen Beispiel anhand von dem Eintrag in OnX auf das Objekt _Out1 schließen).

Moin !

Nachdem ich mich durch die Blogs von Ralf Westphal gelesen habe und eine grundlegende Demo am laufen habe bin ich doch noch auf ein paar Fragen gestoßen.

1. zu übertragende Daten
   Derzeit basiert meine Demo auf einfachen Strings. Das ist natürlich später so nicht zu gebrauchen. Denn ein Input Gerät liefert im Normalfall eine ganze Reihe an Daten.
   Nehmen wir als Beispiel ein GPS als Datenquelle. Da würde ich z.B. die Daten Höhe, Latitude, Longitude (u.a.) bekommen. Die Frage die sich mir nun stellt ist wie ich die Daten weitergebe. Erstelle ich mir eine Datenklasse die dann eine Liste mit verfügbaren Werten enthält, oder schicke ich die Werte parallel durch?
   Ich denke / vermute mal das es in einer Liste eher sinnvoll ist, oder?

2. Threads in der Kette
   Nehmen wir wieder das Beispiel mit dem GPS. Das sei mal seriell an den Rechner angebunden. In dem Fall hätte ich einen Thread für die Schnittstelle der mir die Daten liefert.
   Wie würde man hier am besten den Empfangsthread von der restlichen Verarbeitung abkoppeln?
   Könnte man das in etwa so lösen: Man erzeugt eine Queue in der die Daten eingetragen werden. Der Mainthread würde dann (über ein Event?) die Daten aus der Liste abgreifen und weiter durch die EBC Verkettung schicken?

3. "Routing" Info erstellen
   Es wäre ganz praktisch wenn man der Verabeitungskette eine Art Kommando geben könnte um diese darzustellen.
   Meine Idee dazu wäre folgende :
   Um Input setze ich ein Kommando ab das in jedem Block der Verarbeitung um einen String erweitert wird.
   Immer wenn die Kette auf einen Output Block stößt, dann wird der resultierende String ausgegeben.

Dadurch würde für jedes Output eine Verarbeitungskette erzeugt. Vermutlich ist das nicht der letzte Schrei, aber man könnte zumindest einen groben Überblick bekommen solange meine grafischen Boxen hat die man zusammenklicken kann.
Wie könnte man das evtl. sinnvoller umsetzen?

Männers,

ich danke euch. Ich glaube EBC war das Schlagwart. Bin eben auf das hier gestoßen: http://ebcbinder.codeplex.com/

Und damit auch auf das hier: http://ralfw.blogspot.com/2010/02/verbindungsstucke-event-based.html

Ich glaube das ist genau der Einstieg den ich gesucht habe.

Moin !

Generic Manipulator Tool

Ja das trifft den Nagel fast auf den Kopf 🙂

Leider gibt es von dem Tool den Sourcecode nicht. Das hätte mich sicher einiges weiter gebracht.
Gibt es evtl. irgendwo von so einem Konzept eine rudimentäre Basis als Code Schnipsel?

Hallo !

Ich habe mal eine generelle Designfrage. Unsere Software (derzeit in Delphi) dient zur Datenauswertung von Geräten die serielle Daten liefern und aus denen wir Kurven plotten.
Nun wollen wir das ganze mit C# umsetzen und je länger ich mich mit der Frage "wie" beschäftige, desto mehr kommt mir der Gedanke da ein eher modulares Konzept zu erstellen.

Also, nehmen wir mal an wir haben ein Digitalmultimeter (DMM) und ein Ausgabefenster was ein Zeigerinstrument (Gauge) darstellt. Und nehmen wir mal weiter an das die einzelnen Teile Module sind die sich der User selber zusammenstellen kann.

Dann könnte er aus diesen Objekten folgende Kette bilden:

DMM -> Gauge

Er könnte aber auch folgendes machen:

DMM -> Gauge
    -> Gauge

Will heissen er hat ein Eingansobjekt (DMM) und 1-n Ausgangsobjekte (Gauge).

Ein anderes Szenario könnte sein:

DMM -> Berechnung -> Gauge

Also ein DMM übergibt seinen Ausgabewert an ein Berechnungsobjekt (das dann nach einer Formel einen Ausgangswert ermittelt) und dieses Objekt wiederum gibt die Daten weiter an ein 1-n Ausgaben (in unserem Fall ein Gauge).

Mit anderen Worten ...
Wie kann ich mit C# solche Objekte mit Daten Ein- und Ausgängen definieren, die der User dann selber verketten kann? Damit meine ich jetzt nicht die grafische Umsetzung sondern eher wie ich das mit den Objekten machen könnte.

Ein Objekt wird ja letztlich durch eine Klasse dargestellt. Und wie kriege ich nun eine Art Datenrouting durch die hintereinanderliegenden Klassen hin? Und wie kann ich dabei auch z.B. mehrere Ausgaben wie beim Gauge durch ein Objekt "bedienen"?

Wäre euch super dankbar wenn ihr da ein paar richtungsweisende Tips oder evtl. auch ein Stück (Pseudo-) Code für mich hättet.

Ok ich bleibe bei Englisch.

Danke für das Feedback.

Moin !

Derzeit habe ich ein Englisches VS 2010 installiert. die IDE ansich ist auch nicht das Problem. Aber die Hilfe könnte man in Deutsch vermutlich schneller verarbeiten 🙂

Hat jemand VS 2010 in Deutsch installiert? Ist die Hilfe ok oder nur maschinenübersetzt?
Spricht generell was gegen ein Deutsches System? (Kommen da z.B. Updates später, ... ?)

Moin !

Der Compiler hat nur einen generellen Fehler ausgegeben. Nichts was man hätte posten können.

Unsinn, SerialPort-Objekte zu serialisieren

Naja so unsinnig ist es ja nicht. Denn es geht ja nicht darum den offenen Port zu serialisieren. Mir geht es eher um die Objektinfos als Port, Baud, Stop / Startbits, etc.
Kurzum das was die Schnittstelle an Konfig hat zu sichern. Da wäre serialisieren schon schön weil man nicht alles selber coden müsste.

Moin !

Ok Danke für die Antwort.
Also werde ich das doch mit einer Liste lösen so wie hier schon vorgeschlagen.
Und dann mit einem eigenen Thread die Daten in die GUI eintragen.

Moin !

Habe gestern mal folgendes probiert:

    [Serializable]
    public class Movie
    {
        public string Title { get; set; }

        public SerialPort _serialport { get; set; }
    }

Ich weiss die Klasse is Unsinn, aber die habe ich zum Teil von hier:
http://www.switchonthecode.com/tutorials/csharp-tutorial-xml-serialization

Und dann das hier:

            Movie movie = new Movie();
            movie.Title = "Starship Troopers";
            movie.ReleaseDate = DateTime.Parse("11/7/1997");
            movie.Rating = 6;
            //movie._serialport = null;
            SerialPort _serialport = new SerialPort();

            XmlSerializer serializer = new XmlSerializer(typeof(Movie));
            TextWriter textWriter = new StreamWriter("movie.xml");
            serializer.Serialize(textWriter, movie);
            textWriter.Close();

Da spuckt dann aber der Compiler.

Kann man so etwas wie einen seriellen port (also eine Komponente) nicht serialisieren? Oder muss man das anders machen?

Moin !

Ok, damit kann ich also die Listenstruktur erstellen.

Was bewirkt das [Serializable] am Anfang?

Und wie kriege ich die Verknüpfung zwischen der "virtuellen" Liste und dem TreeView hin?

Moin !

Ich hätte da nochmal eine Frage wegen einer Umsetzung von Delphi nach C#. Sicher gibs da auch in C# was passendes, aber noch weiss ich nicht wie und wo ich das finde 🤔

Also, unsere Software hat eine Struktur ähnlich dem Solution Explorer in VS. Sprich man kann ein Projekt anlegen und in dieses Projekt verschiedene Elemente einhängen. Das ganze kann man beliebig verschachten.

In Delphi haben wir das so gelöst:
Es gibt eine ObjectList wo man Klassen eintragen kann. Man kann dann eben mittels Index auf die Klassen-Instanzen der Liste zugreifen.

Zunächst haben wir eine globale ObjectListe. Hier werden nur Projekte eingetragen (dafür gibts eine extra Klasse PI_Project (PI = ProjectItem)).
Jede Klasse die man in der Projektstruktur einhängt hat nun selber wieder eine ObjectList. Und dort werden dann jeweils die Subelemente eingehängt.

Im Endeffekt bekommt man also eine Baumartige Struktur die durch ObjectListen realisiert ist.

Das schaut dann also in etwa so aus:

Projektliste
 [0] Projekt 1
  > SubobjectListe 
    [0] Element 1
     > SubobjectListe
       [0] Subelement 1
        > SubobjectListe
    [1] Element 2
     > SubobjectListe
 [1] Projekt 2
  > SubobjectListe

Dabei ist dann Element 1, Subelement1, Element 2, Project 1 & 2 jeweils die Instanz einer Klasse.

Zudem gibt es dann noch einen TreeView der das veranschaulicht. Jeder TreeNode hat dabei einen Pointer der auf die Klasseninstanz zeigt die er darstellt.

Damit konnten wir unser Projekt sehr flexibel abbilden und waren für alles offen ...

Wie könnte ich denn dieses in C# umsetzen?
Oder gibt es (vermutlich) eine sinnvollere Vorgehensweise wie man sowas löst?

Moin !

Danke für eure Antworten.
@herbivore : Das werde ich doch mal testen.

@ujr:

...wenn Du BeginInvoke verwendest, da dies nicht blockiert

Ist das Wirklich so? Kann ich ja gar nicht glauben?
Das bedeutet also ... Ich empfange Daten über die serielle Schnittstelle (die arbeitet auch mit einem eigenen Thread). Wenn Daten ankommen schreibe ich die in eine ListBox:

        private void SetText(string text)
        {
            if (this.listBox1.InvokeRequired)
            {
                SetTextCallback d = SetText;
                this.Invoke(d, new object[] { text });
            }
            else
            {
                this.listBox1.Items.Add(text);
            }
        }

Wenn nun Daten schneller an der Schnittstelle wieder ankommen als der GUI Thread mit dem "schreiben des Textes" fertig ist, dann wird der trotzdem vom Thread sauber verarbeitet?

In Delphi gibs da nämlich ein Problem. Wenn ich aus dem Thread ein Synchronze aufrufe, dann ist der Thread solange angehalten wie das Synchronize dauert. Und das zwingt einen eben dazu das man die Sache mit 2 Threads (Empfang und "Ausgabe" Thread) lösen muss.

Grüße Dominik

Moin !

Ich bin neu hier und komme eigentlich aus der Delphi Welt ... Nun muss ich mich aber vermutlich mit C# auseinandersetzen und ich hät da mal eine kurze Frage wie man etwas umsertzen kann ..

Also in unserer Anwendung haben fragen wir u.a. eine serielle Schnittstelle ab. Das passiert in einem Thread. In diesem Thread erstellen wir einen Pointer auf eine Struktur. Die Struktur bekommt dann die empfangenen Daten.
Der Pointer wird dann an eine verkettete Liste angehängt. Bedeutet Pointer 1 kriegt auch die Adresse von Pointer 2, P2 auch von P3, usw.

Damit kann man sich also durch die eizelnen Pointer und die damit verbundenen Daten hangeln.

Nun gibt es parallel einen Ausgabethread. Dieser Thread schaut ob in der Pointerkette neue Daten angefügt worden. Wenn dem so ist dann holt er sich die Daten vorauf der erste (und zeitlich gesehen älteste) Pointer verweist.
Er löscht diesen Pointer aus der Liste und auch die damit verbundene Struktur.

Die Daten werden dann mit einem Synchronize z.B. in einer Grafik eingetragen. Synchronize macht unter Delphi folgendes ...
Der Thread wird quasi pausiert und die Methode die ich dem Synchronize mitgebe wird im Mainthread ausgeführt. Danach gehts im eigentlichen Thread weiter. Es dient also zur Synchronisation zwischen Mainthread und Empfangsthread.

Soweit die Erklärung wie es jetzt läuft.

Kann man ein solches Konstrukt mit C# auch umsetzen? Oder muss man das dort ganz anders angehen?
Im Grunde geht es ja darum die Daten eines Empfangsthreads mit der GUI in Einklang zu bringen. Und das ohne den Empfangsthread vom Arbeiten abzuhalten.
(Deswegen ist das Synchronize auch im Workerthread in unserer Delphi Umsetzung).

Wäre super wenn mir da jemand ein paar Tips geben könnte.

Grüße Dominik