Split user added commands association, toolbar entries from FM2 base entries

[Gregg Young]

Move the base entries to code or ini file with their own assignment space (eg 4000-4100 are fm2 designated commands). Need an install process that can parse and split existing files. Should be able to edit parameters etc on FM2 commands. This would facilitate our updating of commands associations and toolboxes without effecting user modifications. Perhaps we should assign # at creation so that moving stuff around doesn't effect toolbars. I am not clear why commands like bldlevel, pstat and rmview aren't base commands

[Gregg Young]

customizations. I now believe the only practical way to do this is by

moving all this stuff to the ini file.

This is OK, but keep in mind that the INIs are a scarce resource. The profile manager code keeps the data for all INIs in shared memory and the buffer appears to be shared across all INIs.

1. We add all the FM2 provided stuff directly.

OK.

2. We create a utility or cmd that will parse the user files and add all

their existing additions. We could try to incorporate the ability for it to "remember" when the resource # has to be changed and to change it in the tls designations.

OK.

3. For things that have order (ie commands or associations) we add an

ordinal entry that tells fm2 the order.

OK.

4. For commands we add a resource number so each command has a number

that can be used in a toolbar that will never change.

OK.

5. A next resource

# ini entry would facilitate keeping track of this number. If something is deleted its number would not be reused but since it appears we have 1000 resource numbers reserved this should not be a problem.

Worst case we could implement some sort of renumbering scheme.

6. I see

this as a problem for archiver.bb2 where editing the file is much easier than using the dialog (for me at least)

We probably need to revisit the UI design. A clone button can be useful to help save a lot of extra typing.

ini. 10. After the transition any new stuff we add would simply be added to the ini as new kays on install.

How do you plan to keep track of what's been deleted from the standard set by the user?

Is this a reasonable and doable plan? Are there thing I am missing?

It's doable, but non-trivial. It's more of an algorithm problem than a data storage problem. Once you have a design that handles all the edge conditions, it's not going to matter whether the data is kept in the inis are in text files.

[Gregg Young]

I think a better way to do this would be to add sub menus with our commands. We could add a tool in the commands dialog to remove the duplicates from the root menu if the user wished. We should also update the command dialog so it will update the resource number on any user added icons in toolbars. We could just add a new .dat file for these. This would make it easy to do additional toolbars since we would assign the resource numbers and could even add icons to fm3res.dll for them. By using sub menus having duplicates would not be very noticeable and would solve the issue of user changes made to the base file. We could then add notebook page(s)(perhaps a separate commands notebook) where our additions could be removed or added to the menu by check boxes. We should check on startup that the files for each item is found and if not remove it from the menu.

[Gregg Young]

Moving associations and commands to the INI file has resolved the issues related to this ticket