I agree that there will always be use cases which FF might not handle correctly, even if I take great steps in supporting as many as possible of them. This is a generic problem which every useful program/tool/plugin encounters - one just can't make everybody happy.VadiMGP wrote:I just think it is a little dangerous. It is very easy to corrupt wincmd.ini or write to wincmd.ini of another TC instance. What about unicode? What about simultaneous running two instances of TC with different .ini files? What if TC will write file not using INI-file API but rather as text file?
And I don't like the idea to remove a feature just because it currently fails for "some" people. I know other people which already have great use from it. I think FF works currently well enough with "standard" installations of TC.
First I want to concentrate on the most common use cases and fix substantial bugs, over time I will support more of the "special" cases which were mentioned.
EDIT: I thought again about this issue. It could make sense for FF to have independent favs if there would be an integration into the running TC instance that would allow one to use FF favs inside of TC, e.g. hook the invocation of TC's dir menu and replace it with FF's menu (this way it is done in FavMenu 2.0). Provide functionality to import TC's dir menu items into FF's menu.VadiMGP wrote:Therefore I suggested to separate favorite list in two parts:
- TC independant favorites edited by FF
- TC-specific favorites edited by TC
And according to checked options FF will show in it's menu any part or both together.
Maybe this is what you wanted to suggest...
This is the way the Windows security model works - a process is not allowed to access the address space of another one which runs with higher privileges. But the most important WinAPI that is used for FF - SetWindowsHookEx - does excactly this: map the FF DLL into the address space of other programs to be able to provide the FF functionalities.VadiMGP wrote:Can you explain what is the reason for this?zett42 wrote:The service is necessary if you are working on a restricted user account. If you start a program with admin privileges from this account (via "run as"), the program wouldn't show the FlashFolder toolbar unless FF has been started with admin privileges too.
Acknowledged. Would you please be so kind to submit these items to the FlashFolder feature request tracker?VadiMGP wrote:Another suggestions:
1. Add path autocompletion feature to FF.
2. Introduce program-specific settings. For example, when I open file from PhotoShop I want "Open File" dialog to be resized to whole screen and turn folder view in thumbnail view.
How do you define "correct ini"? I understand the use case of running TC directly from a flash drive where another TC (not necessary yours) may be installed onto the machine. In this case you would propably like to use the favorites from wincmd.ini of flash-drive-TC.m^2 wrote:TC's plugins know which ini is correct. So writing one that communicates with FF would solve this problem.
If flash-drive-TC is currently running, I would have no problems to get the "correct" wincmd.ini from env. variable %COMMANDER_INI%, defined in the TC process since the FF-DLL is already mapped into running TC process (and other GUI processes).
If flash-drive-TC is not running but you still want to access your favorites in the open/save dialogs, a way to locate TC on your flash drive would have to be developed.
For a first implementation of this feature, it would propably be sufficient to set it as a requirement that "TC must run if you want your favorites from flash drive".
I think such condition quite typical for many plugin authors and beta-testers.
