ESignal / Turbofeed Automation

[Zapbbx]

I am considering becoming an API subscriber to develop a 3rd party charting application, but I would rather not!

Is eSignal Capable of these things:

1. I want to use a custom dll written in C# or VB.NET inside the EFS scripting code.

2. I would like to record tick data as it comes through turbofeed to a database, and at a later time, simulate turbofeed to eSignal so the data can come back through tick by tick, not just the whole day loaded and analysed as static candles.

And a couple questions:

1. When is your EFS file processed? Is it processed on every tick or price change on a chart? Or is it only processed upon the close of a candle?

2. What time series of data are available in eSignal? (1min chart, 5 min chart, etc)
I want tick charts, 5 sec charts, customizable... is this possible?

Like I said, If I want my app to do the things listed here, I may have to write my own, but I'd rather not have to build the infrastructure to do studies, charting, etc.. I would rather use eSignals... In my opinion the most important feature is to replay data into the system as if it were real-time, or a 2x or 10x speed.

Thanks for your help.

[GenSpoo]

DLLs can be called from inside an EFS script. I'm not sure about .Net DLLs as they are managed code and I've never tried it. C/C++ DLLs should work though.

From within eSignal you can download tick files and then have it play them back in realtime, 2X, 3X, etc. by choosing "Replay Tick File" from the Tools menu. It will replay the data with 1 second interval accuracy (since the ticks are stored with 1 second timestamps). The data is played back under the symbol $PLAYBACK.

EFS studies are computed on a tick by tick basis, unless you tell it to compute on close only.

You can use minute charts, second charts, tick charts, and volume bar charts within the main app.

Cheers... George

[Zapbbx]

dll / playback considerations

Thanks for your fast reply.

I am not a C/C++ developer, only VB.NET/C#.NET, has anyone used these dlls in eSignal script? If so, are there some sample dlls / sample EFS I can look at to see how the object refrencing, etc works? Also, if dlls are supported, to what extent, can I setup my EFS to respond to a callback event from my dll, or is it a call only type mechanism? Also, if for example if wanted to create a dll to store tick/indicator data in a datastore, can I create an instance of the dll that will remain and I can continue to call its methods on a tick by tick basis without having to call the constructor everytime, to save on constructor / db connection resources of course.

In regards to the playback, sounds good you can playback data through the app, if thats the case how does the system handle the date and time of the ticks being replayed? I know Turbofeed resets your system clock upon connection, does this functionality run without turbofeed altogether? And does the data replay in it's time sequence, not corresponding to the system time?

[DionLoy]

Managed Code DLLs

I only have a basic background in mixing Managed + Unmanaged DLLs together, so feel free to correct me if I'm wrong.

The main thing is to export unmanaged "C" style functions from the DLL. The underlying can be managed code after that.

This is impossible to do with VB.NET or C#. All DLLs created in those language are managed code only.

However, this IS possible to do this with Managed C++ extensions AFAIK. This is because MC++.NET is currently the only language that can mix managed and unmanaged code into the same DLL.

The EFS would hook into your unmanaged C style functions, and the underlying code could then pass the data values for manipulation to your managed code.

This is an interesting problem. Due to the cross-language capabilities of .NET, it is quite possible for someone with experience in MC++.NET to write a 'wrapper' DLL that acts as the intermediary between eSignal EFS and your fully-managed DLL (in C#, VB.NET, whatever .NET language). It is something that I think we should look into for a future version. No guarantees though =).

[Zapbbx]

C# Interop...

Thanks again for your reply.

It is possible in C# to compile the dll in a COM callable wrapper, which in essence will export a .tlb file which can be imported with the C++ #import directive. I guess it depends on how you refernce dlls from esf script to determine if this is possible or not.

Is eSignal COM aware, or will it only work right with an unmanaged C++ dll?

note in C++, you could use hi-level wrappers like:
#import "YourDotNET.tlb" no_namespace
...
ICSTestCOMPtr spI = NULL;
HRESULT hr = spI.CreateInstance( __uuidof(CSCOMObj) );
spI->YourMethod();

this all depends of course on how your setup to handle external .dll files in the first place.

[GenSpoo]

I'm pretty sure you can only call functions within a DLL. No COM objects or events. I have not seen any documentation to the contrary. My guess is they are just grabbing a handle to the function, pushing the arguments on the stack, and then jumping to the function address.

Cheers... George

[Zapbbx]

C++ wrapper for C# dll

ok guys, since I'm not a C++ developer, and really dont know any C++ guys offhand. How hard would it be for me to put together a .dll in C#, and have someone write me a wrapper for it. I could just expose a single function, and if I saw the C++ code on how that was done, I'm sure I could replicate it for more functions. I have the MS C++ 6.0 Software and compiler with my Visual Studio 6...

I want to use eSignal as my analysis platform to provide tick and indicator data to an external system. It would be easy to do if I could write my own dll and call it from eSignal, but I guess unless I'm a C++ guy I cant huh?

Is anything other than a C++ .dll supported? VB6? I know they all use COM.

I want to do this with as little latency as possible, sending real-time, or playback realtime indicator data to my analysis app. What are my options? Any if eSignal is not capable of this, how about just getting data from eSignal.. Am I going to have the same problem with the API ?

Thanks for the help...

[DionLoy]

Zapbbx,

I would suggest the ActiveX API reather than the EFS API.

You can write your program to interface with the ActiveX API data control in eSignal with your .NET code

ActiveX gives you a much richer set of data than would EFS, and much more control over it too.

I don't believe you can control playback through the ActiveX though, but you can retrieve level1, level2 and historical quotes as well as all ticks and bid/ask quotes in realtime. It should technically also happen faster than in EFS as EFS is interpreted, but the ActiveX API is all native code.

[Zapbbx]

EFS vs Data

We are really discussing two seperate functions here. I wont need access to the Data API or ActiveX if I can get a C# dll to work to send me indicator data from EFS.

If I cant get this to work then I would have to used the ActiveX or API to pull data from turbofeed mgr into my own application, which if that is the case I would no longer be using eSignal's charting application.

I really want to use eSignal's charting application, rather than having to develop time-series, indicator, charting, etc... all on my own with a raw data feed. This is all contingent upon me being able to use or wrap a C# dll that I can communicate with in EFS...

Is there some dll reference? In what way would I test this functionality?

[GenSpoo]

I'm pretty sure you are not going to get a C# DLL to work the way you want within an EFS script (at least not without writing a C/C++ wrapper for it). It really sounds to me like you should be using the ActiveX control. However, it might be worthwhile for you to try out the main app for a month and see if it can do what you want without resorting to ActiveX.

For some documentation, you might find the EFS help file from http://share.esignal.com/groupconten...le&groupid=114 helpful. It has a page on how to call DLLs from inside scripts.

Cheers... George

[Zapbbx]

Help with my Bridge...

Ok guys,

Here is an unmanaged C++ project with a Managed C++.NET front end bridging the gap to a managed VB.NET dll.

I declared a simple function:

EFS:
var d = new DLL("I:/dlltest/Bridge.dll");
d.addFunction("test", DLL.DOUBLE, DLL.CDECL, "bridge_function_int", DLL.INT);

function preMain()
{}

function main()
{var v = d.call("test", 123);}

C++:
#using "dotNetAssembly.dll"
using namespace System;
using namespace dotNetAssembly;

extern "C"
{
__declspec(dllexport) int __cdecl bridge_function_int(int input)
{
mcDotNetClass __gc *DotNetObject;
DotNetObject = new mcDotNetClass;
return DotNetObject->test_integer(input);
}

VB.NET:
Public Function test_integer(ByVal input As Integer) As Integer
Return input + 25
End Function

I have a C++ test project

extern "C"
{
int __cdecl bridge_function_int(int input);
}
int _tmain(int argc, _TCHAR* argv[])
{
printf("Testing bridge dll...\n\n\n" );
printf("Calling bridge_function_int with a value of 5...\n");
printf("The return of bridge_function_int is %d\n\n\n",bridge_function_int(5));
printf("press enter to exit...\n");
getchar();
return 1;
}

The BridgeTest.exe app runs the sample fine, it calls the unmanaged C++ function "bridge_function_int" which calls the .Net function "test_integer"

It all seems to work fine here, even efs says No problems, but upon running I get a JIT error which crashes the eSignal app.

Any help would be appreciated... You have to have .Net 2002 + to open the solution file... see attached zip

Thanks very much if you can help
Gavin Stevens

[GenSpoo]

Hi Gavin,

I can't do it until a bit later, but I'll try it out on my system when I get the chance. I'll let you know what happens.

Cheers... George

[GenSpoo]

One thing, just looking at the code, you tell the EFS that the result is a double:

d.addFunction("test", DLL.DOUBLE, DLL.CDECL, "bridge_function_int", DLL.INT);

Yet, in your DLL code you declare a return type of int.

__declspec(dllexport) int __cdecl bridge_function_int(int input)

Doubles are 64 bits long and ints are 32, so this could cause an issue with the stack one one way or another.

Cheers... George

[Zapbbx]

return type

George,

I noticed that after I posted the message... in reality I did use the DLL.INT return type in the efs.

I am not sure what causes the jit error to occur... I was unable to get the solution to compile in Release mode, only in debug mode. Seems to work fine with the exe wrapper. My problem is my inexperience with C++ with which I have no ability to debug.

I appreciate your help, and look forward to whatever you find out.

Thanks,
Gavin

[GenSpoo]

Hi Gavin,

Are you using .Net 2003? I came across the bridge project on CodeProject and some folks also mention a build issue that might be related. They linked to the following Microsoft Knowledge Base article that might help. I am a bit stretched for time right now, so haven't had a chance to fully look into it. Let me know if any of this helps...

http://support.microsoft.com/?kbid=814472

Cheers... George