LabVIEW
how to get currently running application names on windows
@PincoG wrote:
Hi Agree with you that is not more the time for windows API, but the result from Jannis FC_WindowsProcesses output a Windows Title, that is not the Property changed with "SetWindowsText" that your older List_of_application correctly show. Wich property Have I to choose?
For me the Windows API is still the prefered way. It is a lot more stable than the whole .Net circus. Yes it is not as easy as point and click a few methods together, and if you do something wrong you can really easily simply crash into nirvana. And .Net has some neat convenience libraries that are much harder to do in Win32 API.
But if you get things done properly in Win32 API, it works and works across a large number of OS versions without needing to load a many 100MB framework first and sideloading extra libraries that may or may not be compatible with the framework that LabVIEW or one of your other .Net components preferably wants to use.
@rolfk ha scritto:
And to make this Windows 64-Bit compatible all the parameters including the return value for FindWindowEx() and the first parameter of the other two Call Library Nodes should be changed to pointer sized integer types. But that is only an option from LabVIEW 8.6 onwards.
Without this change the VI will behave rather badly on the 64-Bit version of LabVIEW for Windows.
I also think that a return value of 0 for FindWindowEx() is in fact the proper way to terminate the loop. An input value of 0 for the second parameter will then start to enumerate the first child window of the desktop again but it makes no sense to do that extra loop iteration.
So, because I have no other way, I will apply this advice, even if I never made a 64bit application.
Also parameters passed by Value, should be changed to Pointer-sized ?
@PincoG wrote:
Also parameters passed by Value, should be changed to Pointer-sized ?
What do you mean by this? The parameter passing is either by value or pointer to value, and that is absolutely independent of bitness but simply how the API developer decided to pass the parameters.
Pointer sized is a different thing. This is the actual sizing of the numeric value, which for pointer sized types will vary depending on the bitness.
They are both distinctive and very different configurations, despite the word "Pointer" in both of them!
@PincoG wrote:
Hi Agree with you that is not more the time for windows API, but the result from Jannis FC_WindowsProcesses output a Windows Title, that is not the Property changed with "SetWindowsText" that your older List_of_application correctly show. Wich property Have I to choose?
The .net solutions online all use user32 and kernel 32 to get window titles.
In this case, the goal just doesn't fit .net framework's goals. You'll be better off using Windows APIs.
Search LabVIEW like a graph!
@PincoG wrote:Also parameters passed by Value, should be changed to Pointer-sized ?
Probably.
Values will probably be converted to a 64 bit value anyway on 64 bit LabVIEW.
So it would be better, but it doesn't seem to make a difference.
