View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002044||Ham Radio Deluxe||Bug||public||2017-06-21 04:57||2019-11-08 02:32|
|Target Version||Fixed in Version||126.96.36.199|
|Summary||0002044: Auto closing all programs not working|
|Description||When in rig control have selected to close some, or all programs on exit, it won't do that.|
|Steps To Reproduce||Open HRD Rig control|
Open Radio config (Connect)
Select Auto close programs
Open up Logbook, DM780 or whatever program from the suite.
Exit Rig Control.
|Tags||No tags attached.|
The on exit features can't ever work because the "close" handler in the main frame window of the Rig control app, in non-debug builds, calls ExitProcess().
The ExitProcess() function exits the process: there is no more further processing, and that's it. "More further processing" would include things like the closing other apps (or releasing connections, or flushing files, or ...)
// Hide, then force an exit in case any threads were not closed.
If Autoexit cannot ever work can the option be removed please?
I use Closeall to shut down the HRD suite.
The code can't work as written, that's for sure. If the call to ExitProcess() is removed, then I think the feature has a chance at working. But the problem with simply removing that call is that comments around it say that the call is meant to work around threads that have hung. If there is a chance of hung threads hanging around that prevent the application from closing, that's far more annoying to customers than the automatic close feature not working.
To proceed, I'll have to look at all the threads in the Rig Control app to see if they have a chance at preventing the application's graceful exit. If they do, then that will have to be fixed before further work. If they don't, or once they're fixed, then I think we'll find that the exit apps feature is ready to go.
Customers keep complaining (Ticket 917747)
Please see what can be done.
I agree with John (G3UCQ). If this can't be done... let's eliminate the option.
If it can be done, let's get on with it. It seems like a fairly simply repro case.
Let's "fill it or kill it".
Being easy to reproduce shouldn't be confused with being easy to correctly fix.
Sounds like this issue has suddenly risen in priority; is that true? If so, we should talk about it at the Thursday meeting and stack it with the other priorities we have.
||I intended to make no inference to the ease of fixing this. But if it's an easier thing to remove, that might be a better approach.|
some clicks on the X will also do the job....
we are spoiled these day's with automation
It's not too complicated to have Rig Control ask other programs in the suite to close when Rig Control is closed. If another program is idle, it will see that request and close.
But what if the other program is not idle? That's the rub. Maybe it's doing a very short operation, like saving a file. The file is saved, then we end the program. Maybe it's doing a pretty long operation, like waiting for a broken rotator to finish turning; or performing a backup. Then what?
It's also conceivable that the other application is busy interacting with the user. Consider this scenario:
1) Start up Rig Control
2) Start up the Logbook
3) Use one of the "Configure" options in the Logbook's tools menu
4) Make some changes, but don't "Apply" them
5) Click on Rig Control
6) Close Rig Control.
Now what? Should Rig Control wait until Logbook actually closes? Or should it just ask it to close and forget about it? When Logbook is waiting for the user to save the changes they made, it's not exactly prepared to let the user exit the application. It has some half-baked changes that it should manage. Maybe it prompts the user before saving them ... or not?
I don't think we're prepared to visit every part of every UI in all applications to find spots where the application might be asked to exit, and add prompts to save dirty data or confirm the exit.
With just a bit of though, then, we reveal that a seemingly innocuous feature request is actually quite complex.
Mike B has valid points here. When this option was first introduced into the HRD software years ago, it DID work for a short period of time, then due to issues just like Mike B described were happening. For example, DM-780, Logbook, Rotator Control and Satellite tracker all save their screen size, the monitor they open on and other data on closing. Logbook does an automatic backup at closing if the data in the log has been changed during the time it was open. The process the previous programmers tried to use was much like using the Task manager to kill a process. It would close the programs and NOT all the programs to do the tasks they do when they are closed normally.
The option was thus, disabled very shortly after it was introduced and hasn't worked since.
I don't see any evidence that the feature was disabled. The code to implement it tried to work, and often did. Last summer, the mechanism the programs used to notify eachother of closing failed becuase it was incorrectly written and the bad code became incompatible with Windows 10; some applications would spuriously shut down based on implementation-level system messages rather than explicitly sent shut-down notifications from the applications themselves.
I've removed the auto-exit options from the Rig Control conect screen, the options persistence code, and each of the applications themselves. If we want to implement this feature, we can start with a clean sheet and build a design we like.
The code as checked-in with this change set:
||I do not see the auto-exit option. Fixed|
||This was a dumb "feature" from the start. It's good to be rid of it.|
|2017-06-21 04:57||PD9FER||New Issue|
|2017-06-21 12:33||K7ZCZ||Note Added: 0003234|
|2017-06-21 12:33||K7ZCZ||Assigned To||=> K7ZCZ|
|2017-06-21 12:33||K7ZCZ||Status||new => assigned|
|2017-06-21 20:42||K7ZCZ||Assigned To||K7ZCZ =>|
|2017-06-28 10:12||g3ucq||Note Added: 0003366|
|2017-06-28 10:25||K7ZCZ||Note Added: 0003387|
|2018-09-11 02:12||PD9FER||Note Added: 0006197|
|2019-03-05 23:56||WA9PIE||Note Added: 0007583|
|2019-03-06 08:47||K7ZCZ||Note Added: 0007584|
|2019-03-06 08:48||K7ZCZ||Assigned To||=> WA9PIE|
|2019-03-06 08:48||K7ZCZ||Status||assigned => feedback|
|2019-03-06 08:48||K7ZCZ||Module||All (Installer) => All|
|2019-03-06 08:48||K7ZCZ||Sub-Module||=> (select)|
|2019-03-06 22:30||WA9PIE||Note Added: 0007613|
|2019-03-07 14:52||PD9FER||Note Added: 0007634|
|2019-03-07 14:52||PD9FER||Status||feedback => assigned|
|2019-09-24 19:16||K7ZCZ||Note Added: 0008637|
|2019-09-25 14:28||KB3NPH||Note Added: 0008669|
|2019-10-04 07:45||K7ZCZ||Status||assigned => resolved|
|2019-10-04 07:45||K7ZCZ||Resolution||open => fixed|
|2019-10-04 07:45||K7ZCZ||Testing||=> Not Started|
|2019-10-04 07:45||K7ZCZ||Note Added: 0008740|
|2019-10-11 09:17||WA9PIE||Project||1 - Backlog => 3 - Current Dev List|
|2019-10-21 17:04||K7ZCZ||Fixed in Version||=> 188.8.131.52|
|2019-10-23 03:28||g3ucq||Note Added: 0008911|
|2019-10-23 04:29||WA9PIE||Status||resolved => closed|
|2019-10-23 04:29||WA9PIE||Additional Information Updated||View Revisions|
|2019-10-23 04:29||WA9PIE||Sub-Module||(select) => General|
|2019-10-23 04:29||WA9PIE||Testing||Not Started => Beta Successful|
|2019-10-23 04:29||WA9PIE||Note Added: 0008945|
|2019-11-08 02:12||WA9PIE||Fixed in Version||184.108.40.206 => 220.127.116.11|
|2019-11-08 02:32||WA9PIE||Project||3 - Current Dev List => Ham Radio Deluxe|