I have a second DOpus installation on the PC at work.
We use roaming profiles there.
Each time after I restart the PC, on the first startup of DOpus, the dialog asking for startup options ("Directory Opus Start Window") opens and asks what DOpus should do on startup.
I always select "New Lister", to open a new lister on startup, and check the checkbox labeled "Don't show start window again".
And each time after a powercycle (haven't checked for new log on), it asks again.
It seems the startup setting(s?) is/are stored in the file "%USERPROFILE%\AppData\Local\GPSoftware\Directory Opus\State Data\confirm.osd".
Is there any way to get this stored in "%APPDATA%\GPSoftware\Directory Opus\State Data\confirm.osd" instead (since %APPDATA% points to the folder with my ROAMING profile instead of the LOCAL which will be deleted on log in)?
It's not normal for the local user profile to be wiped on every reboot. Doesn't that cause lots of problems with other things as well?
AFAIK only one other application (RadioSure) has a problem with (important) settings being stored and then deleted there.
Deleting %USERPROFILE%\AppData\Local is standard practice here and with our customers.
My co-workers do IT support, so they probably know what they are doing (I'm "only" a developer).
Hmm, seems strange/problematic, but I guess it's outside of your control.
With confirm.osd deleted, the Start Window will only be shown if Opus is run in a way which does not cause it to open a lister, so a way to prevent it from appearing would be to turn on Preferences / Launching Opus / Startup / Open the Default Lister so that a lister opens when Opus starts.
You'll probably want to also turn off Launch Directory Opus automatically on system startup in the same place, if it's on, so that you don't get a default lister appearing as soon as you login.
I'd rather prefer to have it set to "Open the Listers that were open when the program was last closed".
But using only one Lister and also having "Default Lister\Update Default Lister automatically when closing a lister" checked seems to do the trick.
So thanks for the advice/prompt support.
But it would be nice if the devs could have another look at which settings should be stored in Local and which should be stored in Roaming.
So - I've see where the locally cached copy of the profile gets wiped... but have normally seen the roaming profile get synced and updated with the most recent local changes upon shutdown (before the local cached copy is wiped).
As Leo mentioned - deleting and not updating the roaming profile should cause havoc with other apps that rely on user paths for state information, but it sounds like your IT group plans on only supporting apps that don't store necessary info in the local settings folder. I wonder what would happen if you provided your IT group with a copy of your /dopuslocaldata folders and files and asked them to copy that into your roaming profile folder so that it gets pushed down to the computer on logon. That should happen before Opus needs them... but of course any subsequent changes you make to your Opus configuration that gets stored in those folders will only survive the current logon session. But I imagine you could get a 'golden' copy stuffed into the roaming profile to prevent things like this from happening.
I don't think we're talking about part of the roaming profile. AppData\Local doesn't roam, it's local to the machine.
Hmm, maybe you're right - but the GPO to delete the local cached copy of the roaming profile deletes the whole profile folder and AppData\Local is just a sub-folder of it. If a plain folder with that same path can't get pushed down along with the roaming profile - maybe a logon script can copy a set of golden config files into place before Opus loads. Or - you guys can just consider an option to stick that stuff all under ProgramData or someplace else for shared config installs ...
If sufficient access to a USB drive isn't blocked by some other company GPO, then maybe using the Opus USB or USB dongle dongle feature is a cleaner way around the issue for now?
True, something like that might be possible, depending on the environment.
USB dongle mode should work, yeah, as long as the USB drives allow reading. (The program + config don't need to live on the USB drive with the "USB key as dongle" mode Steje suggests.)