Class CommandInfo
An instance of this class describes a custom command, declared and implemented by a document plugin
Inherited Members
Namespace: SuperOffice.CRM.Documents
Assembly: SuperOffice.Plugins.dll
Syntax
public class CommandInfo
Remarks
Depending on the return type indicated in the command, the command might be filtered (not shown) by the GUI. For instance, commands that return values of type SoProtocol would not be shown by the (first release of the) Pocket CRM client, since that client does not use nor support soprotocol-type navigation. Return types None and Message will be supported by all clients. Non-GUI clients should save Message-type return values in their log.
A command may be executed on a document at any time. Constraints, such as some commands requiring the document to be checked out, must be enforced by the document plugin - the rest of the system has no knowledge of command semantics. A document plugin with complex custom workflow and GUI requirements can use the returntype SoProtocol to force navigation subsequent to execution of a command, and in this way chain a set of operations. It is OK to have 'secret' commands, i.e., commands that are not declared through GetDocumentProperties(IDocumentInfo, string[]); such secret commands will not be shown in any GUI, but will still be available through the document services.Constructors
CommandInfo()
An instance of this class describes a custom command, declared and implemented by a document plugin
Declaration
public CommandInfo()
Remarks
Depending on the return type indicated in the command, the command might be filtered (not shown) by the GUI. For instance, commands that return values of type SoProtocol would not be shown by the (first release of the) Pocket CRM client, since that client does not use nor support soprotocol-type navigation. Return types None and Message will be supported by all clients. Non-GUI clients should save Message-type return values in their log.
A command may be executed on a document at any time. Constraints, such as some commands requiring the document to be checked out, must be enforced by the document plugin - the rest of the system has no knowledge of command semantics. A document plugin with complex custom workflow and GUI requirements can use the returntype SoProtocol to force navigation subsequent to execution of a command, and in this way chain a set of operations. It is OK to have 'secret' commands, i.e., commands that are not declared through GetDocumentProperties(IDocumentInfo, string[]); such secret commands will not be shown in any GUI, but will still be available through the document services.Properties
DisplayName
Display name, shown in menus, command lists and similar GUI elements.
The name should be kept short. Resource tags, such as [SR_OK], are allowed and will be substituted runtime with the proper languages. A document plugin can have a resource module added to the client to substitute any custom tags.Declaration
public string DisplayName { get; set; }
Property Value
Type | Description |
---|---|
string |
Remarks
Depending on the return type indicated in the command, the command might be filtered (not shown) by the GUI. For instance, commands that return values of type SoProtocol would not be shown by the (first release of the) Pocket CRM client, since that client does not use nor support soprotocol-type navigation. Return types None and Message will be supported by all clients. Non-GUI clients should save Message-type return values in their log.
A command may be executed on a document at any time. Constraints, such as some commands requiring the document to be checked out, must be enforced by the document plugin - the rest of the system has no knowledge of command semantics. A document plugin with complex custom workflow and GUI requirements can use the returntype SoProtocol to force navigation subsequent to execution of a command, and in this way chain a set of operations. It is OK to have 'secret' commands, i.e., commands that are not declared through GetDocumentProperties(IDocumentInfo, string[]); such secret commands will not be shown in any GUI, but will still be available through the document services.DisplayTooltip
Tooltip string associate with the command - can be a literal or a tooltip hint.
Simple tooltips can be literals, and can contain resource tags (including culture-independent formatted dates, see the CultureDataFormatter class for examples and encoding methods. More complex tooltips can be represented as tooltip hints, which cause a runtime call to the tooltip provider system. A document plugin can add its own tooltip provider in order to process such hints into the final tooltip text. This is the recommended approach for tooltips that are time-consuming to precalculate. Tooltip hints can be constructed using the SuperOffice.CRM.Tooltips.TooltipProvider. See SuperOffice.CRM.Tooltips.TooltipProvider.MakeTooltipHint method. They are parsed by provider plugins, either standard ones or custom plugins that can be written together with a document plugin. This member may be blank, if no tooltip is provided.Declaration
public string DisplayTooltip { get; set; }
Property Value
Type | Description |
---|---|
string |
Remarks
Depending on the return type indicated in the command, the command might be filtered (not shown) by the GUI. For instance, commands that return values of type SoProtocol would not be shown by the (first release of the) Pocket CRM client, since that client does not use nor support soprotocol-type navigation. Return types None and Message will be supported by all clients. Non-GUI clients should save Message-type return values in their log.
A command may be executed on a document at any time. Constraints, such as some commands requiring the document to be checked out, must be enforced by the document plugin - the rest of the system has no knowledge of command semantics. A document plugin with complex custom workflow and GUI requirements can use the returntype SoProtocol to force navigation subsequent to execution of a command, and in this way chain a set of operations. It is OK to have 'secret' commands, i.e., commands that are not declared through GetDocumentProperties(IDocumentInfo, string[]); such secret commands will not be shown in any GUI, but will still be available through the document services.IconHint
Icon hint, which should resolve to an icon that is compatible in size with a standard menu or dropdown list font. May be blank.
Declaration
public string IconHint { get; set; }
Property Value
Type | Description |
---|---|
string |
Remarks
Depending on the return type indicated in the command, the command might be filtered (not shown) by the GUI. For instance, commands that return values of type SoProtocol would not be shown by the (first release of the) Pocket CRM client, since that client does not use nor support soprotocol-type navigation. Return types None and Message will be supported by all clients. Non-GUI clients should save Message-type return values in their log.
A command may be executed on a document at any time. Constraints, such as some commands requiring the document to be checked out, must be enforced by the document plugin - the rest of the system has no knowledge of command semantics. A document plugin with complex custom workflow and GUI requirements can use the returntype SoProtocol to force navigation subsequent to execution of a command, and in this way chain a set of operations. It is OK to have 'secret' commands, i.e., commands that are not declared through GetDocumentProperties(IDocumentInfo, string[]); such secret commands will not be shown in any GUI, but will still be available through the document services.Name
The programmatic name of the command, uniquely identifying this command for the document plugin.
Command names need not be unique between different document plugins, but have to be unique within one plugin. Commands should generally not be cached by NetServer or clients, since they are assumed to be dependent on a particular document and its state. Commands for standard Check out, Check in and Undo Check out are not custom commands; they will be shown by GUI logic automatically if the document plugin declares that it supports locking. Similarly, commands for showing a version list are automatically added if such functionality is supported.Declaration
public string Name { get; set; }
Property Value
Type | Description |
---|---|
string |
Remarks
Depending on the return type indicated in the command, the command might be filtered (not shown) by the GUI. For instance, commands that return values of type SoProtocol would not be shown by the (first release of the) Pocket CRM client, since that client does not use nor support soprotocol-type navigation. Return types None and Message will be supported by all clients. Non-GUI clients should save Message-type return values in their log.
A command may be executed on a document at any time. Constraints, such as some commands requiring the document to be checked out, must be enforced by the document plugin - the rest of the system has no knowledge of command semantics. A document plugin with complex custom workflow and GUI requirements can use the returntype SoProtocol to force navigation subsequent to execution of a command, and in this way chain a set of operations. It is OK to have 'secret' commands, i.e., commands that are not declared through GetDocumentProperties(IDocumentInfo, string[]); such secret commands will not be shown in any GUI, but will still be available through the document services.ReturnType
Declaration of what kind of return type the execution of this command will give
A client may use this field to filter out some commands - for instance, a client that does not support soprotocol or custom navigation, would only show commands declared to return None or Message.Declaration
public ReturnType ReturnType { get; set; }
Property Value
Type | Description |
---|---|
ReturnType |
Remarks
Depending on the return type indicated in the command, the command might be filtered (not shown) by the GUI. For instance, commands that return values of type SoProtocol would not be shown by the (first release of the) Pocket CRM client, since that client does not use nor support soprotocol-type navigation. Return types None and Message will be supported by all clients. Non-GUI clients should save Message-type return values in their log.
A command may be executed on a document at any time. Constraints, such as some commands requiring the document to be checked out, must be enforced by the document plugin - the rest of the system has no knowledge of command semantics. A document plugin with complex custom workflow and GUI requirements can use the returntype SoProtocol to force navigation subsequent to execution of a command, and in this way chain a set of operations. It is OK to have 'secret' commands, i.e., commands that are not declared through GetDocumentProperties(IDocumentInfo, string[]); such secret commands will not be shown in any GUI, but will still be available through the document services.