Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
This sounds Great Mike!
Does this mean, the DLL's created for NT can be imported directly into Easy Language & we don't have to convert the indicator or strategy to Easy Language?
If not I wish there was an easy way to do this, please let me know if you have any ideas on easy portability between NT & Easy Language.
It just means if there is something you want to do that can't be done in EasyLanguage, you could pass variables to/from a DLL and have your C++ do it.
As for NT -> EL conversion, it is case by case. I suggest creating a new thread here in the EasyLanguage Programming section for each indicator you want converted, attach a screen shot or two and the NinjaTrader .cs source, and then someone can probably covert it.
I'm in the middle of trying to convert the (futures.io (formerly BMT) Elite) "Myst" strategy from NinjaTrader to MultiCharts 7.4 which lead me down a path trying to implement some of the toolbar functionality that NT handles natively in C# as a C/C++ DLL. I may go the C# or even PowerBasic DLL route at some point, but wanted to start with the most direct method first. Given I've yet to try to extend MC via DLLs, this seemed like a worthwhile exercise to see what was involved. I read the TradeStation/EasyLanguage PDF references and several postings on the web that specifically state that function prototypes need to be defined as "__stdcall" rather than "__cdecl" but MC was unable to locate the functions I defined via DefineDLLFunc due to the mangling that occurred by declaring the functions as "__stdcall" (e.g. bad_function( int ) is exposed as _bad_function@4).
I shot MC support an Email and they referred me to GlobalVariable.dll which exposes the functions without "mangling" the function names which makes me wonder if they used the recommended "__stdcall" method as well - requests for access to the GlobalVarialble.dll source haven't been answered .
I wrote a quickee C/C++ test harness using "__cdecl" (on Visual Studio 2010) that others may find helpful. I'd still be interested in hearing if anyone has been able to create and call DLLs by defining functions using "__stdcall" - attempts at going that route lead MC to report "Can't find function "blah" in dll.". These functions do nothing beyond returning the value passed, but it's a start (K.I.S.S.).
-Guy
p.s. BTW, wouldn't your example above return a string pointer from a stack frame that may cause "bad bahavior" - just curious - it's been a while since I've dabbled in C/C++...
extern "C" {
MYSTTOOLBARWIN32_API int __stdcall bad_function( int v );
MYSTTOOLBARWIN32_API int __cdecl good_function( int v );
MYSTTOOLBARWIN32_API unsigned char __cdecl test_byte( unsigned char b );
MYSTTOOLBARWIN32_API char __cdecl test_char( char b );
MYSTTOOLBARWIN32_API LPSTR __cdecl test_lpstr( LPSTR s );
MYSTTOOLBARWIN32_API unsigned short __cdecl test_word( unsigned short w );
MYSTTOOLBARWIN32_API unsigned int __cdecl test_dword( unsigned int dw );
MYSTTOOLBARWIN32_API unsigned int __cdecl test_bool( unsigned int b );
MYSTTOOLBARWIN32_API int __cdecl test_int( int i );
MYSTTOOLBARWIN32_API long __cdecl test_long( long l );
MYSTTOOLBARWIN32_API float __cdecl test_float( float f );
MYSTTOOLBARWIN32_API double __cdecl test_double( double d );
}
// MystToolBarWin32.cpp : Defines the exported functions for the DLL application.
Thank you Fu510n for posting this code, but I have a trouble to realize it. I copy your text into VC2010(express edition), compile, put the dll to TSSupport\Multicharts folder and after I open PL indicator on chart, i have this message:
Thank you Fu510n for posting this code, but I have a trouble to realize it. I copy your text into VC2010(express edition), compile, put the dll to TSSupport\Multicharts folder and after I open PL indicator on chart, i have this message:
What do you think may be the reason, can you help me?
32-bit vs. 64-bit Multicharts? (i.e. the DLL has to match whatever version of Multicharts you are running).
Just a thought,
Guy
p.s. I've since upgraded to using VS2013 Community Edition to generate 64-bit DLLs to use with MC64. The same code above "still works", in addition to a PureBasic variant which generates the exact same output. I can post new/updated sources for both versions if anyone is interested...
...function prototypes need to be defined as "__stdcall" rather than "__cdecl" but MC was unable to locate the functions ... due to the mangling
that occurred by declaring the functions as "__stdcall" (e.g. bad_function( int ) is exposed as _bad_function@4).
...
I wrote a quickee C/C++ test harness using "__cdecl" (on Visual Studio 2010) that others may find helpful. I'd still be interested in hearing
if anyone has been able to create and call DLLs by defining functions using "__stdcall"...
There are two ways to solve the mangling problem.
1) With DEF file: export the function names via a DEF file, there you can name them whatever you want. Specify the functions by ordinal numbers.
2) Without DEF file: Use linker comments. A lot of people will not like it but it's the simpliest way. The pragma statements belong anywhere in the function body.
Both ways work with VS2008 Pro, I can't test with later versions here but it should do.
Peter
//#define EXPORT extern "C" __declspec(dllexport) // standard way, we don't use it here
#define EXPORT comment(linker, "/EXPORT:"__FUNCTION__"="__FUNCDNAME__) // export unmangled names w/o DEF file
int WINAPI GetLastWin32Error() { // WINAPI translates to __stdcall
return(GetLastError());
#pragma EXPORT
}
32-bit vs. 64-bit Multicharts? (i.e. the DLL has to match whatever version of Multicharts you are running).
Just a thought,
Guy
p.s. I've since upgraded to using VS2013 Community Edition to generate 64-bit DLLs to use with MC64. The same code above "still works", in addition to a PureBasic variant which generates the exact same output. I can post new/updated sources for both versions if anyone is interested...
I received a request for the 64-bit PureBasic (5.31) source from another futures.io (formerly BMT) member, so I'll embed below...
MC64DLLTest.pb
;
; ------------------------------------------------------------
;
; PureBasic - DLL example file
;
; (c) Fantaisie Software
;
; ------------------------------------------------------------
;
; This example is a skeleton to build easely a DLL using PureBasic
; The dll is created in the 'Compilers' directory, under the
; 'purebasic.dll' name. An associated '.lib' is generated to use
; with VisualC++.
;
;
; Rules to follow:
; - Never write code outside a procedure, except for variables
; or structure declaration.
;
; - DirectX Init routines must not be initialized in the the
; AttachProcess() procedure
;
; - There is 4 procedures automatically called: AttachProcess(),
; DetachProcess(), AttachThread() and DetachThread(). If you don't
; need them, just remove them.
;
#TESTDLL = 0
CompilerIf #TESTDLL = 0
CompilerIf #PB_Compiler_OS = #PB_OS_Windows
; These 4 procedures are Windows specific
;
; This procedure is called once, when the program loads the library
; for the first time. All init stuffs can be done here (but not DirectX init)
;
ProcedureDLL AttachProcess(Instance)
EndProcedure
; Called when the program release (free) the DLL
;
ProcedureDLL DetachProcess(Instance)
EndProcedure
; Both are called when a thread in a program call or release (free) the DLL
;
ProcedureDLL AttachThread(Instance)
EndProcedure
ProcedureDLL DetachThread(Instance)
EndProcedure
CompilerEndIf
; Real code start here..
;
ProcedureDLL EasyRequester(Message$)
MessageRequester("EasyRequester !", Message$)
EndProcedure
ProcedureDLL.i bad_function( v.i )
ProcedureReturn 123
EndProcedure
ProcedureCDLL.i good_function( v.i )
ProcedureReturn 456
EndProcedure
ProcedureCDLL.b test_byte( b.b )
ProcedureReturn b.b * 2
EndProcedure
ProcedureCDLL.c test_char( b.c )
ProcedureReturn b.c
EndProcedure
ProcedureCDLL.s test_lpstr( s.s )
ProcedureReturn s.s
EndProcedure
ProcedureCDLL.w test_word( w.w )
ProcedureReturn w.w
EndProcedure
ProcedureCDLL.l test_dword( dw.l )
ProcedureReturn dw.l
EndProcedure
ProcedureCDLL test_bool( b.b )
ProcedureReturn b.b
EndProcedure
ProcedureCDLL.i test_int( i.i )
ProcedureReturn i.i * 2
EndProcedure
ProcedureCDLL.l test_long( l.l )
ProcedureReturn l.l * 2
EndProcedure
ProcedureCDLL.f test_float( f.f )
ProcedureReturn f.f
EndProcedure
ProcedureCDLL.d test_double( d.d )
ProcedureReturn d.d
EndProcedure
CompilerElse
If OpenLibrary(0, "MC64DLLTest.dll") Or OpenLibrary(0, "MC64DLLTest.so")
CallFunction(0, "EasyRequester", @"Hello World!")
EndIf
CompilerEndIf
...and the EasyLanguage MC source that calls the above DLL...