Compare WinCmd.ini files: tools to reformat
Moderators: Hacker, petermad, Stefan2, white
Compare WinCmd.ini files: tools to reformat
A couple of tools are available at http://users.erols.com/ffsq/wincmdini.html to help with comparing WinCmd.ini files.
The first tool sorts and reformats Wincmd.ini files so they can be compared and synchronized with a file comparison and editing program. Keyword sections are sorted, and commands are sorted within keyword sections. Comment lines are kept with the following command or keyword during sorting. Item numbers are removed from the Start menu and Directory hotlist sections, and are replaced with blank separator lines.
When you have reformatted a couple of Wincmd.ini files, you can use the file comparison and side-by-side editing software of your choice to compare and perhaps synchronize the files. See http://www.ghisler.com/tools.htm for comparison programs.
The second tool restores the Ini format by adding Start menu and Directory hotlist item numbers and removing the blank separator lines, so that the synchronized WinCmd.ini files again can be used by Total Commander.
If you see any flaws, please let me know. Thanks
The first tool sorts and reformats Wincmd.ini files so they can be compared and synchronized with a file comparison and editing program. Keyword sections are sorted, and commands are sorted within keyword sections. Comment lines are kept with the following command or keyword during sorting. Item numbers are removed from the Start menu and Directory hotlist sections, and are replaced with blank separator lines.
When you have reformatted a couple of Wincmd.ini files, you can use the file comparison and side-by-side editing software of your choice to compare and perhaps synchronize the files. See http://www.ghisler.com/tools.htm for comparison programs.
The second tool restores the Ini format by adding Start menu and Directory hotlist item numbers and removing the blank separator lines, so that the synchronized WinCmd.ini files again can be used by Total Commander.
If you see any flaws, please let me know. Thanks
Last edited by Ralph on 2005-08-01, 12:50 UTC, edited 1 time in total.
The re-formatting tools for Wincmd.ini files now are written in Visual Basic, allowing a better user interface. The programs have additional error-checking and relaxed size limits. For keeping track of the several files that are part of the synchronizing process, I have settled upon an easy approach, which I offer as a suggestion.
These tools may be made available to the full set of Total Commander users through a link on the TC Addons/Tools page, unless you experienced folks spot problems. I have done testing on a number of files, but the majority of them are variations on my own Wincmd.ini files. Also, I don't use button bars, so my test .BAR file may not show the full range of syntax. Any feedback would be helpful
These tools may be made available to the full set of Total Commander users through a link on the TC Addons/Tools page, unless you experienced folks spot problems. I have done testing on a number of files, but the majority of them are variations on my own Wincmd.ini files. Also, I don't use button bars, so my test .BAR file may not show the full range of syntax. Any feedback would be helpful
Last edited by Ralph on 2005-08-01, 12:52 UTC, edited 1 time in total.
Strange error message when opening wincmd.ini:
There already is a nice lister plugin with which you can sort INI files, not sure if your tool is better suited:
http://www.totalcmd.net/plugring/inied.html
Icfu
What's the sense ofThe Input file that you specified,
E:\Download\wincmd_ini_numsep\wincmd.ini,
exists but does not have a carriage return within the first 2000 characters (not counting hexidecimal[00] characters).
?Item numbers are removed from the Start menu and Directory hotlist sections, and are replaced with blank separator lines.
There already is a nice lister plugin with which you can sort INI files, not sure if your tool is better suited:
http://www.totalcmd.net/plugring/inied.html
Icfu
This account is for sale
Icfu:
"Strange error message when opening wincmd.ini:
Quote:
The Input file that you specified,
E:\Download\wincmd_ini_numsep\wincmd.ini,
exists but does not have a carriage return within the first 2000 characters (not counting hexidecimal[00] characters)."
The Visual Basic program normally reads the Wincmd.ini file with a Line Input command, which looks for a carriage return character (hexidecimal 0D) to indicate the end of each line. If the user accidentally specified a huge file in which each line ended with line feeds (hexidecimal 0A) and not carriage returns, the Line Input # command would try to read the whole file into the first array element, and the program would appear to lock up for a while. Therefore, the program does a preliminary examination of each of the first 2000 characters, to make sure that a carriage return character appears.
If your Wincmd.ini file normally does not contain carriage returns, then I might be able to rewrite the program to do only binary reads. Would you be willing to check your wincmd.ini file in Lister with the Hex display, and let me know which character(s) are at the end of each line? Alternatively, would it be possible for you post somewhere an example file, zipped so that nothing is translated? Maybe the end-of-line character(s) depend on an "International" setting.?
__________
"What's the sense of
Quote:
Item numbers are removed from the Start menu and Directory hotlist sections, and are replaced with blank separator lines."
Item numbers in the Start menu ([user]) and Directory hotlist ([DirMenu]) sections distinguish between the different menu items. These numbers get in the way of file comparisons, because TC automatically changes the numbers in the rest of the section whenever the user adds, removes, or moves an item. Therefore, we want to temporarily take out the item numbers. However, without the numbers, it is not obvious which lines go with which items, since the alphabetic part of the command to the left of the equals sign is not unique (and in fact may re-appear in every menu item). Without the numbers, we need a placeholder to indicate that one item has ended, and another is beginning. Blank lines are used as placeholders, since they add little visual clutter during file comparison and synchronizing.
__________
"There already is a nice lister plugin with which you can sort INI files, not sure if your tool is better suited:
http://www.totalcmd.net/plugring/inied.html"
I just took a quick look at that plugin, and it is nice, with a convenient interface. The tools that I have offered are intended to serve a different and specialized need. The tools keep comments and blank lines with the following command or keyword during sorting. The tools remove menu item numbers, which would interfere with comparison. The tools run in a fraction of a second, without user effort beyond selecting files the first time or if different files are to be used.
Actually, the tools skip sorting in the menu sections, avoiding the problem of grouping by command and not by item, and avoiding the issue of sorting left-justified menu item numbers. A file comparison and side-by-side editing package such as Compare It! lets me work around the problem of moved menu items; I can see where the matching items are located, and move one or the other by hand.
Thanks for having a look. I hope that I am not being too verbose.
"Strange error message when opening wincmd.ini:
Quote:
The Input file that you specified,
E:\Download\wincmd_ini_numsep\wincmd.ini,
exists but does not have a carriage return within the first 2000 characters (not counting hexidecimal[00] characters)."
The Visual Basic program normally reads the Wincmd.ini file with a Line Input command, which looks for a carriage return character (hexidecimal 0D) to indicate the end of each line. If the user accidentally specified a huge file in which each line ended with line feeds (hexidecimal 0A) and not carriage returns, the Line Input # command would try to read the whole file into the first array element, and the program would appear to lock up for a while. Therefore, the program does a preliminary examination of each of the first 2000 characters, to make sure that a carriage return character appears.
If your Wincmd.ini file normally does not contain carriage returns, then I might be able to rewrite the program to do only binary reads. Would you be willing to check your wincmd.ini file in Lister with the Hex display, and let me know which character(s) are at the end of each line? Alternatively, would it be possible for you post somewhere an example file, zipped so that nothing is translated? Maybe the end-of-line character(s) depend on an "International" setting.?
__________
"What's the sense of
Quote:
Item numbers are removed from the Start menu and Directory hotlist sections, and are replaced with blank separator lines."
Item numbers in the Start menu ([user]) and Directory hotlist ([DirMenu]) sections distinguish between the different menu items. These numbers get in the way of file comparisons, because TC automatically changes the numbers in the rest of the section whenever the user adds, removes, or moves an item. Therefore, we want to temporarily take out the item numbers. However, without the numbers, it is not obvious which lines go with which items, since the alphabetic part of the command to the left of the equals sign is not unique (and in fact may re-appear in every menu item). Without the numbers, we need a placeholder to indicate that one item has ended, and another is beginning. Blank lines are used as placeholders, since they add little visual clutter during file comparison and synchronizing.
__________
"There already is a nice lister plugin with which you can sort INI files, not sure if your tool is better suited:
http://www.totalcmd.net/plugring/inied.html"
I just took a quick look at that plugin, and it is nice, with a convenient interface. The tools that I have offered are intended to serve a different and specialized need. The tools keep comments and blank lines with the following command or keyword during sorting. The tools remove menu item numbers, which would interfere with comparison. The tools run in a fraction of a second, without user effort beyond selecting files the first time or if different files are to be used.
Actually, the tools skip sorting in the menu sections, avoiding the problem of grouping by command and not by item, and avoiding the issue of sorting left-justified menu item numbers. A file comparison and side-by-side editing package such as Compare It! lets me work around the problem of moved menu items; I can see where the matching items are located, and move one or the other by hand.
Thanks for having a look. I hope that I am not being too verbose.
I was wondering about the error message because I thought that my wincmd.ini has normal DOS format but it had UNIX format, you are right. No idea when this was changed here, maybe I switched it in metapad or another editor by accident. 
Two bugs:
1. Sorting problems, for example _ comes after z although it should appear before a.
2. Restore INI format option has corrupted the [user] section, now I have entries cmd1-cmd25, menu26-menu52 and param53-param64. It has corrupted the [Dir Menu] section, too, cmd1-35 and menu36-menu76.
I think your item numbering feature needs an update...
Icfu

