이전에는 CustomTicksAdd가 현재 날짜와 관련된 눈금에서 막대를 형성했습니다. 이제 이것은 아닙니다.
이 버그는 버그 #14와 관련된 것으로 보입니다.
다음과 같은 이유로 Market Watch에서 심볼을 제거할 수 있게 되었습니다. CustomSymbolCreate - CustomSymbolDelete - CustomSymbolCreate를 동일한 사용자 지정 기호 이름으로 연속으로 호출하면 기호 식별자가 혼동됩니다. 따라서 마켓워치에서 심볼 제거가 가능한지 확인할 때 해당 심볼의 차트를 찾을 수 없었고(식별자가 손상됨) 해당 심볼을 안전하게 제거하였다. 이 문제가 해결되었습니다.
차트에 틱을 적용하면 같은 일이 가능합니다 - 기호 ID로 차트를 검색해도 결과가 나오지 않습니다
prev_calculated는 OnCalculate에 대한 이전 호출 에서 반환된 값을 포함합니다.
표시기 작성자는 자체 논리를 기반으로 모든 값을 반환할 수 있습니다. 따라서 모든 지표를 살펴보고 prev_calculated 값을 timeframe을 고려하여 계산된 자체 값으로 변경하는 것은 의미가 없습니다. 그리고 리소스 집약적이며 심지어 비합리적으로 리소스 집약적인 것으로 판명될 수도 있습니다.
prev_calculated는 OnCalculate에 대한 이전 호출 에서 반환된 값을 포함합니다.
표시기 작성자는 자체 논리를 기반으로 모든 값을 반환할 수 있습니다. 따라서 모든 지표를 살펴보고 prev_calculated 값을 timeframe을 고려하여 계산된 자체 값으로 변경하는 것은 의미가 없습니다. 그리고 리소스 집약적이며 심지어 비합리적으로 리소스 집약적인 것으로 판명될 수도 있습니다.
아무것도 계산되지 않은 초기와 같이 0을 설정하는 것이 훨씬 더 정직합니다.
그런 다음 사용자 지정 기호에서 각 틱 이후에 이 0 값으로 인해 표시기가 완전히 다시 계산될 때 어떻게 해야 합니까?
표시기는 터미널 속도를 늦추지 않도록 특별히 작성되었지만 여기에서는 모든 것이 반대로 발생하기 시작합니다.
과거의 틱을 전달하는 것은 CustomTicksAdd뿐만 아니라 RatesUpdate이기도 하다는 점을 분명히 해두겠습니다. 결국 작동하는 TicksAdd조차도 오늘보다 일찍 막대를 형성하지 않았습니다. 직접 만들어야 합니다. 이 때문에 prev_calculated가 0이 됩니다.
어쨌든 막대를 교체, 업데이트, 삭제할 때 모든 표시기는 0에서 다시 계산됩니다. 이것은 논의되지 않습니다.
진드기 추가는 평소와 같이 작동해야 합니다. 즉, 진드기 - 어제나 어제가 아닌 오늘의 새 것입니다.
버그 설명 11 에서 Expert Advisor를 시작한 다음 각 OnCalculate에 인쇄된 표시기를 시작했습니다.
버그 16.
이전에는 CustomTicksAdd가 현재 날짜와 관련된 눈금에서 막대를 형성했습니다. 이제 이것은 아닙니다.
이 버그는 버그 #14와 관련된 것으로 보입니다.
다음과 같은 이유로 Market Watch에서 심볼을 제거할 수 있게 되었습니다. CustomSymbolCreate - CustomSymbolDelete - CustomSymbolCreate를 동일한 사용자 지정 기호 이름으로 연속으로 호출하면 기호 식별자가 혼동됩니다. 따라서 마켓워치에서 심볼 제거가 가능한지 확인할 때 해당 심볼의 차트를 찾을 수 없었고(식별자가 손상됨) 해당 심볼을 안전하게 제거하였다. 이 문제가 해결되었습니다.
차트에 틱을 적용하면 같은 일이 가능합니다 - 기호 ID로 차트를 검색해도 결과가 나오지 않습니다
버그 15.
이 Expert Advisor 의 기호( ChartSetSymbolPeriod -string이 제거됨)에서 이러한 표시기를 시작합니다.
0만 반환합니다.
절대적으로 공정합니다.
CustomRatesUpdate가 호출되면 모든 변경 카운터가 재설정되고 표시기가 0에서 다시 계산됩니다.
절대적으로 공정합니다.
CustomRatesUpdate가 호출되면 모든 변경 카운터가 재설정되고 표시기가 0에서 다시 계산됩니다.
그러한 결정의 논리는 무엇입니까? 결국 왼쪽에는 변경되지 않은 막대가 있습니다.
그러한 결정의 논리는 무엇입니까? 결국 왼쪽에는 변경되지 않은 막대가 있습니다.
prev_calculated는 OnCalculate에 대한 이전 호출 에서 반환된 값을 포함합니다.
표시기 작성자는 자체 논리를 기반으로 모든 값을 반환할 수 있습니다. 따라서 모든 지표를 살펴보고 prev_calculated 값을 timeframe을 고려하여 계산된 자체 값으로 변경하는 것은 의미가 없습니다. 그리고 리소스 집약적이며 심지어 비합리적으로 리소스 집약적인 것으로 판명될 수도 있습니다.
아무것도 계산되지 않은 초기와 같이 0을 설정하는 것이 훨씬 더 정직합니다.
prev_calculated는 OnCalculate에 대한 이전 호출 에서 반환된 값을 포함합니다.
표시기 작성자는 자체 논리를 기반으로 모든 값을 반환할 수 있습니다. 따라서 모든 지표를 살펴보고 prev_calculated 값을 timeframe을 고려하여 계산된 자체 값으로 변경하는 것은 의미가 없습니다. 그리고 리소스 집약적이며 심지어 비합리적으로 리소스 집약적인 것으로 판명될 수도 있습니다.
아무것도 계산되지 않은 초기와 같이 0을 설정하는 것이 훨씬 더 정직합니다.
그런 다음 사용자 지정 기호에서 각 틱 이후에 이 0 값으로 인해 표시기가 완전히 다시 계산될 때 어떻게 해야 합니까?
표시기는 터미널 속도를 늦추지 않도록 특별히 작성되었지만 여기에서는 모든 것이 반대로 발생하기 시작합니다.
그런 다음 사용자 지정 기호에서 각 틱 이후에 이 0 값으로 인해 표시기가 완전히 다시 계산될 때 어떻게 해야 합니까?
그렇게 해서는 안됩니다. 점검 해보자
그렇게 해서는 안됩니다. 점검 해보자
과거의 틱을 전달하는 것은 CustomTicksAdd 뿐만 아니라 RatesUpdate 이기도 합니다. 결국 작동하는 TicksAdd조차도 오늘보다 일찍 막대를 형성하지 않았습니다. 직접 만들어야 합니다. 이 때문에 prev_calculated가 0이 됩니다.
과거의 틱을 전달하는 것은 CustomTicksAdd뿐만 아니라 RatesUpdate이기도 하다는 점을 분명히 해두겠습니다. 결국 작동하는 TicksAdd조차도 오늘보다 일찍 막대를 형성하지 않았습니다. 직접 만들어야 합니다. 이 때문에 prev_calculated가 0이 됩니다.
어쨌든 막대를 교체, 업데이트, 삭제할 때 모든 표시기는 0에서 다시 계산됩니다. 이것은 논의되지 않습니다.
진드기 추가는 평소와 같이 작동해야 합니다. 즉, 진드기 - 어제나 어제가 아닌 오늘의 새 것입니다.
버그 설명 11 에서 Expert Advisor를 시작한 다음 각 OnCalculate에 인쇄된 표시기를 시작했습니다.
다음은 로그입니다.
즉, 정상적인 상황(오늘날의 틱, 항상 그랬어야 함)에서는 모든 것이 올바르게 작동합니다. 그리고 틱이 추가되고 지표는 드물게 고려됩니다.
어쨌든 막대를 교체, 업데이트, 삭제할 때 모든 표시기는 0에서 다시 계산됩니다. 이것은 논의되지 않습니다.
진드기 추가는 평소와 같이 작동해야 합니다. 즉, 진드기 - 어제나 어제가 아닌 오늘의 새 것입니다.
버그 설명 11 에서 Expert Advisor를 시작한 다음 각 OnCalculate에 인쇄된 표시기를 시작했습니다.
다음은 로그입니다.
즉, 정상적인 상황에서(오늘날의 틱 은 항상 그랬듯이 ) 모든 것이 올바르게 작동합니다. 그리고 틱이 추가되고 지표는 드물게 고려됩니다.
이게 맞는 말인가요?
게다가 지금이 00:00:01이면 불과 2초 전인 CustomTicksAdd를 통해 막대를 완성할 수 없습니다.
이게 맞는 말인가요?
테스터의 경우, 어제의 시간 전날에 대한 어제의 틱이 신선한 것, 오늘의 것입니다.
무슨 말을 하고 싶은지 이해했습니다. 6개월 전의 맞춤 눈금이 있는 운동은 테스트 특성이 뚜렷합니다. 귀하의 상황이 정상이 아닙니다(일반적인 관행의 의미에서)