Developers have the option of deriving their own classes from ActionTable and ActionItem, but are not required to do either. Only ActionCallback is required to be derived.
Developers will derive their own class from ActionItem only in rare cases. The default implementation of this class stores internal strings for its name, description, category, icon, etc. In some cases this might lead to duplicate storage if that information is stored elsewhere. In that case, you might want to provided a specialization of this class for memory efficiency.
The ActionTable class also has several virtual methods that the developer might want to implement. All these methods have default implementations, so specializing this class is not required unless special behavior is needed.
The default handlers for some of the handlers may not be appropriate. For example ActionTable::IsEnabled() returns TRUE in every case in the default implementation. If you want command to be disabled under some conditions, then you will need to build a specialization of ActionTable and implement this method. The methods of ActionTable that you might want to implement are:
You only need to implement the last two methods if your table uses command identifiers that are not persistent from session to session. An example of this is the ActionTable that exports scripts from MAXScript. This system reads all the scripts in your system and assigns command IDs that are based on the order the scripts are read from the file. This might change from session to session, so when we want a persistent ID to write out to our keyboard or CUI files, we need one that doesn't change. For scripts, it writes the name of the script concatenated with the category of the script. The ReadPersistent ActionId takes that string and returns its integer command ID for the current session.
For tables that use constant integer identifiers that don' t change from session to session, like the FDD example in the section on Building Action Tables there is no need to implement these method.