GUI Design for Trading Parameter Configuration

C

clearinghouse

I have a trading framework that is all console based, written in C++, has no GUI, and is a totally user unfriendly piece of code. It is so unfriendly it gets chosen out of police line-ups even when it didn't commit the crime. Every time I change (add/remove) a trading parameter, I recompile the code and re-run it. If I want to change the value of the parameter, the program just re-reads a file on demand and sets parameters. This was fine for a while, but now this is getting to be a headache.

In C#, they have reflection so trading parameters can be turned into datagrid objects and tweaked so that the user interface doesn't really need to be recompiled. In C++, this is more of a nuisance, as there is no comparable (in terms of features) object reflection.

I am trying to avoid the headache in programming where if I add a trading parameter, I have to go edit the GUI also to show this trading parameter. Since I am using C++, I need some kind of solution that approximates what they have in C#. I could just use C# for the GUI, but I would need some sort of scheme to serialize objects between my C++ code and the C# GUI.

So I am looking for some kind of scheme to generate some kind of GUI based on my trading parameters. The simpler the better, but I have heard of people running a script during compile to generate XML to generate GUIs for wxGlade or something. I just want a lazy-mode solution, as development time is the variable I am trying to optimize here.

I would be interested to hear what people out there are doing to avoid this headache.
 
Maybe you could draw inspiration from commercial products. Shown below is the GUI from a product called Trading Blox which is in Google's search index.

The user has selected a parameter optimization (what the product calls a "Stepped Parameter Simulation"), varying three of the parameters over user-specified ranges. This example would run 14 x 9 x 19 = 2394 different combinations of parameter values.

Users specify parameters with the "Edit Parameter" dialog. This defines variable type, lexical scope, initialization, and name (2 different ways).

You may or may not like it, but possibly it could give you an idea or two.

attachment.php


attachment.php
 

Attachments

Make a configuration table, a text file, with the parameters and read them in the program. You then change the file, you don't have to recompile.
 
I undesrtstand the key requirement is GUI code should need NO modification whenever parameters are added or removed. So, nothing fancy, just an extendible list of parametrs...

Given you need only basic GUI, the easiest thing is to create GUI in C++/CLI (former managed C++). This way you can keep all teh code in C++, can use whetever .NET GUI elements you want... and the compioler will handle the transition between native and managed types smoothly. You can freely mix C++ arrays and .NET collections in the same function. Also try keeping GUI and the rest in separate source files. This way you can specify that "the rest" shoudl eb compiled into native (not "managed" code) while GUI has to be "managed".

The only drawback of this approach is you need to watch out for conversion between C++ and .NET types. Say, string or array assignment may compile but have quite different effect from what you expect. Given you code in C++ I'm sure this is nothing new :)

attachment.php
 

Attachments

If you use tradelink (open source, any .net language supported) you can do this :

Code: 
public class MyStrategy : ResponseTemplate
{
    int _param1 = 22;
    public int Param1 { get { return _param1; } set { _param1 = value; } }


    override void Reset()
    {
        // prompt user to edit all public properties of this strategy
        ParamPrompt.Popup(this);
    }
}

see tradelink.org for more info
 
Quote from LeeD:

I undesrtstand the key requirement is GUI code should need NO modification whenever parameters are added or removed. So, nothing fancy, just an extendible list of parametrs...

Given you need only basic GUI, the easiest thing is to create GUI in C++/CLI (former managed C++). This way you can keep all teh code in C++, can use whetever .NET GUI elements you want... and the compioler will handle the transition between native and managed types smoothly. You can freely mix C++ arrays and .NET collections in the same function. Also try keeping GUI and the rest in separate source files. This way you can specify that "the rest" shoudl eb compiled into native (not "managed" code) while GUI has to be "managed".

The only drawback of this approach is you need to watch out for conversion between C++ and .NET types. Say, string or array assignment may compile but have quite different effect from what you expect. Given you code in C++ I'm sure this is nothing new :)

attachment.php
More...

Your idea is good, except what happens if my trading app runs in Linux? I'm ok with a Windows GUI viewer. Here's something closer to my environment:

Say I put my trading parameter defines in a header, in an "unmanaged" struct or class. The C++/CLI compiler and my gcc compiler on Linux both see this header. How would I take that unmanaged struct and convert it into a managed struct that's reflectable in .NET in C++/CLI?

So say I have this:

struct Parameters {
int emaperiod;
int someotherparameter;
float yourmom;
};

My trading strategy keeps a copy of 'Parameters' uses it, and then someone in the GUI sets 'yourmom' to 10.0f. I would need some kind of 'public ref class ParametersDotNET' in .NET that is separate from 'Parameters', and then I'd have to have code translate 'Parameters' into 'ParametersDotNET' and vice-versa, to serialize 'Parameters' back and forth, like if I were using Google protocol buffers or something.

Is there an easy way to serialize the unmanaged type into a reflectable .NET equivalent, without writing code for the explicit serialization? Am I making sense, or should I elaborate further?
 
Quote from intradaybill:

Make a configuration table, a text file, with the parameters and read them in the program. You then change the file, you don't have to recompile.
More...

I'm ok with recompiling. I'm just not ok with having to adjust the GUI constantly to reflect changes, if I add/remove a parameter from some kind of 'struct'.
 
The beauty of C++/CLI is that Microsoft imlementation produces "mixed-mode" compiled executables. So, the same piece of code can use both .NET and native types.

The easiest solution would be to make the structure containing parameters a manged object in C++/CLI. After you change the structure definition the rest of the code should run as is.

[Serializable]
public ref struct Parameters {
int emaperiod;
int someotherparameter;
float yourmom;
};

Now the object can use default serialization in .NET.

See example.

If you want to run it on Linux, try Mono.
 
The alternative would be to serialize "native" struct Parameters as an array of bytes, but this approach is less robust.
 
Quote from LeeD:

The beauty of C++/CLI is that Microsoft imlementation produces "mixed-mode" compiled executables. So, the same piece of code can use both .NET and native types.

The easiest solution would be to make the structure containing parameters a manged object in C++/CLI. After you change the structure definition the rest of the code should run as is.

[Serializable]
public ref struct Parameters {
int emaperiod;
int someotherparameter;
float yourmom;
};

Now the object can use default serialization in .NET.

See example.

If you want to run it on Linux, try Mono.
More...

What I find inelegant about this is that now I have to maintain a separate .NET header to support that [Serializable] attribute. I guess what I can do is generate two separate headers in my makefile, like:

struct Parameters {...} in Parameters_Unmanaged.h and then

[Serializable]
public ref struct Parameters {...} in Parameters_Managed.h, that maps direct.

Then when they get compiled, the only trick left will be serializing them back and forth. This could actually work, and I get the reflection automatically in .NET.

Thanks for the idea. I think this might be the way to go.
 
You must log in or register to reply here.
Back
Top