Excerpt |
---|
The UnBoundAction object is introduced into the Noah system by modules. The module can access information regarding the actions through UnBoundAction objects. This information includes the type of the UnBoundAction, the user and module that created the UnBoundAction, and a description of the UnBoundAction. NOAH can request a module to launch and include an UnBoundAction to be displayed. Alternatively, NOAH can request a module to launch without displaying any UnBoundAction. Noah 4 introduces two new concepts called Archived Actions this also applies to the UnBoundActions – please . Please refer to section ‘section The Concept of Archived Actions’ for a description.
After creating a new UnBoundAction object – , this UnBoundAction object can be added to the object hierarchy using the ModuleAPI to add the UnBoundAction to the UnBoundActions collection.
The default behavior for Noah is that after you have attached an UnBoundAction to the object hierarchy you can modify its properties whenever you like. UnBoundActions can only be modified by the module that added it. A module can access information regarding actions through UnBoundAction Objects. Examples of UnBoundAction information is - are the kind of UnBoundAction, the user that created the UnBoundAction, the module that created the UnBoundAction, and a description of the UnBoundAction. For further details about the UnBoundAction object, please refer to the ‘Noah 4 ModuleAPI Reference Guide’‘Namespaces,' under 'ModuleAPI Assembly' in the Noah 4 'ModuleAPI.chm' file. HIMSA requests that developers ensure their modules do not attempt to modify any UnBoundAction created by another module. |
Page Comparison
General
Content
Integrations