What signal does an LV app receive when attempting to start a new instance?

[mje]

So, I have an application which customers really want to be able to have multiple instances running. No problem, the quick cludge is to just do the AllowMultipleInstances=True ini setting. For now...

But this is pretty much avoiding the larger issue. Things like config settings become competitive within the application when multiple versions of it are running, memory is also an issue since entire instances of the RTE and VIs get loaded into separate processes...basically the app wasn't designed for this. However even worse, controlling access to singleton type third party resources becomes at best undefined (mostly arising from queues/semaphores/etc not moving past process boundaries).

I'm considering updating the underlying architecture in one of two ways: keep the instances as completely separate processes (which will involve some minor tweaking, but will not solve all my issues), or having a central app manager model that spawns re-entrant versions of the main UI VI (which could save on the overhead of having multiple RTEs and VIs, but also introduces risks since one large memory pool will be used which could take down ALL "instances" if something goes wrong, and memory consumption of the application can be significant).

The question is: When you have an application that does *not* allow multiple instances, does the application receive any signal from LabVIEW or the OS when the user tries to launch the exe a second time? I'd really like to keep the behavior of each time you click the exe, a new window appears even if I go to the application manager model...

[Rolf Kalbermatter]

The question is: When you have an application that does *not* allow multiple instances, does the application receive any signal from LabVIEW or the OS when the user tries to launch the exe a second time? I'd really like to keep the behavior of each time you click the exe, a new window appears even if I go to the application manager model...

LabVIEW really does some custom stuff here as it is not Windows common behavior and not even supported by Windows out of the box. I believe what LabVIEW is doing here is simply detecting if another instance of the same LabVIEW version is running (how that is done is another question, possibly a shared global variable in shared memory or such) and on detecting that sending all its command line parameters to the other application instance through DDE. At least that is how it was done in LabVIEW 5 and 6. The LabVIEW DDE server supports passing commands to its system topic since that is the means File Manager used to pass file paths to an application and it is still the way Windows Explorer passes parameters to an already running application when you double click an application file.