ToolBar.IHandler
ReferencesHandler interface for the ToolBar.
Properties
Dock
#Gets or sets the docking hint for the toolbar.
Remarks: Most platforms will not respect this, and is usually only necessary for constrained devices like iOS and Android. Each platform may have a different default docking mode, depending on the type of device. E.g. iPhone will by default show the toolbar on the bottom, whereas iPad and dekstop platforms will show it at the top by default. Additionally, some platforms may choose to show the toolbar in a different way, e.g. the Navigation control on iPhone has a standard toolbar available, so if you are using one it will attempt to use its toolbar to provide the best native experience.
Value: The dock hint.
Remarks: Some platforms may use this to identify controls (e.g. web)
NativeHandle
nint NativeHandle { get; }
Gets the native platform-specific handle for integration purposes
Value: The native handle.
TextAlign
#Gets or sets the text alignment hint.
Remarks: Note that some platforms may define the visual style of toolbar items and this just serves as a hint for platforms that support such features (e.g. windows).
Value: The text alignment hint.
Methods
Remarks: Most events are late bound by this method. Instead of wiring all events, this will be called with an event string that is defined by the control. This is called automatically when attaching to events, but must be called manually when users of the control only override the event's On... method.
Initialize
void Initialize()
Called after the widget is constructed
Remarks: This gets called automatically after the control is constructed and the Widget.IHandler.Widget and Widget.Platform properties are set. When the handler has specialized construction methods, then the AutoInitializeAttribute can be used to disable automatic initialization. In this case, it is the responsibility of the subclass to call Widget.Initialize()
UnhandleEvent
Called when the last subscriber to an event has been removed, so the platform can stop listening for it.
Remarks: Only reached for events whose remove accessor uses PropertyStore.RemoveHandlerEvent(string, Delegate), and only for events that were attached because something subscribed to them. An event attached because the widget overrides its On[Event] method is never detached, since it has to keep firing regardless. Most events stay attached for the life of the widget, which costs nothing. Detaching is worth wiring up for the few that hold onto something expensive or process wide while they are attached, such as a system wide hook. Handlers deriving from WidgetHandler<TWidget> get an implementation of this that dispatches to WidgetHandler<TWidget>.DetachEvent(string), which is what to override.
Parameters:
| id (string) | ID of the event to stop handling |