fehlende Daten in Elternklasse nach Nutzung einer abgeleiteten Klasse

Hallo zusammen,

ich möchte mich gerade noch tiefer in das Thema Objektorientierung einarbeiten und habe dafür für mein neustes Projekt einen objektorientierten Queued Message Handler aufgesetzt. Dabei bin ich jetzt auf folgendes Problem gestoßen:

Ich habe zusätzlich zu meiner Nachrichtenklasse eine Datenaustauschklasse in meinem Haupt-VI. In der Nachrichtenklasse gebe ich dem auszuführenden VI alle Daten mit, die nur dieses VI benötigt. In der Datenaustauschklasse möchte ich Daten speichern, die ich in verschiedenen VIs immer wieder brauche (z.B. Login-Daten für meine Datenbank).

Von der Datenaustauschklasse habe ich nun zusätzlich noch zwei Ableitungen gebildet: Jeweils eine für meine grundsätzlich unterschiedlichen Funktionen, die mein Programm beherrschen soll (1. Auswertung von Messdaten mit einem Eintrag in die Datenbank, 2. Finden von Einträgen in der Datenbank).

Nun stehe ich vor folgendem Problem (siehe Bild im Anhang): Wenn ich in meinem Do.vi Daten aus der Eltern-Datenaustauschklasse auslesen will, dann funktioniert das prinzipiell mal. Wechsle ich allerdings im Do.vi die Klasse zu einer der abgeleiteten Datenaustauschklassen und will anschließend nochmal aus der Elternklasse lesen, dann bekomme ich plötzlich keine Ergebnisse mehr:

   

Daher meine Frage: was mache ich falsch? Habe ich da noch einen Denk- bzw. Verständnisfehler was LVOOP angeht?

Gruß
Daniel

Anzeige

Moin Daniel
Erst einen grundsätzlichen Hinweis. Bevor Du einen eigenen Queued-Messge-Handler entwicklest, solltest Du Dir das NI Actor Framework anschauen. Das AF ist nämlich ein OO-QMH.

Nun zu Deinem Problem: Bist Du Dir sicher, dass DataExchangeIn wirklich den richtigen Klassentyp hat? Ich empfehle, die Fehlerdrähte der Typycast-VIs auf Problem zu untersuchen.

Gruß Holger

Hallo Holger,

mit dem Actor Framework habe ich mich schon beschäftigt. Meine Idee war, in diesem Projekt mit einem eigenen OOP QMH zu arbeiten, um ein noch tieferes Verständnis für das Thema Objektorientierung zu bekommen (sprich: die Mechanismen, die das AF automatisch mitbringt selbst zu entdecken und dabei besser zu verstehen).

Der Klassentyp am Eingang ist mein generisches Datenaustauschobjekt, von dem ich je nach Bedarf Ableitungen bilde:

   

Wenn ich ganz am Anfang des VIs von der generischen Klassen in die abgeleitete Klasse wechsle, dann kann ich auch den Pfad auslesen. Gehe ich aber am Ende des Vis nochmal eine Klasse tiefer und anschließen wieder zurück, dann klappt das nicht mehr. An den Typecasts bekomme ich keine Fehlermeldungen.

Gruß
Daniel

Wenn die Fehlerdrähte nicht verdrahtet sind, kann man nicht wissen was drin ist, es sei denn die automatische Fehlerbehandlung ist aktiviert. Leider kann ich nicht Hellsehen. Verdrahte sie doch mal, setze Probes drauf und zeige den Screenshot.

Ich sehe auch nicht welche Klasse der Aufrufer an das VI übergibt. Es gibt in der Palette ein VI, mit dem man sich den Klassennamen des Objekt in dem Draht anzeigen lassen kann. Das Upcast vor dem zweiten Lesen des Pfades ist eigentlich unnötig.

Gruß Holger

