iClose/iOpen 시계열 등에 대한 액세스 작업 시 MQL5 버그 - 페이지 8

새 코멘트
 
Slava :

결정하려고 할 수 있습니다.

분이면 마지막 막대의 시간을 TimeCurrent()와 비교할 수 있습니다. M1이 아닌 경우 iTime(_Symbol, PERIOD_M1,0 )을 요청하고 TimeCurrent()와 비교할 수 있습니다.

마지막 막대의 종가와 입찰가 또는 종가(상품에 따라 다름)를 비교할 수 있습니다. 현재 심볼의 SymbolInfoTick을 즉시 요청할 수 있습니다. 거기에는 입찰과 마지막 외에도 틱 시간도 있습니다

감사합니다. 문제가 발생한 경우 버그를 찾는 위치와 방법에 대해 최소한 일부 정보가 표시되었습니다.

하지만 우리는 여전히 상태를 확인하기 위해 내장 함수가 필요하거나 누락된 틱 수를 저장하는 int _LastError와 같은 플래그가 더 좋을 것이라고 생각합니다. 복잡한 계산을 위해 OnCalculate()를 호출할 때 편리할 것입니다. , 기호 스트림을 해제하기 위해 즉시 반환

 
Igor Makanu :

감사합니다. 문제가 발생한 경우 버그를 찾는 위치와 방법에 대해 최소한 일부 정보가 표시되었습니다.

하지만 우리는 여전히 상태를 확인하기 위해 내장 함수가 필요하거나 누락된 틱 수를 저장하는 int _LastError와 같은 플래그가 더 좋을 것이라고 생각합니다. 복잡한 계산을 위해 OnCalculate()를 호출할 때 편리할 것입니다. , 기호 스트림을 해제하기 위해 즉시 반환

생각, 숙고 .... 이것은 선택 사항이 아닙니다. 몇 개의 틱이 건너뛰었다는 사실을 알 수 있는 것은 무엇입니까? 어쨌든 이 틱을 수집하고 처리해야 합니다. 즉, 누락된 틱을 처리할 시간이 없었다면 다음 번에 제 시간에 처리할 수 있기를 갑자기 희망하는 이유가 무엇입니까? - 악순환이다.

나는 이것에 대해 생각했습니다 ... 아마도 개발자는 예외와 유사한 것을 도입해야합니까? 새 틱의 도착은 모든 작업, 현재 표시기의 계산을 중단해야 하며, 해당 시점에 새 틱이 도착하면 모든 표준 MQL 함수가 실행될 때 오류를 반환해야 합니다... 그러면 표시기로 작업하는 것이 이해하기 쉽고 편리해집니다. 예측 가능합니다. 다른 유형의 프로그램(스크립트, 어드바이저)의 경우 이것은 실제로 필요하지 않습니다.

관련성에 대한 표시기의 모든 종류의 진드기 검사는 가볍게 말해서 옵션이 아닙니다.

 

#property tester_everytick_calculate 플래그를 포함하지 않는 표시기에 대한 아이디어가 있습니다. 각 틱 이 아니라 일괄 틱 수신을 기반으로 계산 모드를 활성화하는 것입니다.

이것은 브레이크 표시기의 문제를 근본적으로 해결하는 동시에 일부 표시기에 대한 각 틱의 보장된 처리 가능성을 유지합니다.

 
Renat Fatkhullin :

#property tester_everytick_calculate 플래그를 포함하지 않는 표시기에 대한 아이디어가 있습니다. 각 틱 이 아니라 일괄 틱 수신을 기반으로 계산 모드를 활성화하는 것입니다.

이것은 브레이크 표시기의 문제를 근본적으로 해결하는 동시에 일부 표시기에 대한 각 틱의 보장된 처리 가능성을 유지합니다.

즉, 그러한 디자인으로 매우 빠른 표시기를 가질 수 있습니까?

 //+-------------------------------------------+
int OnInit () 
  {
   EventSetMillisecondTimer ( 200 );
//-
   return ( INIT_SUCCEEDED );
 }

//+-------------------------------------------+
int OnCalculate ( const int rates_total,
                 const int prev_calculated,
                 const datetime & time[],
                 const double & open[],
                 const double & high[],
                 const double & low[],
                 const double & close[],
                 const long & tick_volume[],
                 const long & volume[],
                 const int & spread[])
 {
  // Здесь ничего не делаем, нам не нужен в данном случае OnCalculate
   return (rates_total);
 }

//+-------------------------------------------+
void OnTimer ()
 {
   // Здесь расчёты, и вывод информации на график в виде графических объектов
 }

그렇다면 이것은 좋은 소식입니다!

 
Renat Fatkhullin :

#property tester_everytick_calculate 플래그를 포함하지 않는 표시기에 대한 아이디어가 있습니다. 각 틱 이 아니라 일괄 틱 수신을 기반으로 계산 모드를 활성화하는 것입니다.