Two bugs:
1. Sorting problems, for example _ comes after z although it should appear before a.
2. Restore INI format option has corrupted the [user] section, now I have entries cmd1-cmd25, menu26-menu52 and param53-param64. It has corrupted the [Dir Menu] section, too, cmd1-35 and menu36-menu76.
I think your item numbering feature needs an update...
Icfu
This account is for sale
(Edited)
Icfu:
"...
2. Restore INI format option has corrupted the [user] section, now I have entries cmd1-cmd25, menu26-menu52 and param53-param64. I think your item numbering feature needs an update..."
Could you provide a portion of the input [user] section (or post the whole input file somewhere)? Is it possible that you did a sort within the [user] section? If not, then the first tool must have sorted in the [user] section, which it is not supposed to do...
Thanks
Icfu:
"...
2. Restore INI format option has corrupted the [user] section, now I have entries cmd1-cmd25, menu26-menu52 and param53-param64. I think your item numbering feature needs an update..."
Could you provide a portion of the input [user] section (or post the whole input file somewhere)? Is it possible that you did a sort within the [user] section? If not, then the first tool must have sorted in the [user] section, which it is not supposed to do...
Thanks
Last edited by Ralph on 2005-08-01, 12:54 UTC, edited 1 time in total.
I regularly sort the INI with the above mentioned plugin so all sections are sorted alphabetically! This is completely ok in INI files because the entries don't depend on their position.Is it possible that you did a sort within the [user] section?
You mustn't expect that the section looks exactly like TC writes it originally but you have to check which entries belong together if you do heavy modifications like removal of item numbering.
Icfu
This account is for sale
(Edited)
Icfu:
"I regularly sort the INI with the above mentioned plugin so all sections are sorted alphabetically! This is completely ok in INI files because the entries don't depend on their position.
You mustn't expect that the section looks exactly like TC writes it originally but you have to check which entries belong together if you do heavy modifications like removal of item numbering"
OK, that explains what happened.
I need to think some more about the issue of sorted menus. One solution would be to have the first tool re-group the commands by item number. To me, that sounds convenient, since whole items probably would be added, removed, or moved between files during synchronizing. Does automatic re-grouping by item number sound as though it could be useful?
In addition, the first tool could leave a comment in the menu if any menu item numbers were out of order, in which case the second tool could sort the menu. This could result in sorting when just one command was out of order. Alternatively, if users would handle any re-sorting later, then no comment and no sorting by the second tool would be needed. I am leaning against sorting by the second tool. Comments?
(It is way past my bedtime, so I will sign off for now.)
Thanks
Icfu:
"I regularly sort the INI with the above mentioned plugin so all sections are sorted alphabetically! This is completely ok in INI files because the entries don't depend on their position.
You mustn't expect that the section looks exactly like TC writes it originally but you have to check which entries belong together if you do heavy modifications like removal of item numbering"
OK, that explains what happened.
I need to think some more about the issue of sorted menus. One solution would be to have the first tool re-group the commands by item number. To me, that sounds convenient, since whole items probably would be added, removed, or moved between files during synchronizing. Does automatic re-grouping by item number sound as though it could be useful?
In addition, the first tool could leave a comment in the menu if any menu item numbers were out of order, in which case the second tool could sort the menu. This could result in sorting when just one command was out of order. Alternatively, if users would handle any re-sorting later, then no comment and no sorting by the second tool would be needed. I am leaning against sorting by the second tool. Comments?
(It is way past my bedtime, so I will sign off for now.)
Thanks
Well, it is not only useful but definetely needed I think.Does automatic re-grouping by item number sound as though it could be useful?
All I am interested in is that the original menu structure stays intact and the entries don't change position. Renumbering is a nice feature to clean up the wincmd.ini but only if it works flawlessly. Comments and the like are not needed imho.In addition, the first tool could leave a comment in the menu if any menu item numbers were out of order, in which case the second tool could sort the menu. This could result in sorting when just one command was out of order. Alternatively, if users would handle any re-sorting later, then no comment and no sorting by the second tool would be needed. I am leaning against sorting by the second tool. Comments?
(It is way past my bedtime, so I will sign off for now.)
Icfu
This account is for sale
Icfu:
"Quote:
'Does automatic re-grouping by item number sound as though it could be useful?'
Well, it is not only useful but definetely needed I think."
OK, I will do it.
"All I am interested in is that the original menu structure stays intact and the entries don't change position. Renumbering is a nice feature to clean up the wincmd.ini but only if it works flawlessly. Comments and the like are not needed imho. "
Working flawlessly certainly is the goal. If the user adds, removes, or moves menu items when synchronizing, then the second tool's automatic updating of the following menu item numbers (while retaining the item order determined by the user) can save time.
The tools parallel TC's handling of comments and blank lines. TC does not retain them in the menu sections when it saves Wincmd.ini files, so the tools also do not support comments and extra blank lines in the menu sections. In the non-menu sections, TC retains comments and blank lines, so the tools do also. Sometimes it helps visually to have a blank line above a section. Above the [Colors] section, I have a comment to myself about how to calculate the color number: red + 256 * green + 65536 * blue.
Thanks for the feedback
"Quote:
'Does automatic re-grouping by item number sound as though it could be useful?'
Well, it is not only useful but definetely needed I think."
OK, I will do it.
"All I am interested in is that the original menu structure stays intact and the entries don't change position. Renumbering is a nice feature to clean up the wincmd.ini but only if it works flawlessly. Comments and the like are not needed imho. "
Working flawlessly certainly is the goal. If the user adds, removes, or moves menu items when synchronizing, then the second tool's automatic updating of the following menu item numbers (while retaining the item order determined by the user) can save time.
The tools parallel TC's handling of comments and blank lines. TC does not retain them in the menu sections when it saves Wincmd.ini files, so the tools also do not support comments and extra blank lines in the menu sections. In the non-menu sections, TC retains comments and blank lines, so the tools do also. Sometimes it helps visually to have a blank line above a section. Above the [Colors] section, I have a comment to myself about how to calculate the color number: red + 256 * green + 65536 * blue.
Thanks for the feedback
Icfu:
"Quote:
'Does automatic re-grouping by item number sound as though it could be useful?'
Well, it is not only useful but definetely needed I think."
The first tool now re-groups menu commands by item number, and sub-sorts by command type.
Quote:
"1. Sorting problems, for example _ comes after z although it should appear before a."
The first tool now sorts using text comparisons rather than binary comparisons, so "_" comes before "a".
Thanks for spotting the problems
"Quote:
'Does automatic re-grouping by item number sound as though it could be useful?'
Well, it is not only useful but definetely needed I think."
The first tool now re-groups menu commands by item number, and sub-sorts by command type.
Quote:
"1. Sorting problems, for example _ comes after z although it should appear before a."
The first tool now sorts using text comparisons rather than binary comparisons, so "_" comes before "a".
Thanks for spotting the problems