If users press Cancel, the app should not shut down.
But back to your problem, have you tried to record the parameters to a pref file, say stored in storage directory?
Every time when the app get launched and doesn't receive a port, it can use the one in pref file written in last launch by command line.
When Runtime Update dialog comes up, it should ask users to quit all the running AIR applications before it updates.
I don't see how the app. get shut down and launched automatically. It should be done by users.
When the Adobe runtime update launches, it terminates the app that was just launched -- task manager confirms this. This happens as soon as the runtime update dialog appears, before the user even can make a choice whether to update or cancel. This appears to be part of the runtime update process and is totally out of the hands of my application. (Note: the runtime update mechanism is different than the application update mechanism)
We thought about using the disk as a transfer mechanism, but the problem is that the parameters can vary from session to session. We could probably preserve the last known good locale this way, which would at least let us throw up a localized error message, but the port number varies with every launch (depending on how many instances of our C++ app are running), so we'd still have a non-workign application and the user would have to relaunch.
Right now, we're investigating the idea of launching an "update pre-check" application to "consume" the runtime update check, and then launch our real application behind it. That way the update check won't get in the way of our real application launch. How robust this solution would be, I dunno, but it's the best we've come up with so far.
This is not the correct behavior. Runtime Update should ask users to quit all running AIR apps first before it updates the Runtime.
Could you file a bug at
We have not seen this behavior. I think you have filed a bug asking the Runtime Update remember the parameters. But this is not how the Runtime Update works. It should not shut down your app. automatically. If you can include the situation this behavior can be duplicated, that would be a great help.
When you say "vary from session to session", I assume you mean each launch is a session. If that is the case, couldn't your app check the EvokeEvent at launch, if there is a port number, write it to a file and continue. If there is no port number, read the port number from the record file?
This would be the same behavior as Runtime remembering the parameters during relaunch.
I filed a bug report last night using that same form.
The duplication steps are straightforward. I can duplicate the following with 100% success on a freshly imaged Win 7 32-bit box, admin user account:
1) Install older version of Adobe AIR framework (I tried both 1.1 and 1.5.1). It will ask you to update. Click "Update later".
2) Pull up task manager and watch the process list
3) Run ANY Adobe AIR app with some parameters (I used Adobe's Settings Manager as a sample because it's small)
4) Note that your application appears in the task manager briefly
5) Your app is terminated and "Adobe Air Installer.exe" appears in the task manager. A dialog pops up asking you to update.
6) Click cancel
7) Your app is reinvoked without any parameters
As for my specific case, by "session" I do mean a single launch.
I'm not aware of an evoke event -- perhaps you meant invoke event? The invoke event is not executing before the app terminates (in step 5 above). I think the AIR app is just running long enough to load the runtime and then the runtime takes over from there.