Menu

Remarks: This can sometimes be useful to get the platform-specific object. Some handlers may not have any backing object for its functionality, so this may be null. It is more preferred to use the Widget.Handler and cast that to the platform-specific handler class which can give you additional methods and helpers to do common tasks. For example, the Application object's handler for OS X has a AddFullScreenMenuItem property to specify if you want full screen support in your app.

Remarks: Subclasses may override the standard behaviour so that hierarchy of widgets can be taken into account. For example, a Control may return the data context of a parent, if it is not set explicitly.

Remarks: This can be used to determine when to allow certain logic during the update of the data context. It is used to disable binding setters on the model when the data context changes so that a binding does not cause the view model to be updated when the state hasn't been fully set yet.

Remarks: When the widget is disposed, it can no longer be used.

Remarks: When implementing child widgets that can participate in the context based binding (MVVM), You can set this to the parent widget when it is added or removed to it (usually via a collection). Note that you should typically provide a

public new [ParentWidget] Parent { get; }

property so that consumers of your API cannot set the parent to an invalid value.

Remarks: This gets set to the current Platform.Instance during the construction of the object

Remarks: Styles allow you to attach custom platform-specific logic to a widget. In your platform-specific assembly, use Add{H} to add the style logic with the same id.

// in your UI
var control = new Button { Style = "mystyle" };

// in your platform assembly
using Eto.Mac.Forms.Controls;

Styles.AddHandler<ButtonHandler>("mystyle", handler => {
	// this is where you can use handler.Control to set properties, handle events, etc.
	handler.Control.BezelStyle = NSBezelStyle.SmallSquare;
});

Remarks: The callback should implement the parent class' Widget.ICallback interface so that there only needs to be a single callback for the entire hierarchy. This should return a static instance to avoid having overhead for each instance of your control.

Remarks: This is typically called from the constructor after all of the logic is completed to construct the object. If your handler interface has the AutoInitializeAttribute set to false, then you are responsible for calling this method in your constructor after calling the creation method on your custom handler.

Remarks: Implementors may override this to fire this event on child widgets in a heirarchy. Alternatively, implement IBindableWidgetContainer for your widget and this will trigger any events on the children automatically. This allows a control to be bound to its own BindableWidget.DataContext, which would be set on one of the parent control(s).

Remarks: When you implement IBindableWidgetContainer, this will also unbind any of its children.

Remarks: When you implement IBindableWidgetContainer, this will also update bindings for all of its children.

Remarks: This may be fired in the event of a parent in the hierarchy setting the data context. For example, the Container widget fires this event when it's event is fired.