LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I identify different instances of an executable?

You could probably also use various workarounds, but I can't say I would consider them elegant:

 

  1. Use a non-reentrant VI with a First Call and a feedback node to return a GUID or UUID per instance. Has a non-zero chance of duplicating based on the GUID algorithm.
  2. Pass an ID as a command line parameter. That means you need a caller to launch these which would be "non-reentrant" and can use something like the current time to a high resolution or a running counter stored in a file to assign the IDs.

___________________
Try to take over the world!
0 Kudos
Message 11 of 15
(1,961 Views)

You can also check here.

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 12 of 15
(1,898 Views)

@mikeporter wrote:

You can also check here.

 


Good to know (apart from the fact that I have no idea which class to look into to get access to these functions).

What is the advantage (if any) of using .NET versus a direct call to kernel32.dll?

0 Kudos
Message 13 of 15
(1,867 Views)
Well you could download the code. Plus that code wasn't intended to run in the executable being managed. It's for another process to see how the executable is doing.

The important part would be to pass the identifying information to the executable as it is launched.

Having a unique identifier is only helpful if its unique AND useful. Randomly generated numbers and PIDs for the most part are not.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 14 of 15
(1,852 Views)

The advantage of .Net is that it is generally easier to develop (if you know where to look for what class and methods to use) than fiddling with Call Library Nodes which will generally do bad things to LabVIEW and your app if they aren't perfectly correctly configured and setup. And it may sometimes appear to work without crash but still corrupt something and you may only run into that problem when you deployed the application in a remote application where you have to take an airplaine to get there! 🙂

 

But if you know Call Library Nodes well and how to correctly use them, then it's definitely an advantage to go the direct kernel32.dll path as this will not invoke an extra 100MB .Net runtiime system for a simple OS call.

Rolf Kalbermatter
My Blog
0 Kudos
Message 15 of 15
(1,839 Views)