LVOOP im Kommen!

' schrieb:Die Anforderung Klassen übers Netz zu laden erklärt die Strings natürlich. Mir kam es nur "komisch" vor, immer diese Stringkonstante mit Classname auf die Factory und danach der Typecast per Classkonstante auf die Zielklasse. Naiv betrachtet frage ich mich da natürlich, warum das nicht per Dynamic Dispatch gemacht wird? (Da habe ich allerdings so ein Bauchgefühl, daß mir da wahrscheinlich noch der entscheidende Durchblick fehlt, warum es eben nicht damit geht)

Es muss immer dann ein Typecast auf eine Kindklasse gemacht werden, wenn das aufzurufende SubVI eben kein Dynamic Dispach VI ist. Ein Dynamic Dispach VI benutze ich allerdings nur dann, wenn ich in Kindklassen dieses VI auch wirklich überschreiben möchte. An einigen Stelle wird nur ein statischen SubVI als öffentliche Methode bereit gestellt und intern das Dynamik Dispatch VI aufgerufen. An diesen Stellen behalte ich mir ein Pre- oder Post-Processing vor. Der Anwender darf nur ein öffentliches VI aufrufen. Die Kindklassen überschreiben es.

' schrieb:Wo ich noch nicht dahinter gestiegen bin, warum sind im HGF_BaseClasses.lvlib:HGF_Factory.lvclass:classes.vi zuätzlich zum "Get LV Class Default Value.vi" noch Konstanten drinnen? Nur zur Vereinfachung des Aufrufs/Builds? In den Beispielen habe ich nach der Factory eigentlich immer die passenden Classkonstanten gesehen, also sind die verwendeten LVClasses eh schon geladen/statisch verlinkt?!?

In LabVIEW 8.2 funktionierte das "Get LV Class Default Value.vi" noch nicht im Executable. Das wurde erst später ermöglicht. Aber in der Tat, wenn man die Fabriken in die Build-Spezifikationen einbindet, hat man alle notwendigen Klassen in der gewünschten Version an Bord. Beim dynamischen Laden von Klassen muss man immer damit rechnen, dass darin Unsinn gemacht werden kann. Daher auch der Laufzeitcheck der Vertrauenswürdigkeit der Agenten-Klassenbibliotheken.
Die Fabriken in den Beispielen werden fast ausschließlich zur Illustration des Mechanismus benutz, um den Neuling an das Konzept zu gewöhnen. Ernst wird es in dem stationären Geräte-Agenten, wo das Objekt erst generisch in der Default-Transition der Zustandsmaschine erzeugt wird. Auch immer dann, wenn Objekte generisch aus einer Datenbank heraus erzeugt werden sollen oder die notwendigen Parameter z.B. über das Netzwerk gesendet werden, ist die Fabrik notwendig, um initialisierte LV-Objekte zu instanziieren.

' schrieb:Was mich auch noch wundert, daß du eine so große Klassenbibliothek ohne "Preserve Runtime Class" hinbekommen hast! Ist das noch ein Relikt aus pre LV2009 Zeiten? Ich vermute die ausprogrammierte "isFriend" Logik ebenso oder reicht da die LV-eigene Library/LvClass-Friends Logik nicht/noch nicht(/zu buggy?) aus?

Genau, auch hier wieder ein Relikt aus LV 8.2. "Preserve Runtime Class" kam erst später. Auch der Community-Scope wurde erst in LV 2009 bereitgestellt.

Es handelt sich also bei der HGF Klassenbibliothek tatsächlich um einen Prototypen, der die Machbarkeit demonstrieren sollte. Ich denke das ist ganz gut gelungen. Insbesondere, wenn ein Student mit einer Diplomarbeit beteiligt ist, der nur endliche Zeit zur Verfügung hat, kann man nicht mit jeder neuen LabVIEW Version ein Redesign veranlassen, wenn es nicht einen wirklich wichtigen Grund gibt.

Außerdem wollte ich das Projekt gern einmal veröffentlichen, um mich der kritischen Diskussion anderer LabVIEW Entwickler zu stellen. Z.B. ist der Entwurf für die VISA-Geräteklassen, HGF_VisaDevice.lvclass, zu kurz gegriffen. Stattdessen sollte die HGF_DeviceBase ein Interface-Objekt als Attribute erhalten, also als Composite entworfen werden. Da ich aber erst genau eine Beispielklase, HGF_NInstrSim.lvclass, implementiert habe, hält sich der Aufwand für das Redesign in Grenzen.

Es gibt noch mehr Stellen die des Redesign bedürfen, insbesondere die SharedVariable-Klassen stellen einen Kompromiss im Hinblick auf die kurze Zeit für die Diplomarbeit dar. Das werde ich demnächst in Angriff nehmen. Vielleicht erhalte ich ja Hilfe aus der Community?

Gruß Holger