学步园

In former (Pre-UNO) time the slots where not only used for command dispatching but also for the implementation of our Basic API (up to StarOffice 5.2), so the slot arrays where "real" interfaces. There are a lot residues of the in the sdi files (see below), but they aren't used anymore.

The use case explains why there are two different kinds of slots, property slots and method slots, and the difference between them can be spotted easily from the definition of a slot in the sdi file. Here are two examples, the first one describing a method slot and the second one describing a property slot:

SfxVoidItem About SID_ABOUT
()
[
    /* flags: */
    AutoUpdate = FALSE,
    Cachable = Cachable,
    FastCall = FALSE,
    HasCoreId = FALSE,
    HasDialog = TRUE,
    ReadyOnlyDoc = TRUE,
    Toggle = FALSE,
    Container = FALSE,
    RecordAbsolute = FALSE,
    RecordPerSet;
    Synchron;
 
    /* config */
    AccelConfig = TRUE,
    MenuConfig = TRUE,
    StatusBarConfig = FALSE,
    ToolBoxConfig = TRUE,
    GroupId = GID_APPLICATION;
]
 
SfxBoolItem DesignerDialog SID_STYLE_DESIGNER
 
[
    /* flags: */
    AutoUpdate = TRUE,
    Cachable = Cachable,
    FastCall = TRUE,
    HasCoreId = FALSE,
    HasDialog = FALSE,
    ReadyOnlyDoc = FALSE,
    Toggle = FALSE,
    Container = FALSE,
    RecordAbsolute = FALSE,
    RecordPerSet;
    Synchron;
 
    Readyonly = FALSE,
 
    /* config */
    AccelConfig = TRUE,
    MenuConfig = TRUE,
    StatusBarConfig = FALSE,
    ToolBoxConfig = TRUE,
    GroupId = GID_FORMAT;
] 

Each slot is a block in rectangular bracket filled with attributes that is preceded by two lines that identify the slot and define its nature. The exact meaning of all the attributes is explained below, the most notable difference is seen in the second line of each block: the paranthesis of the "About" slot classify it as a method while the other one (without paranthesis) is a property. As explained above, this classification goes back to the old Basic API but besides that it's important for the implementation of macro recording that is also based on the Dispatch API (and for SFX component it's implemented using slots). "Method" and "property" slots are recorded differently.
The name in the middle of each first line of a block was used as the name of the property or method in the Basic API and today this name is the internal command name that is matched to any ".uno:xxx" CommandURLs of the Dispatch API. As an example, the slot named "Undo" is assigned to the ".uno:Undo" command. This matching requires that the internal command names have to be unique in the complete module. This uniqueness is verified by the svidl compiler that breaks in case if name clashes in a module.
The last part of each first line is the so called SlotID that in former times was the real identifier (not as today the internal command name) and it was also used inside the GUI element configuration files where today CommandURLs are used. So this SlotID had to be unique for the module at least, currently it's even globally unique but at least theoretically it is now obsolete. Inside the slot processing only the textual representation of the SlotID is relevant , not its numerical value.
Property slots have a type specified by the first part of the first line. The same data in a method slot specifies the return value of the associated method. Method slots also can gave parameters (non empty paranthesis) and a return value that could be used in the old Basic API of StarOffice, but also in internal methods of the SfxDispatcher. Strictly speaking the latter is still possible but we try to get rid of this. Here are two examples for slots with arguments, with and without return value: