Store settings in INI instead of registry
At school we have a very-very limited user, so we can't add new registry values and there are predefined applications which can modify the registry, so there is no such workaround that we could simply add-remove anything we want. When I said there are places where you can't change the registry's HKCU I meant physical places (like school,netcafe,etc), not registry hives. I think that in these cases a bit slower working is acceptable. So is there a chance that this feature (a command-line switch, or similar to save into file instead of the registry) will be implemented in the future, or we have to forget this forever? If a man who is a programmer in the FAR Group says that "We won't write the code for this", then there is no need to argue about this.
But those are places where the admin INTENDS to block you from using any other programs. I am pretty sure, that it is also a violation against the usage rules of such systems.When I said there are places where you can't change the registry's HKCU I meant physical places (like school,netcafe,etc), not registry hives.
You see, in those locked-down systems, even the list of EXE files that may be executed at all are most likely limited to wanted ones. Such locked-down-systems are "by design" locked .
I am however pretty sure that you can write to most HKCU keys there as well, as nearly all software (that runs there) needs write access. If those admins really locked down HKEY_CURRENT_USER\Software, so that only few wanted changes are allowed (which is a lot to do for an admin, believe me), the chances are very high, that you won't get your own EXEcutables from a USB stick or anything else to run because of EXE restrictions. (if the second is not the case you have found a hole in the security perimeter of those systems - but in that case you still should not want to abuse that out of moral reasons.)
Well, apparently nothing is going to change any time soon.
But if there were to be any changes, I would prefer a "plugin" approach to the problem - simply export the saving and loading of values to a DLL file and let the user decide whether he wants to use a registry-accessing-DLL or INI-accessing-DLL, XML-accessing-DLL or even Oracle-accessing-DLL... FAR could maybe default to registry if no "settings.dll" was wound.
But if there were to be any changes, I would prefer a "plugin" approach to the problem - simply export the saving and loading of values to a DLL file and let the user decide whether he wants to use a registry-accessing-DLL or INI-accessing-DLL, XML-accessing-DLL or even Oracle-accessing-DLL... FAR could maybe default to registry if no "settings.dll" was wound.
That I meant.t-rex wrote:Well, no simple solution is available for old plugins
To store all settings in ini files, somebody must rewrite all popular plugins - a very funny work...
Registry hook from plugin or external application is more simple, and this idea is very old, but not implemented... Seems, nobody seriously need it
Well, I would write a plugin if I had some information/a little example about registry hooking. I've started a topic at sysinternals forum about this, but there were no answer (actually there were one - the guy thought he is funny ). The other problem, I only know Delphi/Object Pascal (and a little C) which is not the best I think. About "Seems, nobody seriously need it" thats a half-truth (who needs it - can't code it, who can code it - doesn't need it)
Unless you're trying to read the file from a floppy disk the amount of time it takes to load a file containing a mere 200 lines is almost too small to even measure, so I can't imagine that would be an issue.Lofote wrote: Yes, it IS a problem.
I certainly don't want to wait for FAR just because it loads of some stupid text file.
You seem to totally underestimate what it means to load ~200 settings at startup. Maybe you should try it out before you state something like that.
I don't think there is any specific info on registry hooking, but what you need to do to create such a program is to overload every import of far.exe and plugins of registry functions with your own. And your program can not be a plugin, it has to be an exe that runs Far so you can overload that functions before Far even starts. You can check out the sources of ConMan which uses the same technic to overload (hook) some other imports.TCA wrote:Well, I would write a plugin if I had some information/a little example about registry hooking. I've started a topic at sysinternals forum about this, but there were no answer (actually there were one - the guy thought he is funny ). The other problem, I only know Delphi/Object Pascal (and a little C) which is not the best I think. About "Seems, nobody seriously need it" thats a half-truth (who needs it - can't code it, who can code it - doesn't need it)
DrKnS, HaRT: Well, my FarSave is 5000 lines. So what? It may have escaped your notice, but all these questions about INI files consider such an approach to saving and loading FAR settings as an alternative, not a replacement. Why you are so set against it to repeat two rather irrelevant arguments ("I don't need it" and "I wouldn't like the slowdown") is beyond my understanding.
Then argue that "There are more important things to do, such as ...". Not that everyone will agree with you all of a sudden, but at least it will be a valid argumentation and not irrelevant whining.
Personally, I don't need either INI files or Unicode. Should I use your approach and whine that "Unicode will slow down my system, because filenames will take up twice as much RAM as they do now" and "FAR Group members should devote their time to more useful things, such as Synchronize Directories command"? I am sure that would do a lot of good (sarcasm). Why can't we devote this thread to discussion about HOW to best implement INI-files and leave the WHEN (and IF) to Far Group themselves?
Personally, I don't need either INI files or Unicode. Should I use your approach and whine that "Unicode will slow down my system, because filenames will take up twice as much RAM as they do now" and "FAR Group members should devote their time to more useful things, such as Synchronize Directories command"? I am sure that would do a lot of good (sarcasm). Why can't we devote this thread to discussion about HOW to best implement INI-files and leave the WHEN (and IF) to Far Group themselves?