Shared libraries, extensions - howto
Author: RuneHS
Creation Date: 11/6/2009 5:28 PM
profile picture

RuneHS

#1
Here's really a "newbie" question...

I am used to programming in Delphi, making shared code libraries there is very easy. In any new code I must set up a reference to this gathering of functions, like the "using" statements on top of the WL code I presume.

How is that best done in WL, how can I gather my range of often-used functions in just one place? Is that via making an "Extension" or making a C# shared DLL library of some kind?

Sorry for not being an expert C# programmer!
profile picture

Cone

#2
Welcome RuneHS. You've got the right idea. Just create your own library. If you want you can even add to the Community.Components library. Even if you don't contribute, you can take a look at the source code for ideas.
profile picture

RuneHS

#3
Thanks!

There's a bit of a learning curve on the c# side for me (like all programming stuff, really - "heuristic learning", you know) - but I am on it!

It seems to me that I can do almost anything via the code, however the application is a bit limiting sometimes, e.g. when doing "Multi symbol backtest" (portfolio simulation). The application really cannot handle a basket of fx crosses, for instance (ref. other msg. in this forum). If you want tips on how that might be set up, let me know... BTW I guess all this is "well covered ground" for you guys, so sorry for being late to the party.

A general issue, if you know of it:

I imagine using the application for quick script programming and exploration and the like, and then standardized reporting might be done elsewhere once the script is in production. This could be done via exporting the "trades" table in WL (via the code) and picking the table up in some other application and taking it from there.

But: do you know of people accessing the WL function library remotely from other applications, thus making full and good use of the WL functions library but not the application itself? Could we imagine a setup where everything is run from another .NET compatible application like Visual Studio or Delphi - is that doable, do people do this?
profile picture

Eugene

#4
QUOTE:
The application really cannot handle a basket of fx crosses,

Yes, Wealth-Lab was not designed with multi-currency support in mind.

QUOTE:
then standardized reporting might be done elsewhere once the script is in production

Wealth-Lab 5 is a pretty much extensible platform, and we have developed a library of performance reporting with the help of the community (sharing their ideas, suggesting fixes etc.):

Community Performance Visualizers Pack

I mean you can export etc. but why bother if you can program everything about reporting in the app itself?

QUOTE:
thus making full and good use of the WL functions library but not the application itself?

This is not a use case, therefore it is unsupported.
profile picture

RuneHS

#5
Ok. BTW man - you are quick to reply! Aren't you sitting "over there" in US somewhere?

Regarding fx, it is possible to have WL handle a basket of fx-crosses via the code, so it seems to me.

In effect I have to "SetShareSize" in each fx cross so that the underlying amount is the same in USD terms (or volatility terms or whatever). I name each fx pair as AAABBB, like AUDUSD or NOKUSD. The position amounts has to be scaled to the same USD amount (or whatever other base currency).

Then, as the "Profit §" is produced (ref. the "Trades" table), the profit amount has to be converted back to USD since it sometimes comes out as USD and sometimes in other currencies, depending on the standard way of quoting the fx'es in the market.

E.g.
- for AUDUSD the fx is like 0.895, that is the number of USD per AUD (less than one USD per AUD). So 100.000 AUDUSD here for me means 100.000 AUD and the profit comes out in USD
- for NOKUSD the fx is like 5.75, that is the number of NOK per USD (many "nokkies" per USD). So 100.000 NOKUSD here for me means 100.000 USD and the profit comes out in NOK

So it's first a scaling of the position amount, and the a re-calibration of the "Positions.NetProfit" amount. That should do it, and it's doable in the code. It works for me - so far so good at least.