Errors, bugs, questions - page 659

 
antt:
Which access point?
Cyprus.
 

The situation is as follows. For example, there are open positions on Friday. We set Stop Loss and Take Profit. Without waiting for the end of the trading session, we leave these positions, disable communication, and put the computer to sleep (Hibernate mode). We turn on the next day. The Internet connection is established. There is connection to the server. Saturday. The market is closed. We can see that the positions have been closed, some by Stop Loss and some by Take Profit. These deals can be seen in the History tab of the trading terminal:

We request the history of the last three trades:

   datetime Start=0;
//---
   if(!HistorySelect(Start,TimeCurrent())) // Загрузим историю сделок
     {
      Print("Ошибка при загрузке истории!"); return;
     }
   else
     {
      ulong ticket=0;
      datetime time=0;
      string symbol="",comment="";
      //---
      int total_deals=HistoryDealsTotal();
      //---
      for(int d=total_deals-1; d>=total_deals-3; d--)
        {
         if((ticket=HistoryDealGetTicket(d))>0) // Если сделка выбрана
           {
            symbol=HistoryDealGetString(ticket,DEAL_SYMBOL);
            comment=HistoryDealGetString(ticket,DEAL_COMMENT);
            time=(datetime)HistoryDealGetInteger(ticket,DEAL_TIME);
            //---
            Print("<-- symbol: ",symbol,"; comment: ",comment,"; time: ",time," -->");
           }
        }
     }

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:

#define Milliseconds_Ahead 200
//---
datetime TimeCurrentAhead()
  {
   return(TimeCurrent()+Milliseconds_Ahead);
  }
 

tol64:

...

P.S. I tried that too, it doesn't work:

Found a way out. In the Market Watch window you can see the exit time. That is, the last time when there was a connection to the server and the tick arrived (last tick time):

That is, in my case 18:43:30.

It turns out that still using this function...:

#define Milliseconds_Ahead 10000
//---
datetime TimeCurrentAhead()
  {
   return(TimeCurrent()+Milliseconds_Ahead);
  }

...you can solve the situation, but you have to make the request with a significant margin. Or you can do without this crutch and forget about it forever and use TimeLocal() function when making history requests, if it is used in real-time. In the tester, use TimeCurrent() or TimeCurrentAhead(). Something like this:

datetime ChoiceTimeFunction()
  {
   if(NotTest())
     { return(TimeLocal()); }
   else
     { return(TimeCurrent()+Milliseconds_Ahead); }
//---
   return(TimeLocal());
  }

Then this point should be covered in the help or something...

 

It is possible to recover deleted graphics in the terminal:

Open deleted

Open a submenu of deleted charts to restore. Deleted charts are saved if "Save deleted windows for reopening" is checked in the terminal settings. All templates of deleted charts are savedin the/Profiles/Deleteddirectory. When this command is executed, these templates are accessed and the corresponding chart is opened. Any of the deleted chart templates can be deleted using the corresponding command in this menu.

The situation is as follows. The Expert Advisor hangs on the chart and its information panels are displayed. In the OnDeinit() function, I specify that if the chart is closed, the information panels should be deleted, in order to save the template for restoring without objects. I close the chart. Using the Open Deleted option, I restore it, but it is restored with objects, and incorrectly (some are there, some are not). The Expert Advisor restores everything after initialization. It leaves an unpleasant residue and a feeling of shoddily done work. I estimate it from the Expert Advisor users' viewpoint, not that of the terminal. At any other deinitialization events all works correctly. I understand that template saving happens before deinitialization, because during deinitialization the objects are still deleted, but they have time to be saved in the template.

 

Here's the problem...

As far as I know, the terminal "notices" additional history on the server and sort of "gaps" in the local history and starts frantically pumping it in automatically to fill those gaps. This is all great, of course, but...

There is such a phenomenon as non-standard timeframes, the history of which seems to be not downloaded from anywhere but automatically built "in the mind" by the terminal. And here is what I have noticed. If everything is all right with noting the "gaps" in the history and autodownloading, the situation with reconstruction of the built and then damaged (either on the disk or in the memory) history of non-standard timeframes is really out of the question. Well, my terminal has downloaded all the history, then I have jumped over all timeframes and discovered that someone has stolen an entire recent history segment on H2 and H3 which the terminal has neither downloaded nor reconstructed locally. It was helped to unload the terminal and manually delete files of appropriate timeframes from C:\Program Files\MetaTrader 5\Bases\MetaQuotes-Demo\history\NZDUSD\cache with further launch of the terminal, move toH2 and H3 and wait until it rebuilds its history from scratch correctly.

Obviously, we would like to have a smarter terminal that would "feel" these bitten segments at any timeframe, including non-standard ones, and immediately try to fill them up.

---------------

Addendum: although, to be honest, the terminal does not see anything at all. I have been sitting for a year with a curve of history of minutes, which actually starts with MetaQuotes from 1999, while my timeframe was in 2009 for some reason - and what? Where are those automatic downloads? I had enough space to download them, but there were no downloads until today, until I uninstalled and reinstalled everything (I did the same before, but it had no effect). Of course, it's not even about resuming, it's about full downloading of all the history from scratch by the terminal. Well, at least that's the bread and butter.

In this regard, I want to give all MQL programmers, who debug their programs and rely on the consumption of their software products by other users, an important warning: be alert for the availability of the history, for which your product is calculated: during testing with incomplete or substituted by the higher timeframe history, the processing speed will be good, but it may happen that you or your programs users will roar from 100% CPU load on modern computers and "endless" error messages.

 

'f0_34' - comparison expression expected

Can you tell me what this warning means?

 

Again, a mistake of this kind has surfaced:

The problem area has been identified. Detailed description in Service Desk.

//---

P.S. Completed an existing request, with a similar problem once solved. After a while I saw a notification near my profile. I logged into Service Desk and the request completely disappeared. Do I have to do it all over again? )))

 
tol64:

Again, a mistake of this kind has surfaced:

The problem area has been identified. Detailed description in Service Desk.

//---

P.S. Completed an existing request, with a similar problem once solved. After a while I saw a notification near my profile. I logged into Service Desk and the request completely disappeared. Do I have to do it all over again? )))

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

We will definitely take care of it.

 
MetaQuotes:

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

We'll be sure to look into it.

Please sort it out, as some of my applications have also gone away altogether. neither in the open nor in the closed ones.
 
MetaQuotes:

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

We'll be sure to look into it.

Thank you. Looking forward to it as there are clarifications. The problem is not just starting to show up where I indicated. The area of occurrence is now ubiquitous.
Reason: