how to get currently running application names on windows

[Amy2312]

Wiebe,

Thanks for your quick reply. In my system, processes keeps changing in some instance or other.

Yes, I am pretty sure that this is the VI which hangs. I tried to debug and I found that at some random point, this VI keeps counting the processes continuously in the attached while loop (i.e. it keep searching for first hWnd number and never found it, so it stays in that loop only). May be because of that, the memory allocation for the array (initialized at the top-right of while loop) keeps increasing. Eventually, which may cause the LV memory full error.

If I remove this VI from my application then yes I dont get any error and all works fine.

After recognizing all of this, I made small improvements in this VI as shown in attachment no.2 and after that, I havent seen any memory full error yet but the LV still crashes. I am affraid that might this is because of Call Library Node we are using in this VI. Can you please check the Call Library Node in a seprate VI with Null inputs and a hWnd indicator only. See wht happens and please suggest solution if any.

Regards.

[wiebe@CARYA]

Hi,

Nice debugging! That explains the hanging. The first call to the API returns the "first" hWnd. Then the loop repeats until all windows are visitted, and it should start over again with the first. If the fist hWnd is closed, the loop will never stop.

Your solution is valid, but a bit crude. You might as well us a for loop with x wired to the N, and a stop terminal. That is cleaner then the while loop used this way. Obviously, the data returned is bogus, the list of entries will repeat itself.

The attached solution searches the found windows, and stops when a found window is returned. Apparently, the FindWindowEx function returns 0 once in a while (actually, every time). It should indicate an error, but it looks like it also returns 0 when the last window in Z-order is returned (I don't think it should). Others seem to run into this: http://msdn.microsoft.com/en-gb/library/windows/desktop/ms633500%28v=vs.85%29.aspx. So it also stops when 0 is returned.

I also changed the thread the DLL is executed in, it might interfere with UI updates when it runs in the UI Thread.

That leaves the crash... Whatever I use as input, it won't crash. 0, or a random number. Berhaps you can run it with indicators on the front panel, so you can see the last use values before the crash.

Regards,

Wiebe.

[rolfk]

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.

[Amy2312]

Wiebe,

Thanks for revised VI. I will check that with my application and let u know about the progress.

Regards.

[wiebe@CARYA]

Rolf,

You could be right about the zero (it seems to do that). But I do recall that it used to rotate, so when hWndPrevious is the last in Z-order, it would return the first one. That might be the behaviour when you use class names and\or window names.

Amy, feel free to remove the array search, and abort the 1st loop if the result is 0. If it works, it works and there is no need to do search.

Regards,

Wiebe.

[gorkyshaw]

thanks ga101 a lot for the VI which looks very simple, but is difficult. I am using it in my programs.

Gorky Shaw

[haydon]

Hi, 

  When I try to use you program. the FindWindowEx function is good before program crashed, But I step to debug find that the program will generate an array of hWnd then transfer to "GetWindowLongA" then program is stopped and exit Labview directly. My OS is Win7, 32bit, Labview is 2012. Could you help check if any error in parameter setting ?

[rolfk]

Go into the VI and change in all Call Library Nodes the calling convention to stdcall. Almost every Windows API is stdcall. In LabVIEW versions before 2009 LabVIEW tried to be smart and changed the calling convention silently to stdcall if the exported function name matched a certain pattern. They removed that in 2009 because it prevented the calling of functions who happen to use that naming pattern but were explicitedly declared cdecl by the DLL programmer.

[haydon]

Thanks, I have modified this and the program is okay to use. but it is stange that when use original program in High level PC with 4 core CPU. It is okay....Anyway , Thank you.

[rolfk]

---

@haydon wrote:

Thanks, I have modified this and the program is okay to use. but it is stange that when use original program in High level PC with 4 core CPU. It is okay....Anyway , Thank you.

---

That is with the same LabVIEW version and bitness as the one where it crashes? That would be indeed strange. The wrong calling convention will for sure mess up the stack and therefore always crash as soon as the first Call Library Node has executed. Have you checked the debugging level in the CLN configuration? It is imaginable that the highest error handling level in there might attempt to recover the stack frame around CLN calls, but that is a rather expensive thing to do and should not normally be enabled after you debugged your code properly.