Alexey Navoykov : 여기에서의 연설은 "구멍"의 식별에 대해 가지 않았습니다. 인간은 역사상 마지막 바를 얻어야 했다. 그리고 이것은 반드시 현재의 시간 막대일 필요는 없습니다.
그것은 iBarShift()에 관한 것이 아닙니다. 결국 SeriesInfoInteger()와 마찬가지로 iTime()과 동일한 오류를 보냅니다. 여기서 목발은 초기화 중에 얻은 시간을 비교하고 타이머에서 얻은 시간과 비교하는 것입니다. 이것이 우리가 터미널을 로드할 때 IBarShift()가 아닌 올바른 최신 데이터를 얻을 수 있게 해주었습니다.
네, 그리고 시간이 15시 00분 45초이고(예를 들어) 15시에 아직 바에 체크 표시가 없고, 마지막 매시간 바 의 영업시간 이 14시라면 모든 것이 정확하고, 제 생각에는. 그러나 시스템이 13:00을 반환하면 문제가 발생합니다.
이를 위해서는 터미널의 논리에 대한 이해가 필요합니다. 지표가 차트에 연결되면 OnInit()가 즉시 호출됩니다. 터미널이 실행되면 차트 창이 생성된 직후 차트에 인디케이터가 연결됩니다. 현재 단말은 서버에 요청조차 하지 않았다.
첫 번째 OnCalculate()는 로컬에서 사용 가능한 따옴표를 읽은 후 호출됩니다. 드문 경우지만 로컬에 아무것도 없는 경우가 있습니다. 그런 다음 Time[0]을 참조하는 표시기가 배열 범위를 벗어난 오류로 인해 날아갑니다. 따라서 iTime 기능 및 유사한 기능을 사용하는 것이 좋습니다.
두 번째 및 후속 OnCalculate()는 기록이 바뀌거나 틱이 실제로 도착할 때 발생합니다.
첫 번째 OnCalculate()는 로컬에서 사용 가능한 따옴표를 읽은 후 호출됩니다. 드문 경우지만 로컬에 아무것도 없는 경우가 있습니다. 그런 다음 Time[0]을 참조하는 표시기가 배열 범위를 벗어난 오류로 인해 날아갑니다. 따라서 iTime 기능 및 유사한 기능을 사용하는 것이 좋습니다.
우리는 아마도 OHLC의 준비가 MT4와 동일하지 않은 MQL5에 대해 이야기하고 있을 것입니다.
나는 오랫동안 템플릿에 따라 지표를 작성해 왔습니다.
intOnCalculate ( constint rates_total,
constint prev_calculated,
constdatetime &time[],
constdouble &open[],
constdouble &high[],
constdouble &low[],
constdouble &close[],
constlong &tick_volume[],
constlong &volume[],
constint &spread[])
{
//---int i,limit;
if (prev_calculated== 0 )
{
limit=rates_total- 1 ; //--- Первый вызов индикатора или смена таймфрейма или подгрузка данных из истории
}
else limit=rates_total-prev_calculated+ 1 ;
for (i=limit;i>= 0 ;i--) //---- Основной цикл расчета
{
}
return (rates_total);
}
MT4 에서 OHLC 어레이 를 넘어갈 때 "지표 충돌"이 발생한 적이 없으며 차트가 준비될 때까지 MT4가 처음으로 OnCalculate()를 시작하지 않을 것이라고 생각합니다. 확인하지만 prev_calculated== 0 , MT5에서는 작성한 대로 됩니다. OHLC 데이터가 준비되었는지 확인하는 추가 확인이 필요합니다.
귀하의 경우 OnInit() 직후에 하나 이상의 OnTimer 호출이 이루어집니다. 아직 OnCalculate() 이벤트가 없습니다.
이를 위해서는 터미널 논리에 대한 이해가 필요합니다. 지표가 차트에 연결되면 OnInit()가 즉시 호출됩니다. 터미널이 실행되면 차트 창이 생성된 직후 차트에 인디케이터가 연결됩니다. 현재 단말은 서버에 요청조차 하지 않았다.
첫 번째 OnCalculate()는 로컬에서 사용 가능한 따옴표를 읽은 후 호출됩니다. 드문 경우지만 로컬에 아무것도 없는 경우가 있습니다. 그런 다음 Time[0]을 참조하는 표시기가 배열 범위를 벗어난 오류로 인해 날아갑니다. 따라서 iTime 기능 및 유사한 기능을 사용하는 것이 좋습니다.
두 번째 및 후속 OnCalculate()는 기록이 바뀌거나 틱이 실제로 도착할 때 발생합니다.
prev_calculated== 0 값을 전역 가시성 수준의 변수에 복사하고 지표가 계산되었는지 여부를 OnTimer()에서 확인할 수 있습니다. 위에서 MT4에서 잘못된 OnCalculate() 계산으로버그를 본 적이 없다고 썼습니다 . 어쨌든 계산될 것입니다. TF 데이터가 준비되지 않은 경우return(rates_total) 은 0을 반환합니다. 이는 다음 OnCalculate() 호출에서 prev_calculated== 0 의 기호가 됩니다. :
voidOnTimer (){
if (Global_prev_calculated== 0 ) return ;
}
prev_calculated== 0 값을 전역 가시성 수준의 변수에 복사하고 지표가 계산되었는지 여부를 OnTimer()에서 확인할 수 있습니다. 위에서 MT4에서 잘못된 OnCalculate() 계산으로버그를 본 적이 없다고 썼습니다 . 어쨌든 계산될 것입니다. TF 데이터가 준비되지 않은 경우return(rates_total)은 0을 반환하며 이는OnCalculate() 에 대한 다음 호출에서 prev_calculated==0 의 표시가 될 것입니다.
가장 안정적인 솔루션은 실제로 OnCalculate() 호출 을 기다리고 거래 서버에 대한 연결 설정을 의무적으로 확인하는 것입니다. 연결(IsConnected())을 확인하지 않으면 터미널을 로드할 때 OnCalculate()에서도 다음을 얻습니다.
1. OnCalculate()에서 선임 TF의 데이터(최소한)를 수신하기 전에 호출해야 한다고 IsConnected()에 대한 문서에 작성되지 않은 이유는 무엇입니까?
2. OnTimer()의 IsConnected()가 실제로 작동하지 않는 이유는 무엇입니까? 결국, 무역 서버와 연결을 설정했다는 사실이 데이터를 수신할 수 있다는 것을 말해주지 않습니까?
3. 거래 서버와 연결을 설정하고 OnTimer()에서 데이터를 수신하려고 하기 때문에 데이터가 동일한 데이터에서 온 경우 iTime(), iBarShift(), SeriesInfoInteger() 및 유사한 함수가 오류를 반환해서는 안 됩니다. 정보를 가져오는 거래 서버가 아직 동기화되지 않았습니까? 그렇지 않으면 오류 4066을 반환한 다음 가지고 있는 데이터로 원하는 대로 생활하는 것과 같이 일종의 말도 안되는 것으로 판명됩니다.
1. OnCalculate()에서 선임 TF의 데이터(최소한)를 수신하기 전에 호출해야 한다고 IsConnected()에 대한 문서에 작성되지 않은 이유는 무엇입니까?
2. OnTimer()의 IsConnected()가 실제로 작동하지 않는 이유는 무엇입니까? 결국, 무역 서버와 연결을 설정했다는 사실이 데이터를 수신할 수 있다는 것을 말해주지 않습니까?
3. 거래 서버와 연결을 설정하고 OnTimer()에서 데이터를 수신하려고 하기 때문에 데이터가 동일한 데이터에서 온 경우 iTime(), iBarShift(), SeriesInfoInteger() 및 유사한 함수가 오류를 반환해서는 안 됩니다. 정보를 가져오는 거래 서버가 아직 동기화되지 않았습니까? 그렇지 않으면 오류 4066을 반환한 다음 가지고 있는 데이터로 원하는 대로 생활하는 것과 같이 일종의 말도 안되는 것으로 판명됩니다.
1. 글쎄, 아무도 기록 데이터에 대한 표시기를 호출하는 경우를 취소하지 않았습니다. 온라인으로 작업해야 하는 경우 연결을 확인하면 필요하지 않거나 중요하지 않은 경우 내 버전의 템플릿이 작동합니다. IsConnected() 함수 그룹은 일반적으로 약간 까다롭습니다. 어떤 이유에서 IsTradeContextBusy()가 거기에서 교차하고 IsConnected() 자체가 IsTradeAllowed()가 되지만 여기에서는 뭔가가 서버 측에서 화학적으로 수행되고 있다고 생각합니다. 뉴스 또는 기타 조작 중에 터미널이 꺼집니다.
2.3. 작동하지만 GetLastError()가 호출 후 상태를 재설정한다는 사실을 잊어버리고 GetLastError() 상태를 업데이트하기 위해 터미널에 제어를 이전해야 할 수도 있습니다. 아마도 터미널은 다시 실행할 시간이 없을 것입니다. 타이머에서 호출하기 전에 GetLastError()에서 IsConnected() 상태를 설정합니다. ... OnTimer() 함수 자체는 데이터 수신을 위한 것이 아니라고 생각합니다: "MQL4 Reference / Status Check" - OnTimer()가 호출됩니다, 그러나 터미널 환경 변수는 업데이트되었다는 사실이 아니라 OnCalculate()거기에 틱이 도착하면 터미널이 모든 데이터를 준비한다는 것이 보장됩니다.
2.3. 작동하지만 GetLastError()가 호출 후 상태를 재설정한다는 사실을 잊어버리고 GetLastError() 상태를 업데이트하기 위해 터미널에 제어를 이전해야 할 수도 있습니다. 아마도 터미널은 다시 실행할 시간이 없을 것입니다. 타이머에서 호출하기 전에 GetLastError()에서 IsConnected() 상태를 설정합니다. ... OnTimer() 함수 자체는 데이터 수신을 위한 것이 아니라고 생각합니다: "MQL4 Reference / Status Check" - OnTimer()가 호출됩니다, 그러나 터미널 환경 변수는 업데이트되었다는 사실이 아니라 OnCalculate()거기에 틱이 도착하면 터미널이 모든 데이터를 준비한다는 것이 보장됩니다.
1. 0번 마디의 시간이 틀리면 나머지 히스토리도 정확한 시간이 될 거라고 생각하시나요? :)
2.3. 데이터 액세스 기능이 의미 있는 오류를 설정할 시간이 충분하지 않은 경우 어떻게든 보고하게 하되 오류 코드 = 0(오류 없음)을 반환하지는 않습니다. 나머지 "아마도"는 추측일 뿐입니다. 그리고 증거가 없으면 말할 것도 없습니다.
iBarShift를 사용한 리셉션을 사용하면 기록의 구멍을 식별할 수 있지만 이를 위해서는 일정 간격으로 양모를 해야 합니다. 이 작업을 수행하는 절차를 직접 작성했습니다. 그 후 MTF 프로그램의 공백을 잊어버렸습니다.
데이터가 오류 4066과 함께 로드된 다음 메타따옴표를 사용할 수 없습니다. 이 상황에서 수신된 데이터가 처리될 가능성이 높으며 오류가 발생하지 않았습니다. 그리고 여기까지는 모든 것이 논리적입니다.
실수가 "발명되지 않았다"고 해서 그것이 존재하지 않는다는 의미는 아닙니다.
여기에서의 연설은 "구멍"의 식별에 대해 가지 않았습니다. 인간은 역사상 마지막 바를 얻어야 했다. 그리고 이것은 반드시 현재의 시간 막대일 필요는 없습니다.
그것은 iBarShift()에 관한 것이 아닙니다. 결국 SeriesInfoInteger()와 마찬가지로 iTime()과 동일한 오류를 보냅니다. 여기서 목발은 초기화 중에 얻은 시간을 비교하고 타이머에서 얻은 시간과 비교하는 것입니다. 이것이 우리가 터미널을 로드할 때 IBarShift()가 아닌 올바른 최신 데이터를 얻을 수 있게 해주었습니다.
네, 그리고 시간이 15시 00분 45초이고(예를 들어) 15시에 아직 바에 체크 표시가 없고, 마지막 매시간 바 의 영업시간 이 14시라면 모든 것이 정확하고, 제 생각에는. 그러나 시스템이 13:00을 반환하면 문제가 발생합니다.
1. 이고르, 코드 봤어? OnInit()에서 무엇을 얻을 수 있습니까?
귀하의 경우 OnInit() 직후에 하나 이상의 OnTimer 호출이 이루어집니다. 아직 OnCalculate() 이벤트가 없습니다.
2. 수표는 무엇입니까? 표시기가 올바른 작동을 위해 적어도 한 번은 OnCalculate()를 사용해야 한다고 어디에 쓰여 있습니까?
이를 위해서는 터미널의 논리에 대한 이해가 필요합니다. 지표가 차트에 연결되면 OnInit()가 즉시 호출됩니다. 터미널이 실행되면 차트 창이 생성된 직후 차트에 인디케이터가 연결됩니다. 현재 단말은 서버에 요청조차 하지 않았다.
첫 번째 OnCalculate()는 로컬에서 사용 가능한 따옴표를 읽은 후 호출됩니다. 드문 경우지만 로컬에 아무것도 없는 경우가 있습니다. 그런 다음 Time[0]을 참조하는 표시기가 배열 범위를 벗어난 오류로 인해 날아갑니다. 따라서 iTime 기능 및 유사한 기능을 사용하는 것이 좋습니다.
두 번째 및 후속 OnCalculate()는 기록이 바뀌거나 틱이 실제로 도착할 때 발생합니다.
첫 번째 OnCalculate()는 로컬에서 사용 가능한 따옴표를 읽은 후 호출됩니다. 드문 경우지만 로컬에 아무것도 없는 경우가 있습니다. 그런 다음 Time[0]을 참조하는 표시기가 배열 범위를 벗어난 오류로 인해 날아갑니다. 따라서 iTime 기능 및 유사한 기능을 사용하는 것이 좋습니다.
우리는 아마도 OHLC의 준비가 MT4와 동일하지 않은 MQL5에 대해 이야기하고 있을 것입니다.
나는 오랫동안 템플릿에 따라 지표를 작성해 왔습니다.
MT4 에서 OHLC 어레이 를 넘어갈 때 "지표 충돌"이 발생한 적이 없으며 차트가 준비될 때까지 MT4가 처음으로 OnCalculate()를 시작하지 않을 것이라고 생각합니다. 확인하지만 prev_calculated== 0 , MT5에서는 작성한 대로 됩니다. OHLC 데이터가 준비되었는지 확인하는 추가 확인이 필요합니다.
귀하의 경우 OnInit() 직후에 하나 이상의 OnTimer 호출이 이루어집니다. 아직 OnCalculate() 이벤트가 없습니다.
이를 위해서는 터미널 논리에 대한 이해가 필요합니다. 지표가 차트에 연결되면 OnInit()가 즉시 호출됩니다. 터미널이 실행되면 차트 창이 생성된 직후 차트에 인디케이터가 연결됩니다. 현재 단말은 서버에 요청조차 하지 않았다.
첫 번째 OnCalculate()는 로컬에서 사용 가능한 따옴표를 읽은 후 호출됩니다. 드문 경우지만 로컬에 아무것도 없는 경우가 있습니다. 그런 다음 Time[0]을 참조하는 표시기가 배열 범위를 벗어난 오류로 인해 날아갑니다. 따라서 iTime 기능 및 유사한 기능을 사용하는 것이 좋습니다.
두 번째 및 후속 OnCalculate()는 기록이 바뀌거나 틱이 실제로 도착할 때 발생합니다.
문제를 해결하기 위해 무엇을 제안합니까(당신의 생각에는 그것이 존재합니까)? OnCalculate()가 1-2번 호출 될 때까지 기다리시겠습니까?
문제를 해결하기 위해 무엇을 제안합니까(당신의 생각에는 그것이 존재합니까)? OnCalculate()가 1-2번 호출 될 때까지 기다리시겠습니까?
prev_calculated== 0 값을 전역 가시성 수준의 변수에 복사하고 지표가 계산되었는지 여부를 OnTimer()에서 확인할 수 있습니다. 위에서 MT4에서 잘못된 OnCalculate() 계산으로 버그를 본 적이 없다고 썼습니다 . 어쨌든 계산될 것입니다. TF 데이터가 준비되지 않은 경우 return (rates_total) 은 0을 반환합니다. 이는 다음 OnCalculate() 호출에서 prev_calculated == 0 의 기호가 됩니다. :
prev_calculated== 0 값을 전역 가시성 수준의 변수에 복사하고 지표가 계산되었는지 여부를 OnTimer()에서 확인할 수 있습니다. 위에서 MT4에서 잘못된 OnCalculate() 계산으로 버그를 본 적이 없다고 썼습니다 . 어쨌든 계산될 것입니다. TF 데이터가 준비되지 않은 경우 return (rates_total)은 0을 반환하며 이는 OnCalculate() 에 대한 다음 호출에서 prev_calculated== 0 의 표시가 될 것입니다.
가장 안정적인 솔루션은 실제로 OnCalculate() 호출 을 기다리고 거래 서버에 대한 연결 설정을 의무적으로 확인하는 것입니다. 연결(IsConnected())을 확인하지 않으면 터미널을 로드할 때 OnCalculate()에서도 다음을 얻습니다.
그러나 이것이 모든 질문을 해결하는 것은 아닙니다.
1. OnCalculate()에서 선임 TF의 데이터(최소한)를 수신하기 전에 호출해야 한다고 IsConnected()에 대한 문서에 작성되지 않은 이유는 무엇입니까?
2. OnTimer()의 IsConnected()가 실제로 작동하지 않는 이유는 무엇입니까? 결국, 무역 서버와 연결을 설정했다는 사실이 데이터를 수신할 수 있다는 것을 말해주지 않습니까?
3. 거래 서버와 연결을 설정하고 OnTimer()에서 데이터를 수신하려고 하기 때문에 데이터가 동일한 데이터에서 온 경우 iTime(), iBarShift(), SeriesInfoInteger() 및 유사한 함수가 오류를 반환해서는 안 됩니다. 정보를 가져오는 거래 서버가 아직 동기화되지 않았습니까? 그렇지 않으면 오류 4066을 반환한 다음 가지고 있는 데이터로 원하는 대로 생활하는 것과 같이 일종의 말도 안되는 것으로 판명됩니다.
그러나 이것이 모든 질문을 해결하는 것은 아닙니다.
1. OnCalculate()에서 선임 TF의 데이터(최소한)를 수신하기 전에 호출해야 한다고 IsConnected()에 대한 문서에 작성되지 않은 이유는 무엇입니까?
2. OnTimer()의 IsConnected()가 실제로 작동하지 않는 이유는 무엇입니까? 결국, 무역 서버와 연결을 설정했다는 사실이 데이터를 수신할 수 있다는 것을 말해주지 않습니까?
3. 거래 서버와 연결을 설정하고 OnTimer()에서 데이터를 수신하려고 하기 때문에 데이터가 동일한 데이터에서 온 경우 iTime(), iBarShift(), SeriesInfoInteger() 및 유사한 함수가 오류를 반환해서는 안 됩니다. 정보를 가져오는 거래 서버가 아직 동기화되지 않았습니까? 그렇지 않으면 오류 4066을 반환한 다음 가지고 있는 데이터로 원하는 대로 생활하는 것과 같이 일종의 말도 안되는 것으로 판명됩니다.
1. 글쎄, 아무도 기록 데이터에 대한 표시기를 호출하는 경우를 취소하지 않았습니다. 온라인으로 작업해야 하는 경우 연결을 확인하면 필요하지 않거나 중요하지 않은 경우 내 버전의 템플릿이 작동합니다. IsConnected() 함수 그룹은 일반적으로 약간 까다롭습니다. 어떤 이유에서 IsTradeContextBusy()가 거기에서 교차하고 IsConnected() 자체가 IsTradeAllowed()가 되지만 여기에서는 뭔가가 서버 측에서 화학적으로 수행되고 있다고 생각합니다. 뉴스 또는 기타 조작 중에 터미널이 꺼집니다.
2.3. 작동하지만 GetLastError()가 호출 후 상태를 재설정한다는 사실을 잊어버리고 GetLastError() 상태를 업데이트하기 위해 터미널에 제어를 이전해야 할 수도 있습니다. 아마도 터미널은 다시 실행할 시간이 없을 것입니다. 타이머에서 호출하기 전에 GetLastError()에서 IsConnected() 상태를 설정합니다. ... OnTimer() 함수 자체는 데이터 수신을 위한 것이 아니라고 생각합니다: "MQL4 Reference / Status Check" - OnTimer()가 호출됩니다, 그러나 터미널 환경 변수는 업데이트되었다는 사실이 아니라 OnCalculate() 거기에 틱이 도착하면 터미널이 모든 데이터를 준비한다는 것이 보장됩니다.
1. 글쎄, 아무도 과거 데이터에 지표를 호출하는 경우를 취소하지 않았습니다 ...
2.3. 작동하지만 GetLastError()가 호출 후 상태를 재설정한다는 사실을 잊어버리고 GetLastError() 상태를 업데이트하기 위해 터미널에 제어를 이전해야 할 수도 있습니다. 아마도 터미널은 다시 실행할 시간이 없을 것입니다. 타이머에서 호출하기 전에 GetLastError()에서 IsConnected() 상태를 설정합니다. ... OnTimer() 함수 자체는 데이터 수신을 위한 것이 아니라고 생각합니다: "MQL4 Reference / Status Check" - OnTimer()가 호출됩니다, 그러나 터미널 환경 변수는 업데이트되었다는 사실이 아니라 OnCalculate() 거기에 틱이 도착하면 터미널이 모든 데이터를 준비한다는 것이 보장됩니다.
1. 0번 마디의 시간이 틀리면 나머지 히스토리도 정확한 시간이 될 거라고 생각하시나요? :)
2.3. 데이터 액세스 기능이 의미 있는 오류를 설정할 시간이 충분하지 않은 경우 어떻게든 보고하게 하되 오류 코드 = 0(오류 없음)을 반환하지는 않습니다. 나머지 "아마도"는 추측일 뿐입니다. 그리고 증거가 없으면 말할 것도 없습니다.
OnTimer() 함수는 데이터를 수신하도록 설계되지 않았습니다...
댓글이 없습니다.
OnTimer()가 호출되지만 터미널의 환경 변수는 업데이트된다는 사실이 아닙니다.