Page Comparison

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 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.
However it is possible to configure Noah such that an attached UnBoundAction object can only be removed or changed within the calendar day it was created. In this configuration an attempt to modify an UnBoundAction will cause an exception.

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.
The module can request another module to be launched, pre-loaded with an existing UnBoundAction to view or edit it.

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.