Errors, bugs, questions - page 660

 
tol64:

Ask for the history of the last three transactions:

And we see that the history does not match. That is, we can see it in the terminal, but we cannot get it programmatically.

//---

Is it a bug or so it was designed and now you can get these deals programmatically only when the market opens?

P.S. I also tried this way, it does not help:

Instead ofTimeCurrent(), use TimeTradeServer() when selecting history.
Документация по MQL5: Дата и время / TimeTradeServer
Документация по MQL5: Дата и время / TimeTradeServer
  • www.mql5.com
Дата и время / TimeTradeServer - Документация по MQL5
 
Valmars:
Use TimeTradeServer() instead ofTimeCurrent() when selecting history.
Thank you Valery. Yes, indeed, in some cases, TimeLocal() may show wrong result depending on what timezone we are in. That's why TimeTradeServer() is the most accurate variant for requesting the trade history.
 
tol64:. Therefore TimeTradeServer() is the most accurate option for requesting the history of trades.
We only need to synchronise computer time in time, otherwise we might also lose trades.
 
Valmars:
We only need to synchronise computer time in time, otherwise we might also lose trades.

Do you mean this? :

I haven't figured out yet, to be honest, in what other case you can get not the whole history of trades...

 

Can you tell me what this message in the logbook means?

This only happened once and could not be reproduced again.

 

I have two questions at once.

The latest x32 build is installed. It's been on for almost two weeks now. Problems started yesterday or the day before yesterday. That is, the same build didn't malfunction before that, but it started suddenly, didn't it? The indicator hasn't been modified for a long time, either. It turns out it's not the problem either. Then what is it? When bouncing from timeframe to timeframe in some arbitrary cases the indicator appears incorrect in some of the timeframes, the chart literally slides down. When I leave and come back to this timeframe nothing is corrected, the erroneous calculations are fixed from the last time, as if they were stored somewhere in the cache. Sometimes restarting the terminal helps, but sometimes I have to manually clean the cache folder with a sick .hc-file of the corresponding timeframe. It never happened before. (By the way, to be sure I checked my disk for errors and defragmented it: only a slight speedup of system's performance, but the indicator does not perform the same calculations as before).

1. What can be the problem if both the build and the same indicator performed well before? Isn't it time to throw the computer on the scrap heap? Maybe the RAM has "dried up" and is breathing a big favor?

2. Why in the absence of a new history (i.e. ticks on weekends) when switching to nonstandard timeframes, to which I have already switched earlier and for which I have already built the appropriate .hc-files, does the same"Waiting for update" delay happen again as before? Even without any indicators, on a completely new chart!

 
x100intraday:

I have two questions at once.

The latest x32 build is installed. It's been on for almost two weeks now. Problems started yesterday or the day before yesterday. That is, the same build didn't malfunction before, but suddenly it started?

I have similarity with you, in my problem, in that before, since terminal update, error(Access violation read to 0x... ) didn't occur and started to show itself only now. At the weekend. ))
 
tol64:
I have a similarity with you in my problem, in that the error(Access violation read to 0x... ) has not occurred before, since the terminal was updated, and has only started to show itself now. At the weekend. ))
It must be Mason plotting. It's them who secretly control Forex...
 
x100intraday:
It must be the machinations of the Freemasons. They're the ones who secretly control Forex...
I don't know. )) Someone is controlling something everywhere. Everything is controlled and everything is controllable. Anything that cannot be controlled by one, can be controlled by another. It's natural and therefore normal. But that's not usually what we're talking about here. )))
 
MetaQuotes:

The application together with the comments are in place, but for some reason not visible in the profile.

We'll be sure to figure it out.

(chuckles) Okay. Well, that sounds about right now. :)

There's a negative number where there shouldn't be. Here's a script that reproduces the problem.

//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
   Print(FOrdType(-1));
  }
//---
string FOrdType(uint type)
  {
   string str="";
//---
   switch(type)
     {
      case ORDER_TYPE_BUY            : str="buy";             break;
      case ORDER_TYPE_SELL           : str="sell";            break;
      case ORDER_TYPE_BUY_LIMIT      : str="buy_limit";       break;
      case ORDER_TYPE_SELL_LIMIT     : str="sell_limit";      break;
      case ORDER_TYPE_BUY_STOP       : str="buy_stop";        break;
      case ORDER_TYPE_SELL_STOP      : str="sell_stop";       break;
      case ORDER_TYPE_BUY_STOP_LIMIT : str="buy_stop_limit";  break;
      case ORDER_TYPE_SELL_STOP_LIMIT: str="sell_stop_limit"; break;
      //---
      default: str="unknown_order_type: "+string(type); break;
     }
//---
   return(str);
  }

If you pass a negative number to a function that accepts an unsigned integer, voilà:

I think such things should be handled at compile time.

Reason: