Using dll's created by C\C++

[Guest]

I have created a simple dll using the most recent version of Microsoft Visual C#.Net 2003. I am having problems getting this to work and I need some help.

Here is the resultant error message I am getting:

SimpleDll 11 19 2005.efs, line 7: Internal Error: DLL(testDLL.dll), Function(Add) was not found


I am also using eSignal 7.9.1 build 732.

Here is the efs:

var d = new DLL("testDLL.dll");
d.addFunction("MyCallName", DLL.INT, DLL.CDECL, "Add", DLL.INT, DLL.INT);

function main()
{
    if (getBarState() == BARSTATE_ALLBARS)
    {
            debugPrintln(d.call("MyCallName", 5, 7));// line 7 where I am getting the error
    }
} 

simple efs

here is the compiled dll

test dll

and here is the uncompiled source code

using System;

namespace testDLL
{
    /// <summary>
    /// Summary description for Class1.
    /// </summary>
    public class Class1
    {
        public Class1()
        {
            //
            // TODO: Add constructor logic here
            //
        }

        /// <summary>
        /// Add method
        /// </summary>
        public int Add(int val1, int val2)
        {
            return val1+val2;
        }
        /// <summary>
        /// Mult method
        /// </summary>
        public int Mult(int val1, int val2)
        {
            return val1*val2;
        }
    }
} 

source code

The efs is finding the dll, however, when it is calling the function within, it experiences the error. Any help or insight would be appreciated.

[DionLoy]

Hi Steve,

C# can not be called from a non-.NET or non-COM program. If EFS supported COM calls, you could wrap your C# function in a COM callable wrapper, but we don't support that.

I did find this, not sure if it's of any help, I don't think this is easy task:

http://gotdotnet.com/Community/MessageBoard/Thread.aspx?id=347476

[Guest]

Hi Dion,

Thanks for getting back to me on this. There seems to be some clues in the link you provided, however, I am not holding out much hope using C# with efs. Regarding C# not being called from a non-.NET or non-COM program, that is probably why I could find so little information on it. I will have to try my hand with C++, but it may be a while till I get to that point. Thanks again for looking at this Dion.

Regards,

[futurenets]

Steve

I try and put a simple DLL setup together that you can build on.

However there are things you need to know ...

Initially it was intended that each "new DLL(...)" statement, would create a separate instance of the DLL for each EFS. Thus any variables defined in the DLL @ global scope would be unique per instance and each EFS would have it's own unique copy of the DLL data.

but there is a technical constraint outside the control of eSignal ...

Each time a DLL object is created in EFS, internally ::LoadLibrary is called. This is a function of the Win32 SDK. LoadLibrary does create brand new copies of the DLL if it is called from two separate programs (aka processes). But if LoadLibrary is called multiple times in the same program (aka process) (ie: eSignal), then each call is pointing to the same copy of the DLL being loaded.

Therefore 2 or more charts using the same DLL would all be potentially working on the same data causing some confusion.

I'll also try and include a solution that overcomes this problem.

Also when you pass EFS data into a DLL, any changes to that data in the DLL won't be reflected/seen in EFS. So the DLL functions should return data that is subsequently processed
by EFS.

[Guest]

Hi Paul,

That would be very nice, thank you. I was unaware of the issue of the dll's being shared, that could really gum up things if unaware of the potential for that. I appreciate the effort and look forward to seeing what you put together.

Thanks again,

[futurenets]

Steve

I've placed DLLSample.zip in my file share group - Futurenets.

It includes MS Visual Studio .NET 2003 project files, the sample DLL and the sample EFS.

When using arrays, take with pointers if you are new to this.

If you are unfamiliar with C++, stick with C since this is similar to EFS Javascript.

[futurenets]

Steve

So others can find this, you may want to suggest it be renamed to something like:

Using dll's created by C\C++

[Guest]

Hi Paul,

I went ahead and downloaded what you so kindly put together. Thanks for the effort, I appreciate the time it takes to provide a substantive example. I am getting 2005 Visual Net suite next week at a Microsoft sponsored event in Cincinnati. As it is, I only have the 2003 C# portion of the suite, so I have not ventured very much further than that. I will be trying my hand at modifying and compiling your dll code over the Holidays.

I had seen some of the material you had provided, but your example(s) seems to be more in depth and well commented regarding efs interaction(s), which is a big help. I look forward to working with this and will try and provide some better feedback when I get this working. My goal (at least in part) is to communicate with a NET application from the efs environment (non-API).

Thanks again,

[futurenets]

Steve

eSignal may correct me here but I think you'll hit a brick wall (same in TradeStation). You may need to find another way other than DLL.

Simply put, Windows operating system is based on a complex message system and the eSignal process will be exchanging many 000's of messages with it. As soon as you introduce your own DLL that starts its own line of communication with the operating system, it will become unstable. To stay safe, DLL functions should just manipulate data in some way, read/write to files etc.

[futurenets]

Here's a list of points I've included in the DLLSample.zip in my file share group ...

Take care using data in DLL's

1. Initially it was intended that each "new DLL(...)" statement, would create a separate instance of the DLL for each EFS. Thus any variables defined in the DLL @ global scope would be unique per instance and each EFS would have it's own unique copy of the DLL data.

but there is a technical constraint outside the control of eSignal ...

Each time a DLL object is created in EFS, internally ::LoadLibrary is called. This is a function of the Win32 SDK. LoadLibrary does create brand new copies of the DLL if it is called from two separate programs (aka processes). But if LoadLibrary is called multiple times in the same program (aka process) (ie: eSignal), then each call is pointing to the same copy of the DLL being loaded.

Therefore 2 or more charts using the same DLL could all be working on the same data potentially causing some confusion. The solution below overcomes this problem.

2. When you pass EFS data into a DLL, any changes to that data in the DLL won't be reflected in EFS. Have the DLL functions return data that is subsequently processed by EFS.

3. DLL.VOID is not allowed and all DLL functions must return a value.

4. Simply put, Windows operating system is based on a complex message system and the eSignal process will be exchanging many 000's of messages with it. As soon as you introduce your own DLL that starts its own line of communication with the operating system, it will become unstable. Therefore to stay safe, DLL functions should just manipulate data in some way, read/write to files etc.

5. Each function below needs to be listed in FN_DLL.def and defined in FN_DLL.cpp.

6. You will need Microsoft Visual Studio .NET 2003 or later.