Posted by Jhon in SWF Studio V3 on Mar 18 2011, 12:42 am

Hello,

I have SWF Studio 3.8 Build 333. The project I am working on, consist of several .exe's project made in SWF Studio (the same version). As they all use the OnQuit event. I see the, problem explained bellow, often.

The code is as follows:

ssCore.App.setNotify({event:"onQuit"},{callback:onQuit});
function onQuit(ret_obj, cb_obj, err_obj)
{
   if (ret_obj.success) {

      // if window is set to be floating, save window position
      if (_level0.floatPanel == true) { // problem occurs even if this is false
         var return_obj = ssCore.Win.getPosition();
         ssCore.INIFile.setVal({path:path, section:"Win", key:"x", value:return_obj.x});
         ssCore.INIFile.setVal({path:path, section:"Win", key:"y", value:return_obj.y});
      }
      ssCore.App.forceQuit();
   }
}


Pretty simple, as you can see. All exe's with that OnQuit event, has some ssCore code in it. Some gets executed all the time (like sending a message to another exe before closing), the others, like above, only under a condition (note that the problem also occurs when their is no ssCore command to execute).

While the code works PERFECTLY. Sometimes, on rare occasions, ssCore.App.forceQuit() is "partially executed". What I mean is that the program closes, but it is still visible in the task manager (under Processes tab, not Applications).

Note: The executable without OnQuit event shows 0 problem.

To make things more interesting, if I have the options in SWF Studio to only have 1 instance. Then another instance will not open. If I allow another instance, and the above event happen then the second executable has a sever performance degradation when execute ssCore commands. If I just run 2 instances of the program normally.. like where I actually WANT to have 2. They are no performance hit of any kind. It's only when one is "partially closed", and the other is open normally.

Also, if I use:

ssCore.App.setNotify({event:"onExitWindows"},{callback:onExitWindows});
function onExitWindows(ret_obj, cb_obj, err_obj)
{
   ssCore.App.forceExitWindows({method:ret_obj.result});
   ssCore.App.forceQuit();
}

Which I do, else Windows kills the program, and doesn't clean it's temp folder. It takes to much time to quit. While it feels fast, it is slow enough to have Windows 7 show "Waiting for application", and I see my project executable listed for about 1 sec. As my project consists of running all the time in the background of the user computer, this is annoying.

Computer 1 specs:
> Intel Core i7 930 2.8GHz
> Gigabyte GA-X58A-UD5 Rev2 motherboard
> 6GB of RAM 1600MHz DDR3 Timings of 7-8-7-24 1.5V - G.Skill Pi series (triple-channel)
> Nvidia Geforce GTX 260
> 1TB Western Digital Caviar Black
> Corsair AX750 PSU - 750W
> Windows 7 64-bit SP1 (also occurred before SP1)
> Creative X-Fi XtreamMusic sound card

Computer 2 specs:
> Dell Latitude E6400
> Core 2 Duo P8400 2.2 GHz
> 4GB of RAM 800MHz DDR2 (dual-channel)
> Windows 7 64-bit SP1 (also occurred before SP1)
> 160GB Hitachi HDD 5400 RPM
> Nvidia Quadro NVS 160M


Posted by northcode in SWF Studio V3 on Mar 18 2011, 02:49 am

We did some work on the shutdown code in 3.9 to make sure loaded plugins don't prevent clean shutdowns, which is what I suspect you might be running into here. In the first example, do you have the problem if you don't use plugins in yoru code? You can try manually unloading plugins and calling App.quit from a function through a call to SetTimeout to delay it a little.

In the second case it's probably never going to work like you want. You can't call forceQuit before forceExitWindows (for obvious reasons) and once you call forceExitWindows, the call to forceQuit won't get executed because forceExitWindows is synchronous. I don't think calling forceExitWindows asynchronously will help either.

The only "clean" solution I can think of is to have a separate "Windows Killer" app that restasrts Windows and call that from your app. That way you can launch the WK app and then quit your app. If the WK app does it's job 1/2 second after it starts, that should give your app time to shut down before Windows goes away and you don't see the "waiting..." message.