RagingGoblin Posted October 23, 2006 Report Share Posted October 23, 2006 As stated above I want to run an application in the background. According to NI this is possible: http://digital.ni.com/public.nsf/3efedde43...67?OpenDocument I used this technique. If anyone clicks the black x to close the program it will run in the background, but is accessible through an icon in the system tray. This works fine, but after a couple of hours the program stops completely. Can anyone tell me why this could be? Quote Link to comment
Mellroth Posted October 23, 2006 Report Share Posted October 23, 2006 ...Can anyone tell me why this could be? What happens in the other event cases? Especially the timeout case? /J Quote Link to comment
crelf Posted October 23, 2006 Report Share Posted October 23, 2006 As stated above I want to run an application in the background. According to NI this is possible: http://digital.ni.com/public.nsf/3efedde43...67?OpenDocumentI used this technique. If anyone clicks the black x to close the program it will run in the background, but is accessible through an icon in the system tray. This works fine, but after a couple of hours the program stops completely. Can anyone tell me why this could be? Are you sure the crashing is happening because of your application being in the hidden state? What happens if you don't hide it? Does it still crash after a few hours? Quote Link to comment
RagingGoblin Posted October 23, 2006 Report Share Posted October 23, 2006 The other cases are mostly not that importand. They only change the mousepointer into a hand and backward if you hover over a clickable item. Two cases handle the events if you click on the icon in the system tray. The timeout doesn't do anything either, just going on with the next loop. Crelf, yes I am pretty sure, because if I only minimize the app, it runs for days. Quote Link to comment
David Wisti Posted October 23, 2006 Report Share Posted October 23, 2006 but is accessible through an icon in the system tray. How are you sending the application to the system tray? .NET or API? I've used the InvTray toolkit to minimize to the system tray without any problems. Maybe its problem has something to do with minimizing to system tray thats causing the problem. Quote Link to comment
Michael Aivaliotis Posted October 23, 2006 Report Share Posted October 23, 2006 How are you sending the application to the system tray? .NET or API? I've used the InvTray toolkit to minimize to the system tray without any problems. Maybe its problem has something to do with minimizing to system tray thats causing the problem.I was using .NET once to do a tray icon. For some reason it was crashing. I discovered that it was an issue with an ActiveX call I was making while the app was minimized. It turns out that the issue was related to the front panel not having the focus. This only applies if you are using .NET to do the system tray icon. Quote Link to comment
RagingGoblin Posted October 24, 2006 Report Share Posted October 24, 2006 I use a toolkit from Karsten van Zwol, LabVIEW_Tray_Icon.lbb. Got it from here: http://forums.ni.com/ni/board/message?boar...essage.id=95141 This is used to create the icon. To close the frontpanel I use a property node to set the Front panel state to hidden (see above). Download File:post-4151-1161675844.llb Quote Link to comment
Yair Posted October 24, 2006 Author Report Share Posted October 24, 2006 I use a toolkit from Karsten van Zwol, LabVIEW_Tray_Icon.lbb. Got it from here: http://forums.ni.com/ni/board/message?boar...essage.id=95141 This library is useful (I've used it in the past myself), but you should note that you need to install that library in order for it to work, because the ActiveX component needs to be registered. Quote Link to comment
eaolson Posted October 24, 2006 Report Share Posted October 24, 2006 Is there much of a difference between hiding the application by setting the FP.State property to Hidden and closing the front panel by setting the FP.Open property to False? Quote Link to comment
Aristos Queue Posted October 24, 2006 Report Share Posted October 24, 2006 Is there much of a difference between hiding the application by setting the FP.State property to Hidden and closing the front panel by setting the FP.Open property to False? Yes. I strongly recommend never using the FP.Open property. It is "old style" and the FP.State was added to supplant it. Passing "false" to FP.Open is an ambiguous situation. If the window is already hidden and you pass false, did you intend for us to close the window entirely? This is just one of many ambiguous situations. The behavior in all these cases is well defined, but in all of these cases you have to figure out what decision LV R&D made. The old style still exists because of the huge number of toolkits that use it. Quote Link to comment
Ton Plomp Posted October 24, 2006 Report Share Posted October 24, 2006 Is there much of a difference between hiding the application by setting the FP.State property to Hidden and closing the front panel by setting the FP.Open property to False? If I recall correctly will closing the FP terminate the executable if it is the main VI. Ton Quote Link to comment
Yair Posted October 25, 2006 Author Report Share Posted October 25, 2006 If I recall correctly will closing the FP terminate the executable if it is the main VI.Ton Yes, you recall correctly. The RTE continuously polls to see if there are any open FPs and when there are none it terminates. Quote Link to comment
Mike Ashe Posted October 25, 2006 Report Share Posted October 25, 2006 Another good use for all this is if you have a LabVIEW application running as a Windows Service, completely invisible. Then you have another VI that starts up and minimizes itself to the System Tray and provides a monitor-interface to the LabVIEW Service Application. What is the advantage to all this you ask? Security. You can have your LabVIEW Service application run at computer startup, but setup the user login so that you have to hit Ctrl-Alt-Del to login. This lets you set up a secure LabVIEW app as a network service available just by turning the machine on, but hidden behind password security that no one has to login to before use, just flip the on switch, even remotely. :beer: Quote Link to comment
eaolson Posted October 25, 2006 Report Share Posted October 25, 2006 Yes. I strongly recommend never using the FP.Open property. It is "old style" and the FP.State was added to supplant it. Passing "false" to FP.Open is an ambiguous situation. If the window is already hidden and you pass false, did you intend for us to close the window entirely? This is just one of many ambiguous situations. The behavior in all these cases is well defined, but in all of these cases you have to figure out what decision LV R&D made. The old style still exists because of the huge number of toolkits that use it. I asked because RagingGoblin posted a link to an NI example using FP.Open, but the image he attached used FP.State. I wasn't sure if there was a specific reason for the discrepancy, or if he was just taking advantage of a version 8 feature that wasn't available when that was written. (I swear I wrote this yesterday, but it's not here today.) Quote Link to comment
RagingGoblin Posted October 26, 2006 Report Share Posted October 26, 2006 Hey Guys, I am still wondering what causes can stop a program which front panel state is set to hidden. Because every night around twelve it stops, but keeps running if the front panel is open. Guess I have to ask my system manager what is happening at night. Eaolson, yes you Quote Link to comment
Ton Plomp Posted October 26, 2006 Report Share Posted October 26, 2006 Hey Guys,I am still wondering what causes can stop a program which front panel state is set to hidden. Because every night around twelve it stops, but keeps running if the front panel is open. Guess I have to ask my system manager what is happening at night. Eaolson, What are your stop conditions (could you set a log when a FP close? happens) Ton Quote Link to comment
Wolfram Posted October 26, 2006 Report Share Posted October 26, 2006 Hey Guys,I am still wondering what causes can stop a program which front panel state is set to hidden. Because every night around twelve it stops, but keeps running if the front panel is open. Guess I have to ask my system manager what is happening at night. Eaolson, yes you Quote Link to comment
eaolson Posted October 26, 2006 Report Share Posted October 26, 2006 If I recall correctly will closing the FP terminate the executable if it is the main VI.Ton I did not realize this method of starting a background application did not work if it was compiled into an executable. Using a launcher (separate VI that opens a reference, runs the VI with Wait Until Done = F and Auto Dispose Ref = T, then closes itself) also doesn't seem to work with a compiled application. This is a bit tangential to the original topic, but is there any way to have an executable application running in the background and not visible without using the FP.State property? (I'm still trapped in the land of 7.1.1, so I don't have access to it.) Quote Link to comment
RagingGoblin Posted October 26, 2006 Report Share Posted October 26, 2006 Wolfram, would love to see your solution, but I only have 7.1. Can you send a picture? Quote Link to comment
Guillaume Lessard Posted October 26, 2006 Report Share Posted October 26, 2006 I strongly recommend never using the FP.Open property. It is "old style" and the FP.State was added to supplant it. Thank you! I'd been chasing a strange race condition that was linked to these ambiguities. Switching to FP.State solved it. Awesome! Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.