Doing Strategy development in Visual Studio and inherit the interface in WLP

algtrader

#1

10/11/2017 5:13 PM

Hi Eugene,

I want to do the bulk of my strategy development using
VisualStudio (I use VS community 2017). With that in
mind, I want to implement strategies in such a way that
my source code looks like:
#1 on the Wealth Lab Pro side, and
#2 on the VS side.

Problem:
VisualStudio compiled everything with no complaints. The generated
libs were copied to: ".../Fidelity Investments/Wealth-Lab Pro 6/." ,
and WLP was re-started. WLP didn't display any errors when "Compile"
was pressed.

However, WLP does absolutely nothing.

Any ideas? I would really want to make this work, because it would
simplify so many things. For example, there's only 1 source code
to manage. No more cut/paste between WLP and VS, and sometimes losing
track of which one is the "current" version.

Thanks in advance.

/ALG

// ======================================================================
// 1. On the Wealth Lab Pro 6 side....

CODE:
Please log in to see this code.

// ======================================================================
// 2. On the VisualStudio side...

CODE:
Please log in to see this code.

Size:

Color:

Hi Eugene,

I want to do the bulk of my strategy development using 
VisualStudio (I use VS community 2017).  With that in 
mind, I want to implement strategies in such a way that
my source code looks like:
#1 on the Wealth Lab Pro side, and 
#2 on the VS side.

Problem:
VisualStudio compiled everything with no complaints. The generated
libs were copied to: ".../Fidelity Investments/Wealth-Lab Pro 6/." , 
and WLP was re-started.  WLP didn't display any errors when "Compile" 
was pressed.

However, WLP does absolutely nothing.

Any ideas? I would really want to make this work, because it would 
simplify so many things.  For example, there's only 1 source code
to manage.  No more cut/paste between WLP and VS, and sometimes losing
track of which one is the "current" version.

Thanks in advance.

/ALG

[b]
// ======================================================================
// 1. On the Wealth Lab Pro 6 side....
[/b]

[code]
using WealthLab;
using WealthLab.Indicators;
using MyStratUtils;
using MyStrategies;

namespace WealthLab.Strategies
{
    public class StrategyToRun :  MyFractalStrat
    {
       // Everything is in MyFractalStrat.
       // MyFractalStrat.Execute() should be implicitly called.
    }
}

[/code]

[b]
// ======================================================================
// 2. On the VisualStudio side...
[/b]

[code]
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// File: StratBase.cs, Part of assembly: MyStratUtils.lib
namespace MyStratUtils {
public abstract class StratBase : WealthScript
{
    // Execute() to be declared in actual strategy class.
    // Declare all utility functions that I use in all my strategies.

// optionally create log file
    public void setLogger(string fileName) {  /** create log file **/  }

// prLn(string s): 
    //  If running in WLP: PrintDebug(s), else Console.WriteLine(s)
    //  If logFile is active, also do: logFile.WriteLine(s)
    public void prLn(string s) { ... }

} 
}
[/code]

[code]
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// File: MyFractalStrat.cs,   Part of assembly: MyStrategies.lib
// 
...
using MyStratUtils;
namespace MyStrategies  {
public abstract class MyFractalStrat : StratBase 
{
    protected override void Execute() {
        // Strategy implementation, which can 
        // be as complex as needed.
    }

} 
}
[/code]

Eugene

#2

10/11/2017 6:30 PM

Hi Al,

Since you're asking me, I can't remember having tried this proxy pattern with regard to WealthScript Strategies. ¯\_(ツ)_/¯ So I have to take your word on that it does nothing. ;) Maybe there's some trick that doesn't come to my mind now, maybe the lack of StrategyHelper interface implementation, I don't know.

At least you can go the beaten path:

1. add a reference to your compiled function library (with setLogger, prLn, whatever)
2. edit the template code
3. save it by clicking Edit > Set as Default Template Code

algtrader

#3

10/11/2017 9:52 PM

OK I get it. From doing a bunch of test compiles I figured out that WealthLab.WealthScriptCompiler (the class that compiles the strategy code in WLP) has to know which instance of the WealthScript class to construct. It does this by examining all classes defined in the WLP strategy source code. The first non-abstract class whose immediate parent base class is WealthScript will be instantiated and used.

Luckily, WealthScriptCompiler only looks at the base name of the class, and not the fully qualified class name. Hence, the below solution works.

// ======================================================================
// 1. On the Wealth Lab Pro 6 side....

CODE:
Please log in to see this code.

// ======================================================================
// 2. On the VisualStudio side...

CODE:
Please log in to see this code.

Size:

Color:

OK I get it.  From doing a bunch of  test compiles I figured out that  [b][i]WealthLab.WealthScriptCompiler[/i][/b] (the class that compiles the strategy code in WLP) has to know which instance of the [b]WealthScript[/b] class to construct.  It does this by examining all classes defined in the WLP strategy source code.  The first non-abstract class whose [b][u]immediate[/u][/b] parent base class is   [b][i]WealthScript[/i][/b] will be instantiated and used.

