Page 1 of 1

Reread configuration

Posted: 2009-10-09, 04:48 UTC
by MVV
Sorry if this already discussed (I can't remember such topics).

We have a menu item Configuration - Save settings.
We need a menu item Configuration - Load settings.

So on Load settings TC will reread all its options from INI files as if it does it after restarting. So, we won't need to restart TC in order to apply IFI file changes.

For ages---

Posted: 2009-10-09, 04:57 UTC
by Clo
2MVV

:) Hello!

• Yes, that was proposed several times for ages (including by myself)… and not implemented.
Support +++, of course !

:mrgreen: KR
Claude
Clo

Posted: 2009-10-09, 07:18 UTC
by Balderstrom
I'm not sure why it even needs to be a manual command. Any half-decent editor can tell when a file it has open has been modified by another process and offers to reread the file from disk.

TC could automatically pop-up a notification Settings file has changed, do you wish to reload configuration?

Support+.

Posted: 2009-10-10, 13:08 UTC
by JohnFredC
Support++

Posted: 2009-10-10, 22:43 UTC
by petermad
Support ++++

Re: For ages---

Posted: 2009-10-11, 10:52 UTC
by Postkutscher
Clo wrote:• Yes, that was proposed several times for ages (including by myself)… and not implemented.
Support +++, of course !
Exactly.
Support++

Simplistic---

Posted: 2009-10-11, 22:40 UTC
by Clo
2Postkutscher

:) Hello !

• Actually, I've the simplistic following idea :
- I assume that the internal command exists (as number) for the “Apply” buttons of the config. pages,
so we need only this number and a usable common “text” command like i.e. :
cm_ReloadINIs able to do this for all INIs, or maybe several ones more specialized ?
- What do you think ?

:mrgreen: KR
Claude
Clo

Posted: 2009-10-12, 03:56 UTC
by Balderstrom
Why the insistence on a new command? When launched TC should track the TimeStamps on the .ini files (and any possible redirected .ini's). When such files change - and said change is not due to TC writing to the file... then a popup: "Configuration Files have changed, Apply Changes?\n [Apply][Cancel]"

Posted: 2009-10-12, 05:27 UTC
by MVV
Balderstrom wrote:Why the insistence on a new command? When launched TC should track the TimeStamps on the .ini files (and any possible redirected .ini's). When such files change - and said change is not due to TC writing to the file... then a popup: "Configuration Files have changed, Apply Changes?\n [Apply][Cancel]"
This requires additional thread that will constantly check INI timestamp. I do not think it is a good idea, for me just command like cm_ConfigLoadSettings is better - it doesn't require additional resources.

Posted: 2009-10-12, 06:21 UTC
by Balderstrom
Really? The only way to edit the Ini file is to open an editor to do so. Which puts TC in the background.
When TC is activated/brought to foreground it would take an insignificant amount of time to check if it's ini files have changed.

Posted: 2009-10-12, 08:43 UTC
by MVV
Balderstrom wrote:Really? The only way to edit the Ini file is to open an editor to do so. Which puts TC in the background.
When TC is activated/brought to foreground it would take an insignificant amount of time to check if it's ini files have changed.
Hmm, I didn't thought about check on WM_ACTIVATE. Maybe good idea. But I think that menu item would be enough.

Posted: 2009-10-13, 19:56 UTC
by ghisler(Author)
I tried to add such a command, but unfortunately there are far too many options which can be set, and which have effects on things like plugins, active ftp connections etc. etc., so a restart of TC cannot be avoided.

Posted: 2011-10-21, 13:33 UTC
by ask-rus
2ghisler(Author)
Maybe try again in TC 8.0?

Posted: 2011-10-21, 13:59 UTC
by JohnFredC
In many cases, "partial" implementations can add value.

If some INI options cannot be "reloaded" without a restart (due to issues internal to TC), then inform the user and proceed (if the user affirms) with the options that CAN be refreshed.

Perhaps the developer's effort to build such a "partial" mechanism outweighs the overall benefit to TC (this is probable, IMO), but that is an entirely separate issue from feasibility of implementation.