Startup setting lost after updating

Help & Support
1

In Preferences --> Launching Opus --> Startup --> Listers opened automatically when Directory Opus starts, I always set the radio button to Run a command, where the command is a user-defined command in Customise --> Commands.

Recently, on PC and laptops, this setting has been disappearing after some of the DOpus updates (for example, the update to the current V12.0.9), with the radio button set to Don't open any lister after the necessary reboot. I have to reset the button manually afterwards, and the setting then remains stable. It's an irritation rather than a problem, but I thought it worth reporting.

2

Are you seeing that after updating from 12.0.8 to 12.0.9, or from an earlier version (e.g. 11.x)?

3
  • The setting was lost from V12.0.8 to V12.0.9.
  • I'm fairly sure, but not certain, that the setting was retained from V12.0.7 to V12.0.8.
  • It has happened before, but I didn't record anything because I thought that I must have been doing something wrong.
4

Reporting further:

  • The setting was NOT lost when I updated DOpus on my wife's work computer from V12.0.5 to V12.0.9. That computer is a 64-bit Mac notebook that is still running Windows 7 Enterprise on top of some Mac platform or another.
  • The computers where the setting was lost are 64-bit PCs running Windows 10 Pro.
5

Did the machine which lost the setting, or the config backup, go back to Opus 11 at any point?

6

No, I've never gone backwards to V11 on those machines or on any other. There's no urgency --- perhaps we can leave it until the next DOpus update, and I'll report again.

7

OK. Definitely worth tracking down if it is happening.

Before installing the next update, please make a config backup so we can compare before & after versions if the setting does get lost again. That should reveal what's happening.

8

Will certainly do. That in turn brings up another point, which should perhaps be in another thread.

Yesterday and today I tried to restore backed-up DOpus configs onto other computers that I had newly updated to V12.0.9 (we've been away), but the operations failed instantly, and I have just worked out what's going on. For years I have been routinely and automatically changing each backup's file extension from .ocb to .zip so that I could see it in the preview pane (hardly a compelling reason), and restoring directly from the ZIP file was never a problem until yesterday. Once I had changed the extensions back to .ocb, however, the restorations worked perfectly. Was this change intended?

9

The change was intended, as the way backup & restore commands handled extensions passed as command-line parameters was inconsistent and confusing. (One required you to include the ".ocb" extension in the filepath. The other required you to omit it. Neither worked if you did the opposite.)

The side effect of the change that you're seeing wasn't explicitly intended, but I don't think the ability to restore a backup from a .zip extension was ever intended/supported either.

10

Thanks, leo. That clears up the mystery, with no loss whatsoever. I'll use the extension .ocb from now on.

11

Reporting the good news that there were no problems with losing the startup settings on three machines updating from V12.0.9 to V12.0.10, and then from V12.0.10 to V12.0.11. Two are a desktop and laptop each running Windows 10 Pro, and one is a notebook running Windows 7 Enterprise on top of some Apple system.