Providing UI Elements for Extensions

WealthLab 9 separates core extension logic from Windows-specific user interface functionality. The core WealthLab.Core assembly contains platform-neutral components and interfaces. Extension components such as Historical Data Providers, Broker Providers, and Event Providers can therefore implement their primary functionality without depending directly on WPF. Windows-specific user interface functionality is provided through the WealthLab.WPF assembly.

WealthLab uses classes derived from ObjectEditorBase to connect platform-neutral extension components with their WPF user interfaces. An ObjectEditorBase implementation can provide several types of UI integration:

• Custom Settings Editors for configurable components such as Historical Data Providers and Broker Providers.
• New DataSet Wizard pages for Historical Data Providers that require additional information when creating a DataSet.
• BarGlyphs that allow Event Providers to display custom Event graphics on charts.
• Platform Methods that allow platform-neutral extension components to request Windows-specific functionality.

Build Environment

You can create an Object Editor in a .NET development tool such as Visual Studio 2026. Create a class library project that targets .NET10, then reference the WealthLab.WPF library DLL that you'll find in the WL9 installation folder.

Your Object Editor will be a class in this library that descends from ObjectEditorBase, which is defined in the WealthLab.WPF library, in the WealthLab.WPF namespace. After you implement and build your library, simply copy the resulting assembly DLL into the WL9 installation folder. The next time WL9 starts up, it will discover your Object Editor, making it available in appropriate locations of the WL9 user interface.

Accessing the Host (WL9) Environment

The IHost interface provides access to the current WealthLab environment. Extensions can use it to retrieve application-level information and services, such as the location of the user's WealthLab data folder or the DataSets defined by the user.

You can access the current IHost instance from anywhere in your extension through the WLHost singleton and its Instance property. For example, the following code retrieves the path to the user's WealthLab data folder:

string folder = WLHost.Instance.DataFolder;

Use WLHost.Instance whenever your extension needs access to functionality exposed by the IHost interface.

Creating an ObjectEditorBase Class

If your extension requires custom configuration or other WPF integration, create a class derived from ObjectEditorBase. Override its Name property so that it returns exactly the same name as the component that the ObjectEditor supports. For example:

public override string Name => "My Data Provider";

The associated extension component ultimately derives from Configurable, which also exposes a Name property. WealthLab uses these matching names to associate the platform-neutral component with its WPF ObjectEditor. A common extension architecture therefore consists of two assemblies:

MyCompany.MyExtension
    Platform-neutral extension logic

MyCompany.MyExtension.WPF
    Windows-specific UI and ObjectEditorBase classes

This separation allows your primary extension logic to remain independent of WPF.

Custom Settings Editors

The Configurable base class supports two approaches to storing component configuration, controlled by its ConfigurableType property.

ParameterList

With this option, the component uses its Parameters collection to store configuration. Define the Parameters by overriding GenerateParameters in the component:

protected override void GenerateParameters()
{
    // Add configuration Parameters.
}

WealthLab can automatically generate a standard settings editor for these Parameters.

VanillaString

With this option, the component stores its configuration as a single string in its Configuration property. Because WealthLab cannot automatically determine how this string should be edited, components using VanillaString generally provide their own Custom Settings Editor.

Do I Need a Custom Settings Editor?

If your component uses ParameterList, you normally do not need to create a custom editor. WealthLab automatically provides a standard Parameter editor. You can still provide your own editor if your component requires a more specialized user interface. If your component uses VanillaString, provide a Custom Settings Editor to allow the user to configure the component. Historical Data Providers display their settings editor when selected in the Data Manager. Broker Providers display their settings editor when the user configures the Broker in the Order Manager.

GetCustomSettingsEditor

public virtual ICustomSettingsEditor GetCustomSettingsEditor()

Override this method in your ObjectEditorBase descendant to return the editor for your component. The editor is typically a WPF UserControl that implements ICustomSettingsEditor. The ICustomSettingsEditor interface allows the editor to exchange configuration information with WealthLab.

New DataSet Wizard Pages

Historical Data Providers can use ObjectEditorBase to provide custom pages for the New DataSet Wizard. When the user selects your Historical Data Provider and proceeds through the Wizard, WealthLab displays the pages supplied by your ObjectEditor.

Do I Need Custom Wizard Pages?

If your Historical Data Provider requires only a list of symbols, you normally do not need to implement custom Wizard pages. WealthLab provides a standard page that allows the user to enter the DataSet's symbols. Implement custom Wizard pages when your DataSet requires additional configuration. Examples might include selecting an exchange, market, index, data category, or other Provider-specific options.

DSString

Each DataSet can store Provider-specific configuration information in its DSString property.

public string DSString

Your Wizard pages collect the information required to create the DataSet, and your ObjectEditor ultimately converts those selections into the DSString returned by GetWizardDSString. The Historical Data Provider can later examine this string when it needs to interpret the DataSet's configuration.

Initializing the New DataSet Wizard

public virtual void InitializeNewDataSetWizard(
    DataSet ds = null)

