Fatal Error:LabVIEW.LIB could not locate "PostLVUserEven"

' schrieb:Ein Thread der von einem Out Of Process Server gestarted wurde. Da das ein anderer Prozess ist als Deine LabVIEW Applikation, hat der auch keinerlei Idee von einer lvrt.dll und selbst wenn er die fände wäre das sinnlos, da Userevent Refnums nur in dem LabVIEW Context Sinn machen der sie auch erzeugt hat (und mit Context meine ich hier nicht nur den LabVIEW Prozess sondern die Application Referenz, wobei beispielswiese ein VI aus einem Project aufgestartet eine andere Applikation Referenz hat als ein anderes VI das global oder aus einem anderen Projekt heraus gestartet wurde).

Ok, jede DLL hat ja einen Eintrittspunkt, so auch meine. Dort kann man den "Grund" des aufrufs abfangen. Mittels DLL_PRocess_Attach (so oder so ähnlich) wird mein Objekt erzeugt. Das heisst die DLL wird als Process von LabVIEW.exe aufgerufen. Den Thread starte ich innerhalb der DLL, also doch im selben Process einen neuen Thread, oder irre ich mich?

Anzeige

' schrieb:Ok, jede DLL hat ja einen Eintrittspunkt, so auch meine. Dort kann man den "Grund" des aufrufs abfangen. Mittels DLL_PRocess_Attach (so oder so ähnlich) wird mein Objekt erzeugt. Das heisst die DLL wird als Process von LabVIEW.exe aufgerufen. Den Thread starte ich innerhalb der DLL, also doch im selben Process einen neuen Thread, oder irre ich mich?

Wenn und nur wenn die DLL durch Deine LabVIEW Applikation aufgerufen wird. Wird das in Deinem Camera Treiber in einem Out Of Process Server gemacht, dann ja dann.... ist da kein LabVIEW.exe und auch kein lvrt.dll oder so und dann ist da auch keine PostLVUserEvent() Funktion.

Ich denke aber mal nicht dass Du dem Treiber einen DLL Namen und einen Funktionsnamen übergibst um aufzurufen aber eventuel schon einen Callback Funktionspointer und das ginge dann halt auch nicht wenn der diese Funktion nicht innerhalb des DLL Kontextes aufruft, denn Du von Deiner LabVIEW Applikation aufgerufen hast. Das kann zum Beispiel sein wenn die Camera Treiber DLL nur das ActiveX Frontend zu einem Out-of Process Treiber ist, etwa einem Serviceprozess der mittels ActiveX Marshaling mit diesem Frontend mittels RPC kommuniziert.

Aber ich kann mich da stundenlang im Kreise drehen um zu versuchen Dir dies mit immer neuen Worten zu erklären. Nur Du weisst was Du für einen Treiber aufrufst und hoffentlich ist es Dir auch möglich herauszufinden wie der intern aufgebaut ist und allfällige Callbacks ausführt. So wie es aussieht wird eine Funktion von Deiner DLL, die irgendwie PostLVUserEvent() aufruft NICHT im Kontext Deines LabVIEW Prozesses aufgerufen. Warum, wie, wo und überhaupt kann ich dir aber nicht erzählen.

Rolf Kalbermatter

' schrieb:So wie es aussieht wird eine Funktion von Deiner DLL, die irgendwie PostLVUserEvent() aufruft NICHT im Kontext Deines LabVIEW Prozesses aufgerufen. Warum, wie, wo und überhaupt kann ich dir aber nicht erzählen.

Rolf Kalbermatter

Erstmal Danke das du dir die Zeit nimmst. Wie in meinem geposteten Quellcode gezeigt weiß ich genau wann ich was aufrufe. PostLVUserEvent hat nichst mit der Hersteller DLL zu tun. MoveBlock wird einen Schritt vorher ja auch ausgeführt. Diese Funktion bezieht sich ja auch auf die LabVIEW.lib. Deshalb verstehe ich es auch nicht.