이것은 브레이크 표시기의 문제를 근본적으로 해결하는 동시에 일부 표시기에 대한 각 틱의 보장된 처리 가능성을 유지합니다.

좋은 소식!

 
Renat Fatkhullin :

#property tester_everytick_calculate 플래그를 포함하지 않는 표시기에 대한 아이디어가 있습니다. 각 틱 이 아니라 일괄 틱 수신을 기반으로 계산 모드를 활성화하는 것입니다.

이것은 브레이크 표시기의 문제를 근본적으로 해결하는 동시에 일부 표시기에 대한 각 틱의 보장된 처리 가능성을 유지합니다.

좋은 생각!

기본적으로 #property 없이 작동하는 것이 바람직합니다.

다른 사람이 필요하면 #property를 넣으십시오.

 
일괄적으로 틱을 받는 것은 실시간이 필요하지 않은 경우 좋은 해결책이며 아마도 빈혈 솔루션일 것입니다.

그러나 모든 틱마다 실시간으로 또 다른 클래스의 작업이 있습니다. 여기에서 그는 다음 틱이 도착하기 전에 틱이 도착한 후 계산을 할 수 있었는지 여부와 거래 결정이 더 이상 관련이 없습니다(세 번째는 없음). 따라서 내가 올바르게 보는 한 가지가 있습니다. 새 틱이 도착하면 모든 현재 계산이 중단되고 오류가 반환됩니다. 그렇지 않으면 실시간을 잊어버릴 수 있습니다. 오늘날, 틱은 날이 갈수록 점점 빨라지고 있고, 앞으로 더 있을지 여부에 대해서는 내기를 해야 합니다. 현재로서는 문제 없이 제시간에 모든 틱을 예외 없이 처리하는 것이 이미 비현실적이라는 사실은 말할 것도 없습니다. 브레이크.

 
_o0O :
일괄적으로 틱을 받는 것은 실시간이 필요하지 않은 경우 좋은 해결책이며 아마도 빈혈 솔루션일 것입니다.

그러나 모든 틱마다 실시간으로 또 다른 클래스의 작업이 있습니다. 여기에서 그는 다음 틱이 도착하기 전에 틱이 도착한 후 계산을 할 수 있었는지 여부와 거래 결정이 더 이상 관련이 없습니다(세 번째는 없음). 따라서 내가 올바르게 보는 한 가지만 있습니다. 새 틱이 도착하면 모든 현재 계산이 중단되고 오류가 반환됩니다. 그렇지 않으면 실시간을 잊어버릴 수 있습니다. 오늘날, 틱은 날이 갈수록 점점 더 빠르게 뱉어지고 있고, 더 있을지 여부는 미래에 베팅해야 합니다. 현재로서는 모든 틱을 문제 없이 제시간에 예외 없이 처리하는 것이 이미 비현실적이라는 사실은 말할 것도 없습니다. 브레이크.

지표 EA의 많은 부분이 닫힌 막대와 함께 작동하므로[1] 눈금을 건너뛰는 것은 문제가 되지 않습니다. 눈금으로 작업하는 지표의 경우에는 사실이지만, 그 수가 많지 않으므로 " #property tester_everytick_calculate "를 선택할 수 있습니다.

그리고 다시 슈퍼 틱이 필요한 경우 이를 위한 표시기가 필요하지 않으며 이 모든 것이 어드바이저 코드에 작성될 수 있습니다. 따라서 각 틱을 위해 전체 지표 작업을 늦추는 것은 합리적이지 않습니다.

" #property tester_everytick_calculate " 대기 중

 
Vitaly Muzichenko :

표시기 EA의 많은 부분이 닫힌 막대와 함께 작동하므로[1] 눈금을 건너뛰는 것은 문제가 되지 않습니다. 눈금으로 작동하는 표시기의 경우에도 마찬가지이지만, 그 수가 많지 않으므로 " #property tester_everytick_calculate "를 선택하기만 하면 됩니다.

그리고 다시 슈퍼 틱이 필요한 경우 이를 위한 표시기가 필요하지 않으며 이 모든 것이 어드바이저 코드에 작성될 수 있습니다. 따라서 각 틱을 위해 전체 지표 작업을 늦추는 것은 합리적이지 않습니다.

" #property tester_everytick_calculate " 대기 중


좋아, 그리고 당신이 말한 것이 내 말과 어떻게 일치하지 않았습니까?
 
누군가 유용할 수도 있습니다. 다중 통화 표시기 가 있으므로 초기화 블록에서 주요 용량 계산을 수행하고 oncalculate만 그립니다. 사실, 이것은 지표 라인 자체에 복잡한 계산이 포함되어 있지 않은 상황에서 탈출구입니다. 제 경우에는 포트폴리오 행동의 그래프를 표시하는 포트폴리오 지표입니다.
12345678910
새 코멘트