Errors, bugs, questions - page 3128

[Alain Verleyen]

Nikolai Semko # :

Ah, doesn't this theme in the debug work anymore?
Sad :(( Was very useful in my work

Reported over 4 months ago. No one cares.

[Vladimir Pastushak]

Vladimir Pastushak #:

Finance: A non-financial issue

Open,Started: 2021.09.02 10:45,#3182963

Hello! Activated the ticket as the "New Application" button is not working.

Reason for the request: The description of the last 4 languages, Korean, Italian, French, Turkish is not saved in the signals.

Raising it as it is not working.

[fxsaber]

Need a script that will run the script/service on all running MT4/5 terminals. Can you suggest PostMessage parameters.

[Andrey Khatimlianskii]

fxsaber #:
Need a script that will run the script/service on all running MT4/5 Terminals. Can you tell me the PostMessage parameters.

I would make a service that waits for the command file to appear in the common folder. Well, and a script to create such a command.

[fxsaber]

Andrey Khatimlianskii #:

I would make a service that waits for the command file to appear in the common folder. Well, and a script to create such a command.

Very crutchy, and MT4 is still relevant.

[x572intraday]

I don't dare to call it a bug. So I'll just say that I've noticed one peculiarity of the if statement. I suspect this may be true for other languages as well.

if(a && Array[over_index]>val) {...}

If a turns out to be true, the check skips to Array[over_index] and here the terminal starts crashing through the'array out of range' part, which is absolutely fair. But if a turns out to be false, the terminal will not check for the Array[over_index] condition and hence for index redundancy, and if will skip further and the coder will not know that there is an array with a non-existing index in his program... or rather an existing but redundant one.

Maybe there should be a fix for it so that the check for 'array out of range' would be carried out to the very end of the if loop and the same message would be output? Or it will significantly reduce operator's speed?

[Alexey Viktorov]

x572intraday #:

I don't dare to call it a bug. So I'll just say that I've noticed one peculiarity of the if statement. I suspect this may apply to other languages as well.

If a turns out to be true, check skips to Array[over_index] and here the compiler starts crashing the'array out of range' part, which is quite true. But if a turns out to be false, the terminal will not check for the Array[over_index] condition and hence for index redundancy, and if will skip further and the coder will not know that there is an array with a non-existing index in his program... or rather an existing but redundant one.

Maybe there should be a fix for it so that the check for 'array out of range' would be carried out to the very end of the if loop and the same message would be output? Or it will significantly reduce speed of the operator?

In your case it is not so, because both conditions must be satisfied. But if you set

if(a || Array[over_index]>val) {...}

then, yes. If condition 'a' is fulfilled, the second condition will not be checked. This has been fought for for years, and now you suggest we go back to the last century...

[Vitaly Muzichenko]

x572intraday #:

I don't dare to call it a bug. So I'll just say that I've noticed one peculiarity of the if statement. I suspect this may apply to other languages as well.

If a turns out to be true, check skips to Array[over_index] and here the terminal starts crashing through the'array out of range' part, which is quite true. But if a turns out to be false, the terminal will not check for the Array[over_index] condition and hence for the redundancy of the index, and if will skip further and the coder will not know that there is an array with a non-existing index in his program... or rather an existing but redundant one.

Maybe there should be a fix for it so that the check for 'array out of range' would be carried out to the very end of the if loop and the same message would be output? Or it will significantly reduce speed of the operator?

If you change the behavior, normally written programs will simply "crash", while those not written will be difficult to write.

Read on, there is some description there

[Andrei Trukhanovich]

x572intraday #:

I don't dare to call it a bug.

This is normal behaviour everywhere. If you want the argument to be calculated all the time, calculate it before the if-

[Vitaly Muzichenko]

Alexey Viktorov #:

In your case this is not the case as both conditions must be met. But if you put this

then, yes. If condition 'a' is met, the second condition will not be checked. This has been fought for for years, and now you suggest we go back to the last century...

Check

// +--------
int start()
{
 if(false && Test()) { 
  Print("if Yes"); // Это никогда не напечатает
 }
}

// +--------
bool Test() {
 Print("Test"); // Это тоже, к ней не дошла очередь
 return(true);
}