Plugin Classes

The plugin assembly offers different namespaces to better organize the available classes:

  • Core: contains the classes required to interact between the plugins and the host.
  • UserControls: contains the user controls (and their related classes) used to create the control panels.
  • Base: the base namespace contains the common functionality inherited by all the plugins. All of them will be created inheriting the classes present in this namespace. This namespace has 3 sub-namespaces:
    • Common: contains the base classes used by both roles (historical and real-time).
    • Historical: contains the base classes used to create the historical role of the plugins.
    • Real-time: contains the base classes used to create the real-time role of the plugins.
  • Common: contains the classes that can be used by both roles (historical and real-time).
  • Historical: contains the classes that can be used by the historical role.
  • Real-time: contains the classes that can be used by the real-time role.

Theme classes:

PluginTheme.xaml: this xaml contains the styles and definitions used by the plugins. It's mainly a copy of the StockAnalystTheme.xaml but this one is intended to be exposed to plugin developers that will reference only the Plugin assembly. 

Core classes:

  • IStrategyPlugin: defines all the methods a custom strategy plugin must implement to be able to be managed by the Stock Analyst application. As an interface cannot define constructor parameters a method called Initialize will be used to construct the objects. They won't be usable until Initialize has been called. We are using an interface instead of an abstract class because we don't need to provide default implementation of anything, the only reason to think on abstract classes is the need of a parameterized constructor but we solved the issue with the Initialize method. The plugin defines the following methods:
    • VisualRepresentation: this property retries an object with the visual representation information needed by the application to represent the plugin in its menus and toolbars.
    • HistoricalControlPanel: this property contains the user control that will be used by the end-user when using the plugin in historical mode to select the desired settings and execute it. The HistoricalControlPanel user control is in charge of executing the plugin and generating the results.
    • RealtimeControlPanel: this property contains the user control that will be used by the end-user when using the plugin in realtime mode to select the desired settings and execute it.
    • SupportsRealtime: as probably plugins will start only with historical mode implemented this readonly property lets the application know if the plugin has the runtime mode implemented. If you no implement the RealtimeControlPanel throw a NotImplementedException and set this property to false.
    • Initialize: this method is a replacement of the constructor as an interface cannot define constructors. 
    • HistoricalResultsAvailable: this event will be raised when the plugin in historical mode has generated the execution results and will be handled by the UI to show them.
    • RealtimeNotification: this event is raised by the plugin in real-time mode when it has something to notify (it is a sort of logger). The application will handle this notifications, store them on the database and show it on a grid.
  • PluginContainerAssemblyAttribute: it's the attribute an assembly must contain to be examined by the PluginDetector class. This is done because examining assemblies with reflection is a slow process and this way we can limit the exploration to the assemblies that we know for sure that contain plugins.
  • VisualRepresentation: it is the memory model of the data that a plugin requires to be represented in the UI by the MainUI. It contains a text entry for the menu and an icon for the toolbar.
  • RealtimeNotificationEventArgs: the event args present in a RealtimeNotification event. They include the message being notified.
  • HistoricalResultsAvaiableEventArgs: the event args present in a HistoricalResultsAvailable event. They include the list of operations and the custom data if any.
  • HistoricalExecutionResult: this class models the result of an historical execution. It contains the list of operations and the range of dates used.

User controls:

They are controls that probably are present on most plugin control panels as they allow you to do basic tasks like selecting the date range in historical mode, choosing the stock to operate with, etc. All of the follow the same principle, a user-control class has a view-model that manages a model. The user-control defines the name, the view-mode is the name of the user-control plus VM and the model is the name of the user-control plus Data.

  • DateSelector: it is a control that allows the end user to select a date range or to select all the available dates.
  • DateSelectorData: the data managed by the DateSelector.
  • DateSelectorVM: the view-model of the DateSelector.
  • HourSelector: it is a control that lets you filter the quotations the decision engine process based on the hour of the quotation.
  • HourSelectorData: the data managed by the HourSelector
  • HourSelectorVM: the view-model of the HourSelector. 
  • IPresetSelector: defines the set of operations that a preset selector has to be able to execute. It is used as the DataContext of the PresetSelector because otherwise we should declare the PresetSelector control generic and user-controls cannot be generic.
  • Preset: a preset is the configuration of a plugin (the plugin's settings) plus a name. As each plugin settings are different from the others the class is generic. It is the model of the PresetSelector (with a collection).
  • PresetsDataSource: is the class responsible of storing or loading a preset. Is generic because presets from different plugins have different settings.
  • PresetSelector: it is the control that allows the end user to manage presets (create, load or delete them).
  • PresetSelectorVM: it is the view-model of the PresetSelector.
  • StockParametersSelector: it is a control that sets the different parameters of a stock like fees, reserves and tick value.
  • StockParametersSelectorData: the data managed by the StockParametersSelector.
  • StockParametersSelectorVM: the view-model of the StockParametersSelector.
  • StockSelector: it is the control that allows us to select an existing stock based on its name.
  • StockSelectorData: it is the data managed by the StockSelector. Even when it contains only a string we still follow the same principle used on the other controls.
  • StockSelectorVM: it is the view-model of the StockSelector. It contains the logic to refresh the name list.

Base classes:

They contain the skeleton of a plugin. To create one you must always use the classes available here:


  • PluginBase: the base class for all plugins. Implements IStrategyPluing and contains all the common methods. Inheritors just need to create their VisualRepresentation, the HistoricalEngine and the HistoricalControlPanel. The class does not provide real-time support so it has to be coded directly on the inheritor. 
  • CommonSettingsBase: all the plugins share some settings (the stock parameters, the selected stock [at least one or more] and the hour settings). This class contains them. They also define all the copy and clone features needed to implement presets.
  • StrategyControlDataBase: it is the base of the model of each StrategyControl. Defines the settings shared by the different strategy controls (the ones configuring the specific behaviour of each plugin). The only thing they have in common is that they notify changes. The StrategyControlData class of each plugin must inherit from this class.
  • StrategyControlVMBase: it is the base of the view-model of each StrategyControl. The only thing they share is that all of them contain the model.
  • DecisionEngineBase: this class contains what is common between all the DecisionEngines. All of them contain a class with the internal data of the engine (the DecisionEngineData) to be able to save it or to modify it (mostly to allow real-time editing of the values). This class also contains the real-time connection management and the quotation evaluation. The class will call the EvaluateStateMachineInternal abstract method each time it receives a quotation.
  • DecisionEngineDataBase: contains the data present on all the DecisionEngine classes. The current quotation, the previous one, the current state and the previous one.
  • DecisionEngineStateBase; contains the states present on all the DecisionEngines classes. As enums cannot be inherited static instances are used as enum values. A string member is added to make debug easier.


  • HistoricalSettingsBase: extends the settings shared with CommonSettingsBase adding to them the Date range setting.
  • ControlPanelVMBase: contains what is common between the different plugin's historical panels (almost everything). How to execute the plugin, when it can be executed, the view-models of the different controls and the validation of the parameters. Inheritors just need to create the HistoricalSettings instance, pass it to the base (to be able to handle the presets), add the StrategyControlVM and define the default values of the settings.
  • HistoricalDayProcesorBase: contains what is required to process one day of historical data. Basically this is the DataLoader, the DataFeeder and the OperationManager. The class was created to allow parallel execution as having one processor per thread we stop sharing data between threads.
  • HistoricalEngineBase: contains the common code between historical engines. Most of the code handles the execution of the plugins. To do it the engine base creates only one DayProcessor and reuses it. As one of the goals is to test the DecisionEngine in historical mode to validate it before going into real-time we want to use it in the same way as the real-time engine.


Utility classes:

They are classes that I've found myself using on repeated plugins so I thought they could be generic and reused and thus they are here

  • DynamicStopLossManager:
  • FakeOrderExecutor:
  • HistoricalItemToProcess:
  • OperationExecutedEventArgs:
  • OperationManager:

Last edited Feb 18, 2013 at 3:30 PM by somos, version 13


No comments yet.