How to fix serialization problems MQL4?

Question

Today I get problems with serialization in MQL4 .

I have a method, which I imported from a DLL :

In MQL4:

void insertQuery( int     id,
                  string  tableName,
                  double &values[4],
                  long   &times[3],
                  int     volume
                  );

In DLL:

__declspec(dllexport) void __stdcall insertQuery( int      id,
                                                  wchar_t *tableName,
                                                  double  *values,
                                                  long    *times,
                                                  int      volume
                                                  );

I tested it with this function calls in MQL4:

string a      = "bla";
double arr[4] = { 1.1, 1.3, 0.2, 0.9 };
long     A[3] = { 19991208, 19991308, 19992208 };
int volume    = 1;
insertQuery( idDB, a, arr, A, volume );

Inside of this method I collect this values to files.

C++ :

stringstream stream;
stream << " '";
for (int i = 0; i < 2; ++i) {
    stream << times[i] << "' , '";
}
stream << times[2] << ", ";

for (int i = 0; i < 4; ++i) {
    stream << values[i] << ", ";
}

stream << volume;
wstring table(tableName);
query.append("INSERT INTO ");
query.append(table.begin(), table.end());
query.append(" VALUES (");
query.append(stream.str());
query.append(" )");

std::ofstream out("C:\\Users\\alex\\Desktop\\text.txt");
out << query;
out.close();

But in output file I receive this record:

INSERT INTO bla VALUES ( '19991208' , '0' , '19991308, 1.1, 1.3, 0.2, 0.9, 1 )

So my question is : why I lose one long value in array when I receive my record in DLL ?

I tried a lot of ways to solve this problem ( I transfered two and three long values, etc ) and always I get a result that I lose second long value at serialization. Why?

Answer 1

The problem is cause because in MQL4, a long is an 8 bytes, while a long in C++ is a 4 bytes.

1. What you want is a long long in your C++ constructor.
2. Or you could also pass them as strings, then convert them into the appropriate type within your C++ code.

Answer 2

Well, be carefull, New- MQL4.56789 is not a c-compatible language

The first thing to test is to avoid passing MQL4 string into DLL calling interface, where really a c-lang string is expected.

Since old- MQL4 has been silently re-defined into a still-WIP-creeping syntax New- MQL4 ,
the MQL4 string is not a string , but a struct .

---

Root-cause [ isolation ]:

Having swallowed the shock about string/struct trouble, if you can, first try to test the MQL4/DLL interactions without passing any string to proof, that all other parameters, passed by value and addressed by-ref, do get their way to the hands of a DLL -function as you expect.

If this works as you wish, proceed to the next step:

How to pass the very data to expected string representation, then?

Let me share a dirty hack I used for passing data where DLL expects string -s

#import     "mql4TOOL.dll"
               ...
               int      mql4TOOL_msg_init_data ( int   &msg[],
                                                 uchar &data[],
                                                 int    size
                                                 );
               ...
#import
...
int                tool_msg_init_data ( int &msg[], string data, int size ) {  uchar dataChar[]; StringToCharArray( data, dataChar );
      return ( mql4TOOL_msg_init_data (      msg,          dataChar, size ) );
   }

Yes, dirty, but works for years and saved us many tens-of-man*years of re-engineering upon a maintained code-base with heavy dependence on the MQL4/DLL interfacing in massively distributed heterogeneous computing systems.

The last resort:

If all efforts went in vain, go low level, passing a uchar[] as needed, where you assemble some serialised representation in MQL4 and parse that on the opposite end, before processing the intended functionality.

Ugly?

Yes, might look like that,
but
keeps you focused on core-functionality and isolates you from any next shift of paradigm if not only strings cease to be strings et al.