04-03-2010 07:27 AM
You might have a look into this nugget
The Application Instance Close Event is fired when you kill the App using the task manager in Windows. Might be useful if you need to perform some 'emergency clean-up' like shuting of power devices.
Felix
04-03-2010 08:13 AM
The workflow I normally use is the following:
Register for a panel close? event
In this event I discard it, and I will set the Front panel of all open VIs to hidden
I will call the Exit state
Register for a Application Instance close? event
In this event I call the Exit State
The exit State
In the exit state I deal with cleaning up the code, closing references and files
Close the running sub-vis
I exit my state machine while loop
After the while loop I will close the Main Front panel, this will close the application
Ton
04-03-2010 02:03 PM
lavalava wrote:
Just a suggestion, that close vi method isn't very reliable in version 8.x. I haven't tried version 9 yet so I dunno if NI ever fixed it. From my experience with this method, many times it freezes my application instead of exiting it.
That method is not designed to exit the application. It's purpose is to close the front panel window of the VI it's invoked on. The run-time engine has a rule which states that if there are no front panels open in the process, it terminates the process itself, so this is probably what you're seeing when the application does stop (which is not a good thing, by the way. You should use the Quit LabVIEW primitive to properly terminate an executable after you called all your cleanup code).
I'm guessing that the times when it "freezes" are times when you do have a window open (it could be hidden, so you don't actually see it) and your code keeps running because you don't stop it properly, thus making the program appear stuck.
04-03-2010 05:15 PM
Just wanna correct my last post, I was mistaken for quit labview VI. This one:
Obviously, I can't post my company project here so I'll try to replicate this problem. Not sure if I can but I'll give it a try when I get a chance. What happens was when you try to execute this VI, it occasionally pops up another windows that said something "labview is restarting..." and freezes. Taskkill was my only answer to shut everything down.
This is not really a big deal as I've already figured a concrete solution using taskkill. You just can't go wrong with it.
Also note, I don't have this problem under development mode. This happens only after I compiled the entire project into executables.
04-03-2010 05:39 PM
Post your "task kill" code example. I haven't had any trouble using the moethod discussed.
It's interesting that there are so many ways of doing this. Aside from the closing of application specific reference and processes etc, there should be only one (best) way to Close an Application Properly.
I would like to understand better the purposes of each of these "Instance" events which exist (i.e. "application instance closed?", etc...).
04-03-2010 05:58 PM - edited 04-03-2010 06:04 PM
Try "Simple" and "Force Exit"
The simple method will cause problem as your application grows, this is my problem. Not sure what everyone elses are experiencing. However, I'm pretty sure all the protocol (TCP/VISA/etc...) and references that were opened did closed. And I checked a million times before too. I doubt they're the culprit.
04-03-2010 07:02 PM
04-03-2010 07:59 PM
Thanks for posting the Forced Exit syst exec method. Good to know about.
I can't imagine any situation where the Exit LV would not work. It is however (alone) not the proper method for shutting down an application. Also, as I have found, using the Exit LV alone (without using the window close method prior) will produce glitches on the screen.
What about when the user presses the window close cross(X) in the right-hand corner? That is why you need to use the window close? event.
04-04-2010 04:12 AM
lavalava wrote:when you try to execute this VI, it occasionally pops up another windows that said something "labview is restarting..." and freezes.
I assume you mean "Resetting VI...". My impression was that this window appears if you try to abort the VI when it's in the middle of running a primitive and it doesn't manage to break out of it. Potential examples would include DLL calls which are stuck or calls to VISA where something causes it not to return. These can also happen in the IDE. In any case, this dialog is relatively rare and if you're getting it a lot you have something wrong with your app. Again, killing the task is bad form. You should have proper cleanup and exit code. If the code doesn't work for some reason, you can debug it (e.g. instead of closing the app, add a display or a log which is updated when each section of the code finishes executing. The section which doesn't post the update is the culprit).
04-04-2010 03:38 PM
tst wrote:I assume you mean "Resetting VI...". My impression was that this window appears if you try to abort the VI when it's in the middle of running a primitive and it doesn't manage to break out of it. Potential examples would include DLL calls which are stuck or calls to VISA where something causes it not to return. These can also happen in the IDE. In any case, this dialog is relatively rare and if you're getting it a lot you have something wrong with your app. Again, killing the task is bad form. You should have proper cleanup and exit code. If the code doesn't work for some reason, you can debug it (e.g. instead of closing the app, add a display or a log which is updated when each section of the code finishes executing. The section which doesn't post the update is the culprit).
Yes, it was the Resetting VI screen that comes up but the goal was to exit not to reset.
My program do not access any DLL directly by itself. Indirectly by going through the base LV program? Very possible.
I just gave you a kudo because I was thinking it might have something to do with VISA too. I work alot with GPIB in particular that almost any projects that I work involved a handful of those devices. But the thing is, all of my programs were event driven. In order to get to the exit event. LV already finished executing all the previous events. That being said, all of my VISA sessions that were opened did reached their closed session state. Therefore, I don't think it's my program. I think it has more to do with LV than anything.
I do, however, agree with you that force exit is never a good thing but I don't have any other choices really.
Are there any application engineers out there, could you please document this case and see if someone can investigate a little further why there are inherent problem with the Exit labview VI and VISA (GPIB) in general? In theory, if an end user hits exit, LV should call its own garbage collector do what it needs to do, releases all resources back to the operating system, and simply exit. It shouldn't be looping back to Resetting VI state and freezes itself no matter what.