Override this method to initialize your Wizard pages. This is a good place to create the WPF UserControls that represent the individual pages and initialize any supporting state. If ds contains a DataSet, initialize your controls using the configuration stored in:

ds.DSString

This allows the same UI to be used when working with an existing DataSet configuration.

Returning the First Wizard Page

public virtual UserControl GetFirstWizardPage()

Return the first WPF UserControl that WealthLab should display for your Provider in the New DataSet Wizard. You will typically create your Wizard page instances during InitializeNewDataSetWizard and return the appropriate instance here. For example:

private MyWizardPage _page;

public override void InitializeNewDataSetWizard(
    DataSet ds = null)
{
    _page = new MyWizardPage();
}

public override UserControl GetFirstWizardPage()
{
    return _page;
}

Validating a Wizard Page

public virtual bool CanAdvanceToNextPage(
    UserControl page,
    ref string errorMessage)

WealthLab calls this method when the user attempts to advance from one of your Wizard pages. Examine the values entered into the supplied page and return true if the information is valid. If the user cannot advance, return false and assign a description of the problem to errorMessage. For example:

public override bool CanAdvanceToNextPage(
    UserControl page,
    ref string errorMessage)
{
    MyWizardPage p =
        page as MyWizardPage;

    if (String.IsNullOrWhiteSpace(
        p.SelectedMarket))
    {
        errorMessage =
            "Select a market before continuing.";

        return false;
    }

    return true;
}

Returning the Next Wizard Page

public virtual UserControl GetNextWizardPage(
    UserControl page)

After CanAdvanceToNextPage returns true, WealthLab calls this method to obtain the next page. Return the UserControl that should follow the supplied page. If your Wizard contains only one page, you do not need to override this method. Return null when there is no subsequent page.

Identifying the Last Wizard Page

public virtual bool IsLastWizardPage(
    UserControl page)

Return true if the supplied UserControl represents the final page of your Wizard sequence. The default implementation returns true, so a single-page Wizard does not need to override this method. For a multi-page Wizard, examine page and indicate whether additional pages remain.

Creating the DSString

public virtual string GetWizardDSString()

Override this method to return the completed DSString for the DataSet. Build the string using the information collected by your Wizard pages. WealthLab assigns the resulting configuration to the DataSet being created.

Suggesting a DataSet Name

public virtual string SuggestedDataSetName

Optionally override this property to provide a suggested name for the DataSet. The suggested name can be based on selections the user made in your Wizard pages. For example, a Provider that allows the user to select an exchange might suggest:

public override string SuggestedDataSetName =>
    "NASDAQ Stocks";

BarGlyphs for Custom Event Types

Event Providers can use ObjectEditorBase to customize how their Events are represented on WealthLab charts.

public virtual object GetEventBarGlyph(
    EventDataPoint edp)

Override this method to return a custom chart glyph for the supplied EventDataPoint. Examine the EventDataPoint to determine which glyph should be used, then return an instance of a class derived from BarGlyphBase. For example, an Event Provider supporting several Event types could return a different BarGlyphBase implementation for earnings, dividends, ratings changes, or other Events. If you do not provide a custom BarGlyph, WealthLab uses its standard Event rendering.

Platform Methods

Platform Methods provide a bridge between platform-neutral extension logic and Windows-specific functionality implemented in a WPF assembly. The platform-neutral component initiates the request through the IHost interface. The associated ObjectEditorBase receives and executes the request.

ExecutePlatformMethod

In your ObjectEditorBase descendant, override:

public virtual object ExecutePlatformMethod(
    string methodName,
    object parameter)

Use methodName to determine which platform-specific operation the component is requesting. The optional parameter can contain information required to perform the operation. Return the result of the operation to the caller. For example:

public override object ExecutePlatformMethod(
    string methodName,
    object parameter)
{
    if (methodName == "OpenApplication")
    {
        // Perform Windows-specific operation.

        return true;
    }

    return null;
}

Calling a Platform Method

The platform-neutral component calls the method through the WealthLab host:

object result =
    WLHost.Instance.ExecutePlatformMethod(
        "OpenApplication",
        parameter);

WealthLab locates the ObjectEditorBase associated with the calling component and invokes its ExecutePlatformMethod implementation. This allows the core extension assembly to request platform-specific operations without referencing WPF or other Windows-specific APIs directly.

Example: Interactive Brokers

The Interactive Brokers Broker Provider illustrates the purpose of Platform Methods. The Broker Provider resides in a platform-neutral assembly and needs to perform a Windows-specific operation: launching Interactive Brokers TWS. The core Broker Provider requests the operation through:

WLHost.Instance.ExecutePlatformMethod(
    "OpenTWS",
    parameter);

A corresponding ObjectEditorBase implementation in the WPF assembly handles the "OpenTWS" method, attempts to launch TWS, and returns the result to the Broker Provider. This architecture keeps Windows-specific functionality out of the core Broker Provider while still allowing it to integrate fully with the WealthLab 9 desktop environment.