Ok, so wie es scheint wird die DLL einfach aus LabVIEW aufgerufen, obwohl der Source Code schaut komisch aus. Einige Dinge sind wohl C++ Eigenheiten wie der Übergabeparameter bei this->Grab(void *buf) und das kenne ich wirklich nicht, aber bei NumericArrayResize() vermisse ich ganz eindeutig den Handle Parameter selber.

Ansonsten habe ich auch keine Idee was abstrakte C++ Klassen genau bewirken und ob die eventuel eine Instantierung in einem eigenen Kontext bewirken könnten. Und der Umstand das MoveBlock und NumericArrayResize die zuvor aufgerufen werden keinen solchen Fehler verursachen weist darauf hin das das nicht das Problem ist, da ansonsten ALLE LabVIEW Manager Funktionen so einen Fehler produzieren müssten.

Bleibt meiner Meinung nach nur noch eine Sache übrig. PostLVUserEvent wurde erst mit LabVIEW 7.1 verfügbar. Kann es sein dass Du das alles irgendwie in LabVIEW 7.0 versuchst auszuführen????

Rolf Kalbermatter

' schrieb:Ok, so wie es scheint wird die DLL einfach aus LabVIEW aufgerufen, obwohl der Source Code schaut komisch aus. Einige Dinge sind wohl C++ Eigenheiten wie der Übergabeparameter bei this->Grab(void *buf) und das kenne ich wirklich nicht, aber bei NumericArrayResize() vermisse ich ganz eindeutig den Handle Parameter selber.

Du hast recht. Entschuldige, ich habe diesen Aufruf als Klassenfunktion deklariert. Das heisst in meinem Fall rufe ich NumericArrayResize() als Funktion der Klasse auf. In das Handle holt es sich aus der Klasse. Ist hier beim reduzieren verloren gegangen.

Anson

' schrieb:sten habe ich auch keine Idee was abstrakte C++ Klassen genau bewirken und ob die eventuel eine Instantierung in einem eigenen Kontext bewirken könnten. Und der Umstand das MoveBlock und NumericArrayResize die zuvor aufgerufen werden keinen solchen Fehler verursachen weist darauf hin das das nicht das Problem ist, da ansonsten ALLE LabVIEW Manager Funktionen so einen Fehler produzieren müssten.

Bleibt meiner Meinung nach nur noch eine Sache übrig. PostLVUserEvent wurde erst mit LabVIEW 7.1 verfügbar. Kann es sein dass Du das alles irgendwie in LabVIEW 7.0 versuchst auszuführen????

Rolf Kalbermatter

Ich rufe es mit auf.

Nicht immer sind Fehlermeldungen richtig. Will sagen, wenn da steht "LIB could not locate", dann heißt das noch lange nicht, dass das auch genau so stimmt. Möglicherweise hat der MoveBlock (bah, wer verwendet denn solche Befehle) was überschrieben.

' schrieb:Nicht immer sind Fehlermeldungen richtig. Will sagen, wenn da steht "LIB could not locate", dann heißt das noch lange nicht, dass das auch genau so stimmt. Möglicherweise hat der MoveBlock (bah, wer verwendet denn solche Befehle) was überschrieben.

Welchen würdest du denn verwenden?

' schrieb:Welchen würdest du denn verwenden?

Einen "selbstsicheren" Befehl - oder eine entsprechende Methode. Also irgendwas, das von sich aus dafür sorgt, dass nur aus erlaubten Bereichen gelesen wird, dass nur in erlaubte Bereiche geschrieben wird und dass nur erlaubte Bereichsgrößen verhandelt werden.

Ich würde hier jetzt mal wie folgt vorgehen.

