StringFind not working in the latest update. - page 2

New comment
 

I've found the root cause of dietcokes issue: (I've posted this on FF too as it was Hanover's library). This was due to StringSubstr


1. StringSubstr is changed. EOL flag is now -1 not 0 (OLD NEW)

2. NumberToStr is calling StringSubstr(str,start_pos,length) with a negative start_pos. When this happens new MQL4 lost the plot, I'm not 100% sure what old MQL4 does, I'm guessing forced a zero? I'd replace all calls to StringSubstr(a,b,c) with calls to StrSubstrOld(a,b,c)


string StringSubstrOld(string x,int a,int b=-1) {
    if (a < 0) a= 0; // Stop odd behaviour
    if (b<=0) b = -1; // new MQL4 EOL flag
    return StringSubstr(x,a,b);
}

I'd also change the following to take advantage of library functions: (or in the case of StringLeftTrim just call the library function StringLeftTrim directly)


string StringLeftTrim(string str)
{
    return StringTrimLeft(str);
}

string StringTrim(string str)
{
    return StringTrimLeft(StringTrimRight(str));
}

string StringUpper(string str)
{
    StringToUpper(str);
    return str;
}

There is still a double -ve appearing in the test. Not sure why...

 

PS This is really really shoddy work from MQ. How many developer hours will be wasted with things like this. The compiler should either flag or force the same behaviour if #property strict is not present.

We should not be expected to trawl through debuggers and documentation for small differences like this.

MQ need to either:

1. Make absence of "#property strict" 100% back compatible...

2. Add compiler warning if function has changed

3. Produce a comprehensive migration guide.

 
ydrol:

There is a lot of code there, why not make the smallest test case possible?

ps we now have standard functions StringTrimLeft, StringTrimRight, StringToUpper, StringToLower


1) There is a lot of code there, I agree. However, all of it is simple string manipulation. there are no arrays, no dll imports, no nothing which should cause a corrupt output. I don't know which bit of it is failing so I don't know what test case to design.

2) the fact that there are now built-in functions that do the job of the bespoke ones I attached, is somewhat irrelevant, given that the ones I used work in earlier builds.


I'd like to know if the script I attached display's non-corrupted output on other build 600 systes.

Edit: I've just seen your update. Ridiculous from metaquotes.

 
ydrol:

PS This is really really shoddy work from MQ. How many developer hours will be wasted with things like this. The compiler should either flag or force the same behaviour if #property strict is not present.

We should not be expected to trawl through debuggers and documentation for small differences like this.

MQ need to either:

1. Make lack of property strict 100% back compatible...

2. Add compiler warning if function has changed

3. Produce a comprehensive migration guide.



Nice piece of detective work. well done.
 
No prob! I thought it was worth investigating because it would have implications for everyone trying to migrate code :)
 
ydrol:
No prob! I thought it was worth investigating because it would have implications for everyone trying to migrate code :)

It goes on...

The mql5 StringTrim functions all return an int


StringToUpper and StringToLower return an equally ridiculaous bool

 
dietcoke:

It goes on...

The mql5 StringTrim functions all return an int


StringToUpper and StringToLower return an equally ridiculaous bool

You are off-topic. There is nothing ridiculous in my opinion, the returned bool indicated you success or error, it's good practice in programming to check for errors.
 
angevoyageur:
You are off-topic. There is nothing ridiculous in my opinion, the returned bool indicated you success or error, it's good practice in programming to check for errors.

Does off-topic mean something different in French?

I personally think you are right about this one and dietcoke is wrong, and it makes sense for StringTrim to return an int and for StringToUpper to return a bool, but how is he/she off-topic?

 
gchrmt4:

Does off-topic mean something different in French?

I personally think you are right about this one and dietcoke is wrong, and it makes sense for StringTrim to return an int and for StringToUpper to return a bool, but how is he/she off-topic?

The topic is StringFind not working in the latest update. Talking about others StringXXX functions, and not even to ask a question or report a problem is off-topic, not ? Please correct my English if it's wrong.


 
angevoyageur:
The topic is StringFind not working in the latest update. Talking about others StringXXX functions, and not even to ask a question or report a problem is off-topic, not ? Please correct my English if it's wrong.




angevoyageur:
You are off-topic. There is nothing ridiculous in my opinion, the returned bool indicated you success or error, it's good practice in programming to check for errors.


In mql4 stringtrimleft and right return a string now they don't, so as an MQL4 programmer, when I code

outstr = StringTrimLeft(outstr);


I get a result I don't expect

There are no errors, no warnings because it is correct code and the change is completely undocumented. Thats my problem. As far as I can see there is nothing on the metquotes site which tells me about this. This is what I've read about changes to strings:

"Strings are now presented in Unicode format, though they were in ANSI format (single byte ones) before. That should be considered if the program uses DLLs and passes string variables to them. When calling Windows API functions, Unicode versions of these functions should be used."

It should not be down to me to discover the changes that have been introduced. Why is there no comprehensive documentation?

123
New comment
Reason: