Tasking Library

' schrieb:genau DAS is der Punkt. Nach meinem Empfinden MÜSSTE das mit LVOOP gehen. Wenn ich die entsprechenden Dokumentationen zu dem Thema richtig verstanden haben ist es ja genau dafür gemacht, dass man sich Bibliotheken erstellt, die man in vielen Projekten verwendet und lange pflegt, aber GENAU IN diesem Punkt versagt das Konzept immer wieder, und das find ich nicht nur schade, das regt mich sogar auf, weil ich mich irgendwie verarscht fühle.
nach meinem Verständnis speichert und verwaltet ein Objekt seine Members. Das ist bei LVOOP nicht der Fall, allerdings kann man es relativ schnell "nachrüsten" in dem man eine Feedback Node ins Blockdiagramm legt ...

Dieses versagt in jeder anderen Programmiersprache. Man muss den Datentyp entweder global und projektabhängig definieren, oder halt datentypunabhängige Übertragungsmethode verwenden und Datentyp casten.

' schrieb:Aber zurück zum Konzept: Meine Meinung nach läßt sich sowas nur sinnvoll und zukunftssicher implementieren, wenn LVOOP "vernünftig" funktioniert: man schreibt sich eine Basis-Klasse, die sich um den ganze Queue Kram und die Typ-Sicherheit kümmert, mit dem Datentyp "leerer Cluster". Die eigentlichen Tasks (ich nenn das "Module") sind dann immer Kinder von der Basis-Klasse und erben alle Methoden und überschreiben den "leeren Cluster" mit ihrem eigenen Datentyp. Aber leider stoß ich immer wieder an die Grenzen von Objekten und Queues *grrrr*. Mein Haupt-Kritikpunkt ist: man muss - bisher - die Type-Propagation aufgeben und damit verliert man einen der großen Vorteile von LV, aber gerade das sollte man doch verhindern können, wenn man dynamic Dispatching verwendet, aber renn ich immer vor ne Wand ...

Ich glaube du verwechselst etwas mit dem Polymorphysmus. Du kannst mit LVOOP ruhig solche überladende Methoden machen und es ist ähnlich oder fast genauso wie polymorphe VIs im nativen LV.

Ich denke du stellst viel zu viele Anforderungen an LVOOP. Es ist wirklich fast nur ein Datencluster mit einigen Verbesserungen.