CODEWITHSUNDEEP
c++dllmql4metatrader4mt4
user1465810
user1465810

Reputation: 11

How to create a DLL, which accepts strings from MT4 and returns back string type?

I am trying for two weeks to create a DLL to which I can pass strings and get back strings. But still no success.

I tried this on Dev-C++(TDM-GCC 4.9.2) and visual studio community 2015. I searched a lot about this and tried almost every sample code I found but I have no success.

I have to use this DLL with MetaTrader Terminal 4.
Here is a one sample code, which I used. This code compiles successfully but when I send a string to this, from MT4, I get an access violation error.

#ifndef MYLIB_HPP
#define MYLIB_HPP

#include <string>

#ifdef MYLIB_EXPORTS
#define MYLIB_API __declspec(dllimport) 
#else
#define MYLIB_API __declspec(dllexport) 
#endif
bool MYLIB_API test(const std::string& str);
#endif

bool MYLIB_API MyTest(const std::string& str)
{
    return (str == "Hi There");
}

Upvotes: 1

Views: 1305

Answers (3)

user3666197
user3666197

Reputation: 1

You have just experienced one of the MQL4 tricks,
the MQL4 string is not a string but a struct thus #import on MQL4 side will make MT4 to inject that, not matching your DLL C-side expectations and the access-violation error is straightforward, as your C-side code tried to access the MQL4 territories...

First rule to design API/DLL: READ the documentation very carefully.

Yes, one may object, that the MQL4 doc is somewhat tricky to follow, but thus more double the Rule#1, read the documentation very, very, very carefully as some important design facts are noted almost hidden in some not very predictable chapters or somewhere in explanations of ENUM tables, compiler directives, pragma-s side-notes et al.

Second rule: design API/DLL interface so as to allow smooth integration

MQL4 has changed the rules somewhere about Build 670+. Good news is, the MetaQuotes has announced, that there will be no further investment on their side into MT4 further developlments, so the MT4-side of the DLL/API integration will hopefully stop from further creeping.

Given your statement, that you design the DLL/API, try to design future-proof specification -- use block of uchar[]-s instead of "interpretations"-sensitive string, pass both inputs and outputs by-reference and return just some form of int aReturnCODE = myDLL_FUNC( byRefParA, byRefParB, byRefRESULT ); and your efforts will result in clean code, better portability among 3rd party language-wrappers and will also minimise your further maintenance costs.

Upvotes: 1

doron
doron

Reputation: 28932

If you do share a C++ string between a DLL and another executable, both need to have been compiled with the same tool-chain. This is because std::string is defined in header only. So, if the DLL and executable use different string headers, they may well be binary incompatible.

If you want to make sure that things do work with different tool-chains, stick to NULL terminated C strings.

Upvotes: 2

Walter
Walter

Reputation: 45454

Most likely, your code and the one you're linking against have been compiled with a different ABI for std::string, i.e. the string used by the library has a different memory layout (and sizeof) than the one you're compiling with.

I once ran into this problem when linking against the hdf5 library and using gcc. In this case, the problem could be solved by reverting to a previous ABI, as explained here.

However, the problem also occurred with clang, when such a solution was not available. Thus, to make this all working I had to avoid using std::string in any calls to the library (hdf5 in my case) that was compiled with the different ABI, and instead make do with the hdf5 interface using const char*.

Upvotes: 0

Related Questions