Why wincmd .ini ''firstmnu''-item change everytime?

[francismeng]

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 :)

[karlchen]

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

[ghisler(Author)]

firstmnu is mainly used to check whether the ini is writable, so you can set it to a fixed value.

[francismeng]

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!

[ghisler(Author)]

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.

[MVV]

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.

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):

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;

[francismeng]

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.:)

[MVV]

Anyway even if TC will return previous value to this parameter file's date changes so you will need to recompare files.
You always may use compare tool to see that the only difference in files is firstmnu parameter or not.

[Balderstrom]

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.

[sqa_wizard]

why TC needs to write to the wincmd.ini file to determine if the file is "writable"?

For the sake of simple and resource saving : No additional code needed, just write and read ...

[francismeng]

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.

[sEXEcutor]

Sorry for bumping old topic but the issue still persists.

[MaxX]

2sEXEcutor
As I see, it's not a bug but the feature (needed to determine write-ability to wincmd.ini).

[sEXEcutor]

I'd call it "enhancement request"

[RandomMarius]

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.