03-24-2014 11:15 AM
Has anyone ever noted: If you change the "Front Panel Window: Title" programmaticly in a build LabView application, it doesn't reflect in the .Net Process MainWindowTitle.
Bummer! It would make it easier to tell different application instance apart.
12-02-2014 05:26 PM - edited 12-02-2014 05:28 PM
@wiebe: Thanks for providing the List_of_applications VI! It took a while to figure out I needed to change the style value being checked in order for the VI to find my LabVIEW executables (I used 0x16CA0000, which works for most of my LV programs; but I also got good results using 0x10020000).
I have converted it into a VI that just identifies the topmost application, which has one use as a round-about way to have multiple programs access hardware (only allowing the topmost program to talk to the hardware that more than one program uses).
12-03-2014 05:18 AM
Razurbeam,
That is a nice usage of the code!
I guess if I had to make it today, I'd use .NET and LabVOOP, creating a much more powerful library. If only I had more time, and perhaps less ideas.
Regards,
Wiebe.
05-19-2015 06:29 AM
How to get all the applications that are open in any user account from these vis. I have tried all posted vis and it seems all list the applications open under current useraccount only.
05-19-2015 08:02 AM - edited 05-19-2015 08:10 AM
Do you mean list all applications running on one computer, but started as different login? Or the "user" as in the task manager list, like SYSTEM, LOCAL SERVICE, etc?
Regards,
Wiebe.
05-19-2015 08:14 AM
Not sure if it will list all users tasks, but from the command line:
tasklist
will give a list of processes and services.
Regards,
Wiebe.
10-05-2017 06:01 AM
the given attachment processes_vi can not open on my windows....plz ckeck it.
i really need it..
10-05-2017 06:41 AM
@kbp1 wrote:
the given attachment processes_vi can not open on my windows....plz ckeck it.
i really need it..
Checked it. Works fine for me.
Be more specific in why it's not working, OS, LV version, etc.
04-04-2019 01:47 AM
Wiebe@CARYA wrote:
I've search for a .net solution first, but didn't find one! I gave up early,
I really don't like to work with it, although I have to admit it's pretty
easy if you know where to look. (I got burned with AX a few times, and don't
want to make this mistake with .net.)
Wiebe.
Just a quick comment on this 11 years old post.
.NET rocks, and I use it all the time now... Looks like most of the AX problems (early binding, lack of backwards\forwards compatibility, etc.) are not there with .NET.