Errors, bugs, questions - page 1279

New comment
 

When getting the tick history with CopyTicks(), the ticks of the previous working session of the terminal are returned, which contradicts the description of the function:

MQL5: Добавлена функция работы с тиковой историей CopyTicks. Функция позволяет получить массив тиков, накопленных терминалом за текущую рабочую сессию. Глубина получаемых тиков ограничена последними 2 000.

Question to developers. Will it be fixed? And is it possible to make the terminal transfer the last N ticks from MQ server (or broker) when it will start, so that it wouldn't have to wait for the accumulated history? It's just unlikely that anyone needs a tick history for some unknown N ticks in the past. Servicedesk#1162481

 

I have the "new screenshots" checkbox removed in my privacy settings, i.e. there should be no posts in my feed when they are published.

My feed does indeed not contain this message. However, the message about publishing new screenshots is in my friends' newsfeeds.

ZS: if it should be so, then it turns out that this setting has nothing to do with privacy at all )

 
sanyooooook:

I have the "new screenshots" checkbox removed in my privacy settings, i.e. there should be no posts in my feed when they are published.

My feed does indeed not contain this message. However, the message about publishing new screenshots is in my friends' newsfeeds.

ZS: if it should be so, then it turns out that this setting has nothing to do with privacy at all )

Thanks for the message,

posts about your screenshots should not be in your friends feed. The error will be fixed shortly.

 
Opened four MT5 terminals, they started updating to b.1079. Loaded the update normally, went to reboot normally. Only half of them managed to get out of the reboot, and that was by accident.
The reason was this very update. Below is a graph of the process of updating one MT5 terminal with a trading system, swap file before and after the update.

When upgrading to b.1085 everything remained the same.

What did you have to do with the terminal to have one terminal fouled the swap file for 2 Gb?

There are no "heavy" indicators in the system. The most "heavy" one takes only 7 µsec to load, two, - 5, one, - 4, the others, - 1 µsec or less.

For comparison, indicator JMA from CodeBase requires 110 µsec on my computer, but it's not used in the system.


So the updated MT5 instantly buried my trading system, - impossible to work even in one terminal, - and I buried it accordingly.

When MT5 has a pool, a shop and a latrine in one bottle, it was bound to happen.

The monsterisation of good MT5 started a long time ago. When the amount of rubbish in previous versions of MT5 got close to 1 Gb, I got worried and concurrently switched the system completely to the MT4 platform. It turned out to be not in vain.

The system simultaneously analyzes 8 TFs, three of them can be seen on the chart. The leading trade signals of the system are generated on the basis of instrumental measurements of

supply/demand ratio, so they are objective.

Below - 5 MT4 terminals are opened simultaneously (for different currency pairs) with the same trading system and there are no problems, as seen so far.



 
s2101:
Opened four MT5 terminals, they started updating to b.1079. Loaded the update normally, went to reboot normally. Only half of them managed to get out of the reboot, and that was by accident.
The reason was this very update. The chart below shows the process of updating one MT5 terminal with a trading system, swap file before and after the update.

Why did you hide the physical memory from the screenshot but did not forget about the swap file?

Also, when addressing such an important question, you forgot to attach a screenshot from the processes section, where you can see both the actual memory consumption for each process and the number of threads running.

 

As far as I understood, MT5 1085 has a race condition for setting a comment (Comment).

The point is this - there is an indicator in a separate window with a code:

int OnInit(){
   Comment("AAAAAAAAAAAAAAAAAAAAAAAAA");
}

void OnDeinit(const int reason) {
   Comment("");
}

If we run 2 instances of the indicator on the same chart and switch the TF, what do we see inComment?
In 90% it will be "". (whether different queues in different threads with different priority to setComment from underOnInit andOnDeinit....)

 

Compilation error

template<typename T>
string ETS( T t ) { return ( typename( t ) == "int" ? "OK" : ::EnumToString( t ) ); }
enum ENUM {     ENUM__ };
void OnStart()
{
        ENUM i1 = ENUM__;       Print( ETS( i1 )); //нормально
        int  i2 = 0;            Print( ETS( i2 )); //ошибка компиляции
}
Why calculate ::EnumToString( int ) in the second case if the type is known at compile time ?
 
ALXIMIKS:

At 90% it will be "".

What was expected? One writes, the other erases.
 
A100:
What was expected? One writes, the other erases.
You forgot about the second writes.

There are two writes and two erases. They are most likely asynchronous.
The erase should be before the write, but alas it is not...
 

The compiler fails to detect the error (which it does - at least the second #endif is missing), resulting in failure to detect more significant errors

#property library
#define __MQL5
#ifdef  __MQL5
#ifndef __MQL5
#else
#else
#endif


1...127212731274127512761277127812791280128112821283128412851286...3189
New comment
Reason: