LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Detect Repeat Application Run by User

Solved!
Go to solution

Hello,

 

I've got a design structure problem that I could use some help with, and am wondering if anyone has some ideas. I have a program that will need manage some shared resources (files, com ports, other connected devices), and respond to a variety of inputs (interprocess communications in a few forms, plus possible user input). Some of these various inputs can influence others (for example, an interprocess command may be to shut down the user interface...temporarily). In general, my plan is to design this as background process, and simply have it operate as a controller for all of these various inputs. It'll spin up the interprocess communications, and hide/show user interfaces accordingly.

 

One thing though that I'd like to do is have an event be triggered when the user attempts to "run the executable." Ideally, I'd like it to be a single executable from their view, so the application will be run on startup, but also can react if they attempt to manually run it. Now, I don't particularly want it to run multiple instances, but do what to detect and react when they try. Based on this, I have a few thoughts, but am looking for feedback:

 

1). Do allow multiple instances, but have the "main" application continually look for the second instance, and if it occurs trigger my event accordingly. I don't particularly want to be polling for additional application instances, and I do believe there are some methods to load them into the same process and therefore share information, but this seems excessive when I simply want to detect and react.

 

2). Create a "loader process" that is actually a separate application. It starts my hidden process and then closes itself. If the user attempts to re-run it, my hidden process would be notified and I could react. It means I need two executables installed on their PC, which is what I didn't want to do, but it seems like it might be the easiest approach?

 

3). Some sort of Win32 registration of events, and whatnot that I have yet to even think through, nor know anything about what happens when a process that doesn't allow multiple instances is re-run while still open.

 

Anyone have any thoughts?

0 Kudos
Message 1 of 8
(3,230 Views)
Solution
Accepted by topic author mspringer

Another option would be to use TCP based messages. This will cross application boundaries and will allow a second start of the application to notify the first that it has been started. After notification it will shutdown and pass control to the running process. If it cannot connect to the process that would be that this is the first instance to run and it can assume control. You are already talking about interprocess communications so this is just an extension of that that uses TCP rather than internal objects only. Attached is a network queue implementation that we use.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 2 of 8
(3,214 Views)

@mspringer wrote:

I have a program that will need manage some shared resources (files, com ports, other connected devices), and respond to a variety of inputs (interprocess communications in a few forms, plus possible user input). Some of these various inputs can influence others (for example, an interprocess command may be to shut down the user interface...temporarily).


That's a pretty nice explanation of operating system 🙂 Are you sure you're not overdoing something here?

 

 

0 Kudos
Message 3 of 8
(3,203 Views)

You seems to have a medium size project there, but not the knowledge to do it. You have so many question, that I can only suggest you to hire someone that have the know how, or be prepare to spend many month to complete that. The knowledge ramp up is quite long for the thing you mention. I did all that already it's why I'm saying that. but I cannot share my project and give you that all for free... where will be the fun...

One advice I can tell you, is that; since you want to create a software that has nothing to do with instrument and that you might need .net extensively, since that LabVIEW has only partial implementation of .net, I strongly suggest you to choose .net as a development platform and not LabVIEW.

 

Benoit

0 Kudos
Message 4 of 8
(3,190 Views)

Mark,

 

Thanks for the advice. This was actually somewhat along the general lines I was thinking, although hadn't specifically considered what messaging modality I would use. TCP would indeed be pretty easy, and we're already using it for other inputs. In general then you would enable multiple instances of the executable, and then when it's spawned it does the TCP check and either shuts down or becomes the main process? It's not the beautiful, elegant solution that I was hoping for, one which would have me shouting out to everyone in the room to come look (and getting weird looks), but it seems that it gets the job done. I like it though, and given no other feedback it's likely what I'll end up implementing. Thanks!

 

(Not to discredit your feedback, maybe the beauty is there and I'm just not seeing it! I was really hoping there was an event I simply didn't understand that could be used, or a callback that could be registered to simply be notified if this happened.)

0 Kudos
Message 5 of 8
(3,169 Views)

Ha! No, no no, I'm just stuck with a variety of different machine interfaces, plus some API-based entrances, so really it's just an attempt to herd kittens and coordinate. Right now I'm simply fixated on feeling like if the user clicks the exe, they are looking for a response, so I want to deal with that elegantly and let them know why their user interface isn't available, or alternatively let them break into what is happening.

0 Kudos
Message 6 of 8
(3,166 Views)

Benoit,

 

Thank you for your thoughts, although what I'm sharing here is only a small subset of the project. The primary component is actually dealing with many machine interfaces, so it made a lot of sense to select Labview as a development environment. Really here I'm fixated on a tiny portion of the entire project, trying to see if there's an elegant way to detect an attempt to start multiple instances of the exe. Even that aside though, I would disagree that you can immediately jump to saying that .net would be a better development platform, as a lot of the platform depends on your people. We're a bunch of mechanical engineers, and the fact that we can get any of us to even look at "code" in Labview is pretty impressive in itself. I admit, there are certainly places where I wanted to pull my hair out (particularly creating very nice looking GUIs that didn't immediate scream "LABVIEW", and some places where I really wanted to force in-placeness for performances reasons, buried through various levels of sub-vis), but the fact that we (mechanical engineers) could create something that uses fairly complex software paradigms is still pretty cool to me. 

 

I'm certainly not saying Labview is the best development environment either, but I'm very often finding myself surprised on what you can actually do with it.

 

At the question at hand though, I'm curious, since you seem to be a .net developer - how do you handle this in that language? Specifically the question of "I want to know if another instance of my exe was launched." Would you use WindowsFormsApplicationBase? I was wondering if there's functionality like that within Labview.

0 Kudos
Message 7 of 8
(3,164 Views)

I would not say that LabVIEW is not up to the task nor that it is only useful when interfacing with hardware. I have spent the last 20+ years developing very large applications and rarely every interface with traditional test hardware. LabVIEW, more precisely G, is a programming language. If you know and follow good software design principals you can develop virtually anything using LabVIEW. With a little effort you can even get a GUI that looks great.

 

The application below is 100% written in LabVIEW. This application is used to test printer firmware and manages in excess of 200K test steps per printer and supports 35+ printer models.

 

ZCAT Plus.png



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 8 of 8
(3,156 Views)