View Issue Details

IDProjectCategoryView StatusLast Update
0002044Ham Radio DeluxeBugpublic2019-11-08 02:32
ReporterPD9FERAssigned ToWA9PIE 
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.7.0.244 
Summary0002044: Auto closing all programs not working
DescriptionWhen in rig control have selected to close some, or all programs on exit, it won't do that.
Steps To ReproduceOpen HRD Rig control
Open Radio config (Connect)
Select Auto close programs

Restart HRD
Open up Logbook, DM780 or whatever program from the suite.

Exit Rig Control.
Additional Information
TagsNo tags attached.
Testing Beta Successful



2017-06-21 12:33

developer   ~0003234

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.

#ifndef _DEBUG


2017-06-28 10:12

viewer   ~0003366

If Autoexit cannot ever work can the option be removed please?
I use Closeall to shut down the HRD suite.


2017-06-28 10:25

developer   ~0003387

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.


2018-09-11 02:12

viewer   ~0006197

Customers keep complaining (Ticket 917747)
Please see what can be done.


2019-03-05 23:56

administrator   ~0007583

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".


2019-03-06 08:47

developer   ~0007584

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.


2019-03-06 22:30

administrator   ~0007613

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.


2019-03-07 14:52

viewer   ~0007634

some clicks on the X will also do the job....
we are spoiled these day's with automation


2019-09-24 19:16

developer   ~0008637

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.


2019-09-25 14:28

administrator   ~0008669

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.


2019-10-04 07:45

developer   ~0008740

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:


2019-10-23 03:28

viewer   ~0008911

I do not see the auto-exit option. Fixed


2019-10-23 04:29

administrator   ~0008945

This was a dumb "feature" from the start. It's good to be rid of it.

Issue History

Date Modified Username Field Change
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 =>
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 =>
2019-11-08 02:32 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe