Why wincmd .ini ''firstmnu''-item change everytime?
Moderators: white, Hacker, petermad, Stefan2
-
- Junior Member
- Posts: 4
- Joined: 2009-11-27, 08:19 UTC
Why wincmd .ini ''firstmnu''-item change everytime?
Hi, I use dropbox to sync my TC from office to home. But the wincmd change everytime even I disable most of the history funtions.
Finally, I found there is only one line CHANGE EVERY time!
------
firstmnu=2180
------
When I disable it by add "#" before it, the software simply creats a new line fistmnu.
What is firstmnu about? And how can I set it statistic or disable it?
Thanks a lot :)
Finally, I found there is only one line CHANGE EVERY time!
------
firstmnu=2180
------
When I disable it by add "#" before it, the software simply creats a new line fistmnu.
What is firstmnu about? And how can I set it statistic or disable it?
Thanks a lot :)
Hi, francismeng.
The T.C. helpfile does not explain what the parameter firstmnu is used for. Yet, the name suggests that it might simply store some information about the first menu item which has been used since T.C. started.
Anyway, it seems to be for T.C. internal purposes only. So your chances of setting it to a fixed value or disabling it are pretty low.
Kind regards,
Karl
The T.C. helpfile does not explain what the parameter firstmnu is used for. Yet, the name suggests that it might simply store some information about the first menu item which has been used since T.C. started.
Anyway, it seems to be for T.C. internal purposes only. So your chances of setting it to a fixed value or disabling it are pretty low.
Kind regards,
Karl
- ghisler(Author)
- Site Admin
- Posts: 48232
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
firstmnu is mainly used to check whether the ini is writable, so you can set it to a fixed value.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
-
- Junior Member
- Posts: 4
- Joined: 2009-11-27, 08:19 UTC
I am afraid it changes every time!
I opened TC, and the value is:
---
firstmnu=3002
---
Then I closed it, and opened it again. It changed to anather vales!
---
firstmnu=2088
---
Every time it change! Opps!
BTW: It's my honor to talk with you ghisler :) TC is so great. Althrough I am pretty noob on it, I allready get a lot of assistance by it!
---
firstmnu=3002
---
Then I closed it, and opened it again. It changed to anather vales!
---
firstmnu=2088
---
Every time it change! Opps!
BTW: It's my honor to talk with you ghisler :) TC is so great. Althrough I am pretty noob on it, I allready get a lot of assistance by it!
- ghisler(Author)
- Site Admin
- Posts: 48232
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Windows only writes to ini files when the value is DIFFERENT from what is already there. So to test the writability, a different value has to be written each time.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Maybe it is simpler just to try to write in the beginning of INI '[' character? So if Windows let to open file for writing and WriteFile returns true, file is writeable. Since first character of INI file is always '[', you won't need to restore first byte after checking (also you may read first character from file, return pointer to beginning of file and to write character back). Function code (I have no Delphi here but I think it should work fine):ghisler(Author) wrote:Windows only writes to ini files when the value is DIFFERENT from what is already there. So to test the writability, a different value has to be written each time.
Code: Select all
function IsWincmdiniWriteable: Boolean;
var
f: HANDLE;
bytes_written: DWORD;
test_string: ShortString;
begin
f := CreateFile(PChar(Wincmdini), GENERIC_WRITE, 0, nil, OPEN_EXISTING, nil);
if (f <> INVALID_HANDLE_VALUE) then begin
try
test_string := '[';
Result := WriteFile(f, PChar(test_string), 1, @bytes_written, nil) and (bytes_written = 1);
finally
CloseHandle(f);
end;
end
else Result := False;
end;
-
- Junior Member
- Posts: 4
- Joined: 2009-11-27, 08:19 UTC
Thanks!
I get it!
But still I the ini files change every time.
I use a 3 PC(Work、Home and a Netbook). For the convinence, I put TC in my dropbox folder. So if I change something in one computer , for example add a short link, it will automatic change on the others.
But for everytime firstmnu changes, everytime the ini is different. There for the ini files have a confilct (2 PC changes the same file,which is correct?), the dropbox copy a ini and name it ---confilcted files---.
So I have a lot ini file in the folder. That is bad :(
Can the test on writable of ini files be set to try the random (1-1000), then it write back the same numbers(for example 1001) back?
There for TC can do the check and don't change the file.:)
But still I the ini files change every time.
I use a 3 PC(Work、Home and a Netbook). For the convinence, I put TC in my dropbox folder. So if I change something in one computer , for example add a short link, it will automatic change on the others.
But for everytime firstmnu changes, everytime the ini is different. There for the ini files have a confilct (2 PC changes the same file,which is correct?), the dropbox copy a ini and name it ---confilcted files---.
So I have a lot ini file in the folder. That is bad :(
Can the test on writable of ini files be set to try the random (1-1000), then it write back the same numbers(for example 1001) back?
There for TC can do the check and don't change the file.:)
- Balderstrom
- Power Member
- Posts: 2148
- Joined: 2005-10-11, 10:10 UTC
I'm curious why TC needs to write to the wincmd.ini file to determine if the file is "writable"?
Under what circumstance would it not be writable that couldn't be determined by normal methods:
* Is the file read only?
* Do you have permission to the path?
...etc...
I can't think of any other application that utilizes an .ini file that constantly writes an otherwise unused string to the file for the sole purpose of determining whether the program is allowed to write to it's own configuration file.
Under what circumstance would it not be writable that couldn't be determined by normal methods:
* Is the file read only?
* Do you have permission to the path?
...etc...
I can't think of any other application that utilizes an .ini file that constantly writes an otherwise unused string to the file for the sole purpose of determining whether the program is allowed to write to it's own configuration file.
- sqa_wizard
- Power Member
- Posts: 3869
- Joined: 2003-02-06, 11:41 UTC
- Location: Germany
-
- Junior Member
- Posts: 4
- Joined: 2009-11-27, 08:19 UTC
only fisrmun is different :)
I disable history functions on ini files (add # before [----]).
After compare 2 ini files by TC (Cool!), I found only the firstmnu is different.
It is the last step to make a in file once for ever.
After compare 2 ini files by TC (Cool!), I found only the firstmnu is different.
It is the last step to make a in file once for ever.
2sEXEcutor
As I see, it's not a bug but the feature (needed to determine write-ability to wincmd.ini).
As I see, it's not a bug but the feature (needed to determine write-ability to wincmd.ini).
Ukrainian Total Commander Translator. Feedback and discuss.
-
- Junior Member
- Posts: 12
- Joined: 2011-10-28, 18:51 UTC
Absurd
Why do you need to "test" if it is writable if you don't have anything to write?
It creates quite a bit of spam for me, and I don't even use Dropbox.
Is there a way to only write config changes if there are actually changes <snark>(a novel idea, I know!)</snark>. One would have expected that when all config options to save are disabled, it would not actually do a write to my disk... tsk tsk.
It creates quite a bit of spam for me, and I don't even use Dropbox.
Is there a way to only write config changes if there are actually changes <snark>(a novel idea, I know!)</snark>. One would have expected that when all config options to save are disabled, it would not actually do a write to my disk... tsk tsk.