'''Please do not delete anything from this page. Add comments under the requirement or add requirements if necessary. Must means it is essential to the upgrade. Should means it would be a nice feature to have.''' = Requirements = 1. The new format must provide an easy upgrade path for the user's commands. a. A keyword system appears to be the best option. b. Something like {{{ ; FM/2 commands file -- 3 lines: title, cmd line, flags[[BR]] version = 2 Name = Unlock exe or dll Command = unlock -v %a Icon = 4096 MenuId = 2100 IconName = areallygoodicon.ico[[BR]] }}} 2. The format must be easily expandable while remaining backward compatible. a. A keyword system appear to be the best option 3. The format must lock in the resource number for each command. a. A keyword system appear to be the best option 4. The menu structure of the commands should be under the control of the user. a. Should the user be able to name the sub menus or should a limited number of sub menu options be provided? b. Should all user added and FM/2 provided commands be movable to all potential sub menus? 5. The user should be made directly aware of new FM/2 command options and have access for adding FM/2 command options at anytime. 6. Under a keyword system. The rules would be that each definition much start with the name keyword. The other keywords could follow in any order. See example under 1 above. 7. The (an) ini file should be considered for the storage medium. 8. A version keyword would allow us to add features while retaining backward compatibility. If we know the file is version 2, it's trivial to provide default values for a version 3 file. 9. We should provide a drop down of the icons that were unused because their command is not being used and we should include extra icons in FM2RES.DLL for use on toolbars. 10. An FM2PATH for use with commands, associations, archivers, etc to reduce the need to include full path names & without cluttering up OS/2's PATH should be developed. a. FM2PATH is probably just another settings page item. Probably needs to be presented as a listbox with reordering support. 11. The file structure used should be adaptable to the associations and archivers to allow for the same basic code to parse all of them. 12. The resource number must be clearly displayed somewhere or adding to the toolbar must take care of this issue internally to make it easy for the user to add commands to toolbars. 13. The ability to set a modified environment should be included. = Code Modifications = == Data Structures == {{{ typedef struct { typedef struct LINKCMDS { CHAR *pszCmdLine; CHAR *pszTitle; ULONG flags; USHORT usToolId; struct LINKCMDS *next; struct LINKCMDS *prev; } LINKCMDS; // flag masks #define SYNCHRONOUS 1 #define ASYNCHRONOUS 2 #define DETACHED 3 #define SEPARATE 4 #define SEPARATEKEEP 5 #define WINDOWED 16 #define MAXIMIZED 32 #define MINIMIZED 64 #define FULLSCREEN 128 #define INVISIBLE 256 #define BACKGROUND 512 #define WAIT 1024 #define PROMPT 2048 #define KEEP 4096 #define ONCE 8192 #define DIEAFTER 16384 #define SEAMLESS 32768 #define CHILD 65536 }}} {{{ typedef struct TOOL { CHAR *pszHelp; CHAR *pszText; INT flags; struct TOOL *next; USHORT id; // CHAR *pszIcon; // icon name or icon resource number in #icon format USHORT usMenuId; } TOOL; // flag masks #define T_DROPABLE 0x00000001 #define T_EMPHASIZED 0x00000002 #define T_INVISIBLE 0x00000004 #define T_SEPARATOR 0x00000008 #define T_TEXT 0x00000010 #define T_MYICON 0x00000020 // This can go away maybe }}} == Source code == === fm3dll.h === Refactor structures to command.h === command.c === === tool.c ===