User32.dll GetGuiResources handle issue

Question

Hi,
I need help in my LabVIEW 2009 vi.I am basically trying to get GDI object count for a process and log the same for certain amount of time (something like Windows task manager-but I intend to use LabVIEW for this purpose as a learning)
I have a prototype vi which gets process ID from a process name (say, notepad.exe), gets a handle to this ID and calls user32.dll [GetGuiResources] method to get the GDI object count. When I use c# for programming, I am able to get the GDI count, but when I follow the same steps in LabVIEW, I do not get the same. I have narrowed the problem to the last step where the 'handle' gets passed to user32.dll. I do not know what Iam doing wrong in the vi. The call to the method also seems fine- No error is reported! I am I doing something wrong while using type cast step?
Steps to reproduce issue: Launch notepad application and run c# file or LabVIEW vi. Observe we do not get the GDI count in case of LabVIEW.
Please suggest me a solution. I have attached both c# code and LabVIEW vi for reference.
Solved!
Go to Solution.
Attachments:
prototype.vi ‏13 KB
Program.txt ‏2 KB

Answer 1

Well, I really doubt that the .Net Object Handle is directly the Windows Handle value itself. This is rather a LabVIEW refnum wrapping the actual object which may or may not be the handle itself. So you can't just typecast this and hope for Windows to recognize it as a valid process handle.
Instead you should treat it as object and execute a Method on it to convert its internal value into a LabVIEW datatype such ans an Int64. ;-)
And btw. running your VI repeatedly will cause a huge memory leak. You have to close every object refnum properly in order to not have LabVIEW and .Net keep creating objects that stay lingering around until you close your LabVIEW app.
.Net has an automatic object deletion that marks all objects whose last referencing variable goes out of program flow scope for deletion. So there is no obj.dispose() or similar method necessary. LabVIEW handles that a little different for various reasons and only deletes objects automatically when the top level VI in whose hierarchy an object refnum was created goes idle.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions
Attachments:
prototype.vi ‏15 KB