Errors, bugs, questions - page 2579

 
Roman:

How is it an empty string? When the string comes from a socket, in other variants though it's crooked, but it's not empty.
I'm not saying your variant is wrong, but in your variant you use an array of string.
In my case it's a pointer.

The socket function returns a pointer to const wchar_t *
. That's why I blame the bug on mql, because I tried so many C functions and hardcore +1 or +2.
It just won't work.

Write lines after memcpy() in parallel to file, if mql is guilty (there is some wrapper on top of calls with copying arguments), then file won't be empty, probably.

HH: well, just in case - the library function in µl is declared with a link, right? void fn(string & s)?
 
Vict:

Write lines after memcpy() in parallel to the file, if µl is to blame (there's some wrapper on top of calls with copying arguments), the file won't be empty, I guess.

HH: well, just in case - in µl library function is declared with reference ? void fn(string & s)?

All strings I display either on the chart in the comment, or in the print terminal, when the string arrives it is immediately visible, in the comment you can see whether it is crooked or not.
When there are big time lapses, the string rarely appears on the chart, and there are holes in the print.
The doubt that no string is coming in from the socket is gone, tick data comes in at millisecond rate.
From socket getData() took in a pointer variable, from pointer variable I copy directly to mql, no wrappers.
Yes declared by feng shui ))

#import "ExampleDll.dll"
   void Func(string task, string & out);
#import
In general, there is an issue with mql string. Tried and tested many variants.
The string from the socket comes with terminal null, and the most reliable check function
wcscpy(out, data);
или
wcsncpy(out, data, wcslen(data));  //wcslen(data)+1
shows the problem on mql.

In general, I will use sizeof(wichar_t*) for now and see the behavior.
But probably to be safe from changes from MQ, I'll really write strings on arrays.
 
But I guess to be safe from changes from MQ, I'll probably really write the strings on arrays.

Golden words. Of course, I'd like to use string, but since there's no standard that describes its implementation and/or behavior when passing it into a dll, it's pure ub. And so, string in short[] and you can safely pass the array; the only thing is the overhead of creating and copying an array.

PS. Still, I think the problem is not in mql, but in your code. All tests passed normally, and there's nothing logically wrong with string, string is a trivial wrapper over wchar_t *, or rather over wstring, that could screw it up.

 
Vladimir Simakov:

Good words. Of course, we'd like to use string, but since there is no standard that describes its implementation and/or transfer behavior in dll, it's pure ub. And so, string in short[] and you can safely pass the array; the only thing is the overhead of creating and copying an array.

PS. Still, I think the problem is not in mql, but in your code. All tests passed normally, and there's nothing logically wrong with string, string is a trivial wrapper over wchar_t *, or rather over wstring, that could screw it up.

I had my doubts about the lib either, I don't rule anything out as a possible reason.
But I converted the received string from the socket to ASCII codes, you can see that the string is correct.
Next comes a simple copy,
mql doesn't accept the string pointer correctly.

Files:
1.PNG  32 kb
 
Roman:

All lines I display either on the chart in the comment, or in the print terminal, when the line comes it is immediately visible in the comment shows it is crooked or not.
When there are big time lags, the line seldom appears on the chart, while there are holes in the print.
The doubt that the string from the socket is not coming in, the tick data is coming in at millisecond rate.
From socket getData() taken to pointer variable, from pointer variable I copy immediately to mql, no wrappers.
Yes declared by feng shui ))

Anyway, any problems with mql string. Tried and tested many variants.
The string from the socket comes with terminal null, and the most reliable check function
shows the problem on mql.

In general, I'll use sizeof(wichar_t*) for now and see the behavior.
But probably to be safe from changes from MQ, I'll really write strings on arrays.

Writing to the file - I meant on the dll side, if the file is written, but does not get into the μl, it is already a weighty argument with a bug claim, maybe corrected.

And there is a wrapper without your wish, MQ hide code/addresses from the outside world, everything does not go directly.

 
Vict:

Writing to file - I meant on dll side, if it writes to file, but does not get to mql, then it is already a strong argument with bug claim, maybe corrected.

And there is a wrapper without your wish, MQs hide code/addresses from the outside world, everything does not go directly.

Written the received strings to a file.
Since the socket function returns a pointer to a string, a pointer to the string is written to the file, and then this pointer is copied to mql.
Using the function

wcscpy(out,  data);

The length of the resulting string is 164, the mql is allocated 200.

StringInit(out, 200, 32);

The copied string received in mql is of equal length, however, there are some gaps in copying.
In mql script, while loop is looped with Sleep(1)

Files:
458.PNG  71 kb
 
And if you use the function
wcsncpy(out, data, wcslen(data));
Then there are no gaps, but the copied lines are not straight, there are extra characters at the end of the line.
Addingwcslen(data)+1 doesn'thelp.

Bottom line, of all the pages I'm writing here.
mql string does not correctly accept from dll, copied pointer to string const wchar_t*
Files:
w6b.PNG  74 kb
qjv2.PNG  73 kb
09i3.PNG  6 kb
 
Roman:

Correct, I allocate a buffer for string out, and initialize it with spaces.
Then I pass this string(pointer) to dll.

In dll wchar_t* data is copied into out, i.e. is also a pointer. Logically there should be no problems.
As I understand it according to the help, the StringInit function should set the string length.
But I still have some problems withthe StringInit function itself; I specified the string length and got weird when I pointed to the pointer size.
I don't understand what manual string length transfer you mean.

And if you use sizeof(wchar_t) without a pointer, the string starts floating around with extra characters, which causes problems with parsing and leakage.
To pass strings into dll I used Renat's example, from his article on how to write a dll.
But for some reason, if I pass it without sizeof(wchar_t) pointer, the string floats, while with sizeof(wchar_t*) pointer there is no problem.
It seems logical to me, I'm copying a string as a pointer, the size should be passed as a pointer, not as a type.

Sometimes you do it right - it doesn't work.

Doing it wrong - it seems to work.

In such cases, you have to do it right and look for an error elsewhere.

 
Roman:

Wrote the resulting string into file.
Since the socket function returns a pointer to a string, a pointer to the string is written to the file and then this pointer is copied to mql.
Using the function

The length of the resulting string is 164, the mql is allocated 200.

The copied string received in mql is of equal length, however there are some gaps in copying.
In mql script, while loop is looped with Sleep(1)

1. In MQL a string, not a pointer, is copied.

2. You selected a 200 character string in MQL. Then you copied 164 characters into it. After that, look at the size of the line in MQL. It remained 200.

 
Koldun Zloy:

Sometimes you do it right - it doesn't work.

Doing it wrong - it seems to work.

In such cases, you have to do the right thing and look for the error elsewhere.

So to get it right, I gave up memcpy, and used wcscpy or wcsncpy.
Result, post above.

Reason: