Tasking Library

' schrieb:Anders (abgesehen von Variant o.ä.) kann ich mir keine Library solcher Art, die projektunabhängig verwendet werden kann, vorstellen.

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.

' schrieb:Die Werte der Member Variables befinden sich im Klassen-Wire, warum sollte man die noch extra irgendwo abspeichern. Oder besser gesagt, ich verstehe nicht so ganz was gemeint ist.

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 ...

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 ...