UIElement

From cxwiki

Revision as of 20:20, 16 April 2018 by Windwalkr (talk | contribs) (Created page with "<div class="mw-parser-output"><div class="mw-parser-output">UIElement forms the baseclass for all cxsource user interface components.</div> <div class="mw-parser-output">&nbsp...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

UIElement forms the baseclass for all cxsource user interface components.
 

UIElement Hierarchy

TBD.

User Interface Implementations

Individual User Interface components often correspond with specific OS-provided native user interface controls, however this is not the only possible usage of the cxsource user interface system. UIElements can implement one of many possible behaviours, eg:
  • Native User Interface Control. Typically, a single native user interface is selected per build platform. This is often mandated by the host OS, but in some cases there may be multiple options available.
  • Custom User Interface Control. For example, a game may implement its own user-interface which exists as an overlay in a 3D-rendered view.
  • Generic User Interface Control. The components do not have hardcoded external dependencies and are compatible with any parent user interface.

To allow this flexibility, the cxsource user interface framework provides the concept of a "user interface implementation". At the most simple level, this is represented by objects of the UIAppearanceImplementation class. Each UIElement may be compatible with a single implementation, or multiple implementations, or even all implementations. In some scenarios, it may be possible to embed elements of one implementation under elements of a different implementation, in which case a special adapter element may be generated automatically to translate between the implementations.

Threading

The UIElement class itself is thread-agnostic. It is not reentrant, but does not make any assumptions about which thread is placing a call to any particular method. Derived classes may place additional limitations.

A given user interface hierarchy is effectively tied to a single thread. Once the UIElement is inserted into a user interface hierarchy, the user interface will typically be calling methods on the object quite regularly, which effectively ties the object to that user interface's thread. Some user interface implementations take this further, by mandating that:

  • The UIElement is only used from the thread that created it; or
  • The UIElement is only used from the application main thread.

Individual UIElement objects may also link into other thread-specific systems (such as CXTask) which will preclude them from being used on other threads safely.

As a result, the following guidelines are implicit when using UIElements:

  • Native User Interface components should only be created or accessed on the application main thread.
  • Any given custom User Interface component should be created and accessed on a single thread, which may or may not be the application main thread.