LabVIEWForum.de - Aufruf der user32.dll führt zum Absturz von Labview

LabVIEWForum.de

Normale Version: Aufruf der user32.dll führt zum Absturz von Labview
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hallo,
bin zur Zeit am Erstellen eines größeren Projekts und Labview beendet sich beim Aufruf der user32.dll mit der Funktion keybd_event komplett. In den Labview Versionen 8.6 und 2009 funktioniert das jedoch ohne Probleme. Diese Windows-Funktion hat die Aufgabe einen Tastendruck der Print-Screen Taste zu emulieren, damit ich dieses Bild im Anschluss aus der Zwischenablage entnehmen und abspeichern kann.
Kann bitte jemand diesen Bug verfizieren? Bzw. hat jemand eine Idee für das Lösen des Bugs?
Anbei ein Bild auf dem Block-Diagramm
[attachment=30009]

Vielen Dank im Vorraus
Aptiva
Hallo,

du kannst alternativ auch auf anderem Wege einen Screenshot machen.

lG nookie

[attachment=30012]
Die Variante geht leider nicht, da ich nicht vom Frontpanel, sondern von einem anderen Programm einen Screenshot machen muss, das im Hintergrund läuft
' schrieb:Hallo,
bin zur Zeit am Erstellen eines größeren Projekts und Labview beendet sich beim Aufruf der user32.dll mit der Funktion keybd_event komplett. In den Labview Versionen 8.6 und 2009 funktioniert das jedoch ohne Probleme. Diese Windows-Funktion hat die Aufgabe einen Tastendruck der Print-Screen Taste zu emulieren, damit ich dieses Bild im Anschluss aus der Zwischenablage entnehmen und abspeichern kann.
Kann bitte jemand diesen Bug verfizieren? Bzw. hat jemand eine Idee für das Lösen des Bugs?
Anbei ein Bild auf dem Block-Diagramm
[attachment=58978:LV_crash.JPG]

Vielen Dank im Vorraus
Aptiva

Könnte es sein dass Du in Deiner CLN den absoluten Pfad zu user32.dll hast stehen? Das das crasht ist nämlich ein bekanntes Problem und steht so auch in der Bugliste für 2010. Für DLLs im Systemverzeichnis (und wohl auch Windowsverzeichnis) muss man spezifisch NUR den DLL Namen einführen. Nach schliessen und wieder öffnen steht da zwar wieder der absolute Name aber solange man daran nichts editiert sollte noch immer der DLL Name alleine abgespeichert bleiben und dann crasht es nicht.
Danke, werd das eben mal schnell ausprobiern...
So habe es mal ausprobiert und verschiedenes andere auch.
Hilft leider nichts, LV crasht leider immer noch. Auch im NI-Forum wird von dem Problem berichtet:
http://forums.ni.com/t5/LabVIEW/Can-i-make...p/534790/page/4
Hallo

bei funktioniert es so ...

WindowsXP prof. LV2010
Lv10
[attachment=31774]

gruß T
Danke, der Vorschlag von toaran_ funktioniert. Er unterscheidet sich durch die Verwendung der Funktion "Run in any Thread" bei der Thread Option. Des weiteren sind die Eingangsdatentypen anders. Anscheinend hatte ich den Aufruf aus einem Beispiel aus dem LV Forum kopiert.
Die älteren LV-Versionen sind fehlertoleranter, da diese alte Vi auch in den LV Versionen 8.6 und 2009 funktioniert hat. Kann somit als gelöst betrachtet werden.

Fehlerursache ist somit, die Übergabe eines falschen Eingangsdatentypes in einen DLL-Aufruf führt zum Absturz von LabView...
Also ich habe mir mal schnell die MSDN Dok angeschaut und Dein ursprünglicher Code war definitief falsch konfiguriert.

MSDN sagt dazu:

Code:
VOID WINAPI keybd_event(
  __in  BYTE bVk,
  __in  BYTE bScan,
  __in  DWORD dwFlags,
  __in  ULONG_PTR dwExtraInfo
);

Man müsste also die Parameter als folgt definieren:

U8
U8
U32
Pointer sized integer

Die ursprüngliche Konfiguration verhaut durch die unterschiedlichen Parametergrössen den Stack, und WINAPI kann damit absolut nicht umgehen (wenn LabVIEW dazu nicht noch einen extra Stackframe und weitere Protection hinzufügt, was man in LAbVIEW 2010 mit dem Maximum Debug Level bei der Call Library Node erreicht), wobei die Funktion dann aber einen Fehler zurückgibt, da der Stack eigentlich zerschossen wurde. Und wenn man Pech hat kracht es auch trotz der extra Protection. Eigentlich ist das nicht Pech sondern Glück, denn auch wenn es auf der Entwickelmaschine in der CLN nur einen Fehler generiert statt zu krachen, kann das auf einem anderen System plötzlich doch in einen Crash enden.
Referenz-URLs