Luckily, [b][i]WealthScriptCompiler[/i][/b] only looks at the base name of the class, and not the fully qualified class name.  Hence, the below solution works.

[b]
// ======================================================================
// 1. On the Wealth Lab Pro 6 side....
[/b]

[code]
using WealthLab;
using WealthLab.Indicators;
using MyStratUtils;
using MyStrategies;

namespace WealthLab.Strategies
{
    public class StrategyToRun :  MyStrategies.MyFractalStrat.WealthScript;
    {
       // Everything is in MyFractalStrat.WealthScript
       // MyFractalStrat.Execute() will be implicitly called.
    }
}

[/code]

[b]
// ======================================================================
// 2. On the VisualStudio side...
[/b]

[code]
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// File: StratBase.cs, Part of assembly: MyStratUtils.lib
// MyStratUtils.StratBase extends WealthLab.WealthScript, adding
// features that allow strategies to be developed in VisualStudio
namespace MyStratUtils {
public abstract class StratBase : WealthScript
{
    // Execute() to be declared in actual strategy class.
    // Declare all utility functions that I use in all my strategies.

// optionally create log file
    public void setLogger(string fileName) {  /** create log file **/  }

// prLn(string s): 
    //  If running in WLP: PrintDebug(s), else Console.WriteLine(s)
    //  If logFile is active, also do: logFile.WriteLine(s)
    public void prLn(string s) { ... }

// etc more features added 
} 
}
[/code]

[code]
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// File: MyFractalStrat.cs,   Part of assembly: MyStrategies.lib
// 
...
using MyStratUtils;  
namespace MyStrategies.MyFractalStrat  {
public abstract class WealthScript : StratBase 
{
    protected override void Execute() {
        // Strategy implementation, which can 
        // be as complex as needed.
    }
} 
}
[/code]

Eugene

#4

10/12/2017 5:51 AM

Al,

Glad you were able to find the solution on your own. Thanks for your contribution.

P.S.
Note to future posters:

This is a very specific, self-contained topic. If you have a general question re: Strategy development in Visual Studio, please ask it in a different thread. All questions not related to this design pattern will be cleaned away.

superticker

#5

10/16/2017 1:36 AM

If I'm understanding the last couple code blocks right, this also illustrates how to "override" or actually supersede/overload some WealthScript members with member functions of one's own design. I'm assuming C# works like C++ in this regard, but I may be wrong. I have noticed to truly override/overload inherited C# class members, they typically have to be declared as "virtual" within the (WealthScript) base class. Not the case with C++, though; C# maybe more restrictive. Perhaps someone could clarify if base-class overloading is somehow possible in C# without the virtual qualifier in the base class.

algtrader

#6

10/16/2017 5:30 PM

Just to clarify... In C#, the terms "override" and "overload" are very different.

Overloaded functions are functions with the same name, defined in the same scope, but having different parameters.
In the below example, calling foo(123) will call the function overload foo(int i), and foo("test") will call function overload foo(string s).

CODE:
Please log in to see this code.

In C# function overrides are the means of implementing new behavior in a subclass (ie. different from the parent class).
Only virtual or abstract functions may be overridden. The whole concept is a bit more involved, but googling "C# override"
should give good references (the first one, by Microsoft, explains it all).

superticker

#7

10/16/2017 8:07 PM

QUOTE:
In C# function overrides are the means of implementing new behavior in a subclass (ie. different from the parent class).
Only virtual or abstract functions may be overridden.

So I can use the approach in post #3 to overload existing WealthScript functions, but not override (modify their behavior totally) them because WealthScript isn't an abstract class and lacks the virtual qualifier on its class members. Thanks a bunch for the clarification. I think C# rules preserve the purity of the language (i.e. its class functionality) better than C++. Interesting.

algtrader

#8

10/25/2017 7:11 PM

Sorry for the confusion. C# added the "abstract" modifier, which in the case of the WealthLab.WealthScript.Execute() method, says that the method is not defined in the base class, but must be defined only once elsewhere in a descendant class. Think of the "abstract" modifier to be the same as the C++ virtual modifier, except that only one override is allowed.

Thus in my examples above, the class MyStratUtils.StratBase implements a subclass of WealthLab.WealthScript with additional extensions. Note that MyStratUtils.StratBase does not define (ie. override) the Execute() function. This is because I intended MyStratUtils.StratBase to be my replacement for WealthLab.WealthScript.

The Execute() function will be defined in each strategy that I create using MyStratUtils.StratBase. See post #3 in this thread,

Hope this helps.

superticker

#9

10/25/2017 9:39 PM

Thanks for the update about having only one override allowed of the Execute() function.

I've coded one private, WL-component *.DLL library myself that employs WealthScript member functions. In so doing, I have to pass an instance of WealthScript into it (with the this operator) in order to use these WealthScript functions in my component library. But I kind of like your alternative way of having one's strategy inherit from one's MyStratUtils.StratBase base class instead WealthScript directly as shown in post# 3.

I often wondered if C# programming would be conceptually easier if WealthScript were a C# interface rather than a base class. But currently, I don't understand C# interfaces well enough yet to really know. Happy computing....