오류, 버그, 질문 - 페이지 2179

새 코멘트
 
Nikolai Semko :

아니요, 여기에 다운로드가 없습니다.

시작 막대가 0이 아니라 막대가 50개라고 하면 모든 것이 정상입니다. 곧.

그리고 30바를 포함하면 멈춥니다. 그리고 아니오 후.

스토퍼드 버그!

이걸로 해봐:

 //+------------------------------------------------------------------+
//| Возвращает смещение бара по времени                              |
//| https://www.mql5.com/ru/code/1864                                |
//+------------------------------------------------------------------+
int iBarShift ( const string symbol_name, const ENUM_TIMEFRAMES timeframe, const datetime time, bool exact= false )
  {
   datetime last_bar;
   if (! SeriesInfoInteger (symbol_name,timeframe, SERIES_LASTBAR_DATE ,last_bar))
     {
       datetime array[ 1 ];
       if ( CopyTime (symbol_name,timeframe, 0 , 1 ,array)== 1 )
         last_bar=array[ 0 ];
       else
         return WRONG_VALUE ;
     }
   if (time>last_bar)
       return ( 0 );
   int shift= Bars (symbol_name,timeframe,time,last_bar);
   datetime array[ 1 ];
   if ( CopyTime (symbol_name,timeframe,time, 1 ,array)== 1 )
       return (array[ 0 ]==time ? shift- 1 : exact && time>array[ 0 ]+ PeriodSeconds (timeframe) ? WRONG_VALUE : shift);
   return WRONG_VALUE ;
  }
//+------------------------------------------------------------------+
 
Artyom Trishkin :

이걸로 해봐:

그리고 iBarShift는 어디에 있습니까?

이제 우리는 표준 막대 기능 의 버그에 대해 이야기하고 있습니다.

 
Nikolai Semko :

그리고 iBarShift는 어디에 있습니까?

이제 우리는 표준 막대 기능 의 버그에 대해 이야기하고 있습니다.

이 함수는 Bars()도 사용합니다. iBarShift()의 아날로그와 함께 모든 것이 시작되었습니다.

 
Artyom Trishkin :

이 함수는 Bars()도 사용합니다. iBarShift()의 아날로그와 함께 모든 것이 시작되었습니다.

예, 물론 iBarShift의 아날로그를 사용하면 이 문제가 드러났습니다.

제공한 iBarShift 기능을 사용하면 이 버그가 잡히지 않습니다. 왜냐하면 하나의 TF만 사용되며,

그리고 이 버그 는 CopyTime 및 Bars 기능에서 다른 시간대를 사용할 때 발생합니다.

그러나 Bar는 언제든지 잘 작동해야 합니다. 그러나 내 예는 iBar가 수십 초 동안 멈추는 특별한 경우가 있음을 보여줍니다. 그리고 로딩 히스토리는 그것과 아무 관련이 없습니다.

 
Nikolai Semko :

예, 물론 iBarShift의 아날로그를 사용하면 이 문제가 드러났습니다.

제공한 iBarShift 기능을 사용하면 이 버그가 잡히지 않습니다. 왜냐하면 하나의 TF만 사용되며,

그리고 이 버그 는 CopyTime 및 Bars 기능에서 다른 시간대를 사용할 때 발생합니다.

그러나 Bar는 언제든지 잘 작동해야 합니다. 그러나 내 예는 iBar가 수십 초 동안 멈추는 특별한 경우가 있음을 보여줍니다. 그리고 로딩 히스토리는 그것과 아무 관련이 없습니다.

아마도 이것은 기록 로드 때문일 것입니다.

 
Nikolai Semko :

예, 물론 iBarShift의 아날로그를 사용하면 이 문제가 드러났습니다.

제공한 iBarShift 기능을 사용하면 이 버그가 잡히지 않습니다. 왜냐하면 단 하나의 TF만 사용됩니다.

그리고 이 버그 는 CopyTime 및 Bars 기능에서 다른 시간대를 사용할 때 발생합니다.

그러나 Bar는 언제든지 잘 작동해야 합니다. 그러나 내 예는 iBar가 수십 초 동안 멈추는 특별한 경우가 있음을 보여줍니다. 그리고 로딩 히스토리는 그것과 아무 관련이 없습니다.

요청한 범위에 막대가 없는 상태에서 주기적 동기화를 시도한 것 같습니다. 막대가 "정상적으로 작동"하도록 최선을 다한 다음 시간 초과 또는 동기화 시도 횟수로 포기합니다.

이러한 경우에 Bars를 호출하지 않도록 값 확인을 직접 수행해야 합니다.

 
Vitaly Muzichenko :

아마도 이것은 기록 로드 때문일 것입니다.

동의하지 않는다. 그러면 22초 동안 다시 다운로드되지 않습니다. 또한 모든 TF에 대한 내 전체 기록에는 특수 표시기가 포함되어 있습니다.

로딩 중이라면 처음 31개 막대는 로딩이 필요하고 다음 막대는 로딩이 필요하지 않다는 것을 설명하는 방법.

 
Nikolai Semko :

로딩 중이라면 처음 31개 막대는 로딩이 필요하고 다음 막대는 로딩이 필요하지 않다는 것을 설명하는 방법.

문서에서: 주어진 날짜 범위에 있는 막대의 수를 요청할 때 이 범위에 열리는 시간의 막대만 고려됩니다.

따라서 Bars() 사전 이미지는 0을 반환하며 이는 히스토리가 없는 것으로 해석되며 스크립트의 경우 ::Bars()는 이전 메시지에서 올바르게 언급했듯이 시간 초과 또는 실패한 횟수로 끝납니다. 시도.

 
Kirill Belousov :

요청한 범위에 막대가 없는 상태에서 주기적 동기화를 시도한 것 같습니다. 막대가 "정상적으로 작동"하도록 최선을 다한 다음 시간 초과 또는 동기화 시도 횟수로 포기합니다.

이러한 경우에 Bars를 호출하지 않도록 값 확인을 직접 수행해야 합니다.

꽤 가능합니다.
그러나 많은 옵션이 있습니다.

바는 매우 중요한 기능으로, 바 없이는 하기 어렵습니다. 더 정확하게 말하면, 얻을 수 있지만 자원 낭비가 증가합니다.

완벽하게 작동해야 합니다.

 
A100 :

문서에서: 주어진 날짜 범위에 있는 막대의 수를 요청할 때 이 범위에 열리는 시간의 막대만 고려됩니다.

따라서 Bars()의 사전 이미지는 0을 반환하며 이는 기록이 없는 것으로 해석되고 이전 메시지에서 올바르게 언급된 대로 스크립트는 시간 초과 또는 실패한 시도 횟수로 종료됩니다.

제로인 것은 분명합니다.

그리고 무엇 - 주어진 기간에 0 막대가 있다고 결정하는 것이 정상적인 22초입니까?

Bars의 내부 구현에서 명백한 알고리즘 버그입니다.

아마도 이 문제에 대해 서비스 데스크에 신청서를 제출해야 할 것입니다. 그렇지 않으면 주말이 다가오고 이 주제가 월요일까지 사라질 수 있습니다.

1...217221732174217521762177217821792180218121822183218421852186...3184
새 코멘트