(24.07.2017 10:13 )BNT schrieb:  Wenn die Fehlerdrähte nicht verdrahtet sind, kann man nicht wissen was drin ist, es sei denn die automatische Fehlerbehandlung ist aktiviert. Leider kann ich nicht Hellsehen. Verdrahte sie doch mal, setze Probes drauf und zeige den Screenshot.

Das habe ich bereits gemacht ... und es wird kein Fehler angezeigt.

(24.07.2017 10:13 )BNT schrieb:  Ich sehe auch nicht welche Klasse der Aufrufer an das VI übergibt. Es gibt in der Palette ein VI, mit dem man sich den Klassennamen des Objekt in dem Draht anzeigen lassen kann. Das Upcast vor dem zweiten Lesen des Pfades ist eigentlich unnötig.

Gruß Holger

In meinem Haupt-VI sieht der Aufruf des Do.VI folgendermaßen aus:

   

Die Klassennamen innerhalb des VI sind diese:

   

Ich würde jetzt eigentlich erwarten, dass Probe [2] wieder die Elternklasse statt der Kindklasse anzeigt.

Gruß
Daniel

Probe 3 zeigt eindeutig, dass Du ein Objekt von Typ 'DataExchange.lvclass' erhalten hast. Der Caller sendet schon kein Objekt der erwarteten Kindklasse.

Gruß Holger

Anzeige

(24.07.2017 12:30 )BNT schrieb:  Probe 3 zeigt eindeutig, dass Du ein Objekt von Typ 'DataExchange.lvclass' erhalten hast. Der Caller sendet schon kein Objekt der erwarteten Kindklasse.

Ich bekomm doch aber nach Probe 1 noch den Wert für SupportFilesPath aus der 'Main - DataExchange.lvclass' ... nur nach Probe 2 bekomme ich den Wert nicht mehr. Zwischendurch gehe ich in der Hierarchie eine Ebene nach unten und anschließend wieder eine nach oben ... nur scheinbar funktioniert das mit dem nach oben gehen nicht so, wie ich mir das vorstelle.

Wie ich schon schrieb: Wenn das Objekt am Eingang schon nicht die richtige Klasse anzeigt, ist alles danach unwichtig.

Und: Solange Du Dich weigerst eine ordentliche Fehlerbehandlung zu implementieren, werde ich Dir auch nicht konstruktive weiterhelfen können, weil es an Informationen fehlt.

Gruß Holger

Vielleicht noch zur Erläuterung:

(24.07.2017 14:03 )kwakz schrieb:  Zwischendurch gehe ich in der Hierarchie eine Ebene nach unten ...

Genau dabei sollte ein Fehler generiert werden (denn Du ja ignorierst) und es wird ein neues Objekt der typdefinierenden Klasse mit den Default-Werten erzeugt! Also ist der Pfad in dem Attribute leer.

Holger

(24.07.2017 15:07 )BNT schrieb:  Vielleicht noch zur Erläuterung:

(24.07.2017 14:03 )kwakz schrieb:  Zwischendurch gehe ich in der Hierarchie eine Ebene nach unten ...

Genau dabei sollte ein Fehler generiert werden (denn Du ja ignorierst) und es wird ein neues Objekt der typdefinierenden Klasse mit den Default-Werten erzeugt! Also ist der Pfad in dem Attribute leer.

Holger

Guten Morgen,

das hilft mir auf jeden Fall weiter ... dass beim Wechsel der Klasse ein neues Objekt erzeugt wird war mir nicht bewusst und erklärt natürlich das Verhalten.
Die Fehlerausgänge hab ich jetzt alle verbunden ... und es wird der Fehler 1448 erzeugt.

Wenn ich das also recht verstehe, dann muss beim Aufruf der Methode bereits die Kindklasse übergeben und nicht die Elternklasse? Das bedeutet dann aber, dass ich die Eigenschaften der Elternklasse, auf die ich ja in beiden Kindklassen zugreifen will, auch für beide Kindklassen setzen muss?

Gruß
Daniel