Zuerst mal den Post weglassen und kucken, ob denn alles absturzfrei funktioniert. Funktioniert es nicht, liegt es nicht am Post oder daran, dass der nicht lokalisiert werden kann. Wenn der Fehler an einem fehlerhaften MemMove liegt, dann würde der Fehler jetzt wo anderes auftreten.
Dann würde ich den MemMove und alles was damit zusammen hängt (LVMem?) weglassen und dem Post als Daten einen Leerblock oder eine Konstante übergeben. Auf jeden Fall irgendwas, das nicht durch Create oder MemMove erzeugt worden ist (Speichermanager!). Möglicherweise ist auch ein Test mit einen ganz einfachen Event-Typ erforderlich. Kommt jetzt nicht mehr die Meldung "could not locate PostLVUserEvent" - dann hast du ein Problem. Hier tippe ich doch auf einen "beschädigten Speichermanager etc". Würde auch mit einem einfachen Event und konstanten Daten (ohne Speichermanager!) die Meldung erscheinen, wäre das Problem nicht geringer - es läge nur wo anders. Möglicherweise doch daran, dass DLL und LV unterschiedliche Speicherbereiche haben.

Die Fehlermeldung selbst klingt schon so, als ob die DLL/Lib ein Problem hat, eine Funktion zu finden (nämlich eben PostLVUserEvent). Kann man den Namen (mit Pfad?) der Library vor die Funktion setzen? Vielleicht gibt es ja eine LabVIEW.LIB in der der Befehl gar nicht drinnen ist?

' schrieb:Nicht immer sind Fehlermeldungen richtig. Will sagen, wenn da steht "LIB could not locate", dann heißt das noch lange nicht, dass das auch genau so stimmt. Möglicherweise hat der MoveBlock (bah, wer verwendet denn solche Befehle) was überschrieben.

Diese Fehlermeldung ist aber schon in LabVIEW.LIB und tritt genau dann auf wenn LabVIEW nicht die entsprechende Funktion mit LoadLibrary() laden kann. MoveBlock() könnte da eher wenig machen, oder er müsste die Exporttabelle des LabVIEW Kernels (LabVIEW.EXE oder lvrt.dll) selber überschreiben. Sehr unwahrscheinlich dass er dabei nur diese eine Funktion erwischt und nicht noch weiss ich was alles andere.
Warum dann schon diese eine Funktion nicht verfügbar ist, aber nicht die anderen wie MoveBlock() oder NumericArrayResize() ist schon etwas komisch. Das verwirrt mich tatsächlich ziemlich.

Mit MoveBlock() ist übrigens nichts falsch. Da kann man natürlich weiss nicht was alles versuchen um so eine Funktion sicherer zu machen, aber keine Variante schützt zuverlässig davor einen verkehrten Parameter zu benützen. Das Windows API kennt zum Beispiel Funktionen wie BadPtr() die einmal in Windows 3.x Zeiten eingeführt wurden. Scheint eine wunderbare Funktion zu sein, aber erstens hat sie Threadingprobleme (ja Windows 3.1 war halt nicht Multithreading), die Performance ist katastrophal, und die Implementation beruht intern doch nur auf Exceptions. Kann man alles auch viel einfacher haben indem man direkt Exceptions verwendet. Aber das fängt halt immer noch nur NULL Pointer und Pointer ausserhalb des gültigen Prozessheaps ab. Ein Pointer der zufällig irgendwo in den gültigen Prozessheap weist wird immer noch als gültig erkannt.

Natürlich kann man auch alle Memorybereiche objektialisieren und nur noch Memberfunktionen dieser Objekte darauf zulassen, aber man kann auch mit Kanonen auf Spatzen schiessen.

Rolf Kalbermatter

' schrieb:Warum dann schon diese eine Funktion nicht verfügbar ist, aber nicht die anderen wie MoveBlock() oder NumericArrayResize() ist schon etwas komisch.

Kann man LIBs, wie DLLs, dynamisch laden? Naja, beim Kompilieren findet der Kompiler die Funktion zwar in der einen LabVIEW.LIB, die (LV-)Exe verwendet aber eine ganz andere LabVIEW.LIB - ohne dieser Funktion.

Zitat:Das verwirrt mich tatsächlich ziemlich.

Wie käme ich sonst auf so Gedanken wie oben und mit dem MemMove.