Если в MT изменить таймфрейм или имя символа чарта, то все индикаторы на чарте выгрузятся с чарта и загрузятся на него снова. При этом, в отличие от MT4, в MT5 последовательность выгрузиться/загрузиться не определена из-за особенности внутренней архитектуры. Данное обстоятельство иногда вызывает не сразу очевидные проблемы, связанные с тем, что...
솔직히 말해서, 고통받는 사람들이 자신의 문제에 대한 해결책을 스스로 작성하지 못하게 한 이유를 이해하지 못합니다.
그리고 왜 개발자는 여기서 무언가를 변경해야 합니까?
고통받는 사람은 지표에서 들어오는 틱 수를 어떤 식 으로든 변경할 수 없으며 새 막대가 나타날 때까지 지표에서 틱을 건너 뜁니다. 지표가 오랫동안 계산되면 틱은 여전히 건너 뜁니다. 어떻게든 현실에 적응해야 합니다.
한 기호의 최고 값이 분당 ~800틱인 경우 여러 기호의 합성의 경우 이미 분당 2300틱입니다. 하나의 합성물과 하나의 기호를 열면 피크는 분당 ~ 3000틱입니다. 동일한 합성 및 동일한 기호의 다른 시간 프레임을 추가하면... 음, 세 개의 엘더 스크린이 있었고 최대 ~9000틱/분 또는 150틱/초를 얻습니다. Rinat은 이미 성능 문제에 대해 글을 썼습니다. 모든 기호 tfs에 대해 분당 1틱이 필요한 경우 다중 기호-mtf 표시기를 통해 초당 유휴 150틱을 전달하는 이유는 무엇입니까? 마찬가지로 mql 호스팅의 장점은 호스트 시스템에서 오버 헤드 비용이 없다는 것을 나타내며 터미널은 지표 및 전문가에게만 동일한 호스트입니다. 지표의 계산이 RSI(3) + EMA(5) + EMA(7)로 구성되면 물론 향후 10년 동안 문제가 예상되지 않습니다.
합성에서 (실제로 터미널의 다중 문자 표시기) 개발자는 어떻게 든 여러 문자를 함께 묶는 아이디어를 생각해 냈습니다. 왜이 시스템의 요소를 복제 (이상적이지 않다고 말하자) 표시기에서 프로그래머의 자위? 시스템을 단순화할 수 있다면 그렇게 하지 마십시오. 지구가 여전히 세 마리의 코끼리 위에 서 있을 때 5초짜리 TF가 발명된 데에는 이유가 있습니다.
업데이트 기록 없이 5초 동안 TF를 입력하고 5초에 한 번만 틱을 표시하고 모든 종류의 솔루션을 테스트할 수도 있습니다(5S에서만 작동하도록 일종의 접두사가 있는 표시기를 컴파일하면 다른 표시기가 시작되지 않습니다. it) - 기존 단말의 이념은 건드리지 않기 때문에 솔루션 변경 및 변경이 가능하며, 테스트 중에 최적/최적의 솔루션이 형성됩니다.
문제는 솔루션의 실행 가능성에 관한 것이 아닙니다. 알 수없는 수의 틱이 건너 뛰기 전에 도달 한 각 틱에서 표시기를 호출하는 편리함 외에도 틱의 일부 노후화로 간주됩니다 ??? 무언가를 건너뛰고(부하가 증가하면서) 들어오는 틱의 관련성을 알 수 없으므로 이 상황은 시간과 관련된 분석 문제를 해결하지 못합니다. 그렇지 않은 경우 왜 문제를 해결해야 합니까? 일반적으로 표시기로의 틱 흐름을 금지하고 5초마다 한 번씩 플랫폼에서 표시기로 틱을 남겨두십시오. 분당 12틱이면 충분합니다.
문제는 솔루션의 실행 가능성에 관한 것이 아닙니다. 알 수없는 수의 틱이 건너 뛰기 전에 도달 한 각 틱에서 표시기를 호출하는 편리함 외에도 틱의 일부 노후화로 간주됩니다 ??? 무언가를 건너뛰고(부하가 증가하면서) 들어오는 틱의 관련성을 알 수 없기 때문에 이 상황은 시간과 관련된 분석 문제를 해결하지 못합니다. 그렇지 않다면 왜 문제를 일으키겠습니까? 일반적으로 표시기로의 틱 흐름을 금지하고 5초마다 한 번씩 플랫폼에서 표시기로 틱을 남겨두십시오. 분당 12틱이면 충분합니다.
즉, 그러한 디자인으로 매우 빠른 표시기를 가질 수 있습니까?
오히려 OnCalculate는 모든 틱 에 대해 호출되지 않고 틱의 무리 후에 호출됩니다.
그렇다면 이것은 좋은 소식입니다!
#property tester_everytick_calculate 플래그를 포함하지 않는 표시기에 대한 아이디어가 있습니다. 각 틱 이 아니라 일괄 틱 수신을 기반으로 계산 모드를 활성화하는 것입니다.
이것은 브레이크 표시기의 문제를 근본적으로 해결하는 동시에 일부 표시기에 대한 각 틱의 보장된 처리 가능성을 유지합니다.
다른 해결책을 제안합니다.
SymbolInfoTick
MqlTick 유형의 변수에 지정된 기호의 현재 가격을 반환합니다.
옵션
반환 값
그런 다음 OnCalculate에서는 그러한 구성만 처방하는 것으로 충분합니다.
이 솔루션은 사용 및 구현 측면에서 더 유연하고 편리한 것 같습니다.
위협 현재 및 표시기 틱의 수를 얻을 수 있는 기능과 함께 틱의 번호를 매기는 것이 더 좋습니다. 그러나 이 옵션은 개발자에게 더 어렵습니다. 그래서 가치가 없을 것입니다.
다른 해결책을 제안합니다.
그러나 개발자 측에서 아무 것도 수행하지 않으면(그런데 이것은 매우 좋은 옵션임) 이제 이러한 방식으로 모든 브레이크를 우회할 수 있습니다.
그러나 개발자 측에서 아무 것도 수행하지 않으면(그런데 이것은 매우 좋은 옵션임) 이제 이러한 방식으로 모든 브레이크를 우회할 수 있습니다.
글쎄, 우리는 막대 중간에 눈금이 필요하지 않으며 여전히 강제로 건너뜁니다. mql의 구현을 기다리자.
글쎄, 우리는 막대 중간에 눈금이 필요하지 않으며 여전히 강제로 건너뜁니다. mql의 구현을 기다리자.
솔직히 말해서, 고통받는 사람들이 자신의 문제에 대한 해결책을 스스로 작성하지 못하게 한 이유를 이해하지 못합니다.
그리고 왜 개발자는 여기서 무언가를 변경해야 합니까?
위의 솔루션은 mqh 파일로 형식을 지정할 수 있으며 예를 들어 Init_Sync 에서 수행되는 것처럼 한 줄로 모든 표시기에 연결할 수 있습니다. 그러나 최소한 코드는 명확하지 않고 적절하게 작성되어야 했습니다. 다음은 몇 줄입니다.
재접속 후 다른 사람의 보이지 않는 시간대 업데이트가 정지되면서 연결이 정리되고 수정되었습니다. 이유는 재연결 후 잘못된 캐시 상태였습니다.
베타 버전 1946은 도움말 -> 데스크톱 업데이트 확인 -> 최신 베타 버전을 통해 사용할 수 있습니다.
Rinat, 3일 동안 문제 없이 테스트했습니다. 감사합니다!
솔직히 말해서, 고통받는 사람들이 자신의 문제에 대한 해결책을 스스로 작성하지 못하게 한 이유를 이해하지 못합니다.
그리고 왜 개발자는 여기서 무언가를 변경해야 합니까?
고통받는 사람은 지표에서 들어오는 틱 수를 어떤 식 으로든 변경할 수 없으며 새 막대가 나타날 때까지 지표에서 틱을 건너 뜁니다. 지표가 오랫동안 계산되면 틱은 여전히 건너 뜁니다. 어떻게든 현실에 적응해야 합니다.
한 기호의 최고 값이 분당 ~800틱인 경우 여러 기호의 합성의 경우 이미 분당 2300틱입니다. 하나의 합성물과 하나의 기호를 열면 피크는 분당 ~ 3000틱입니다. 동일한 합성 및 동일한 기호의 다른 시간 프레임을 추가하면... 음, 세 개의 엘더 스크린이 있었고 최대 ~9000틱/분 또는 150틱/초를 얻습니다. Rinat은 이미 성능 문제에 대해 글을 썼습니다. 모든 기호 tfs에 대해 분당 1틱이 필요한 경우 다중 기호-mtf 표시기를 통해 초당 유휴 150틱을 전달하는 이유는 무엇입니까? 마찬가지로 mql 호스팅의 장점은 호스트 시스템에서 오버 헤드 비용이 없다는 것을 나타내며 터미널은 지표 및 전문가에게만 동일한 호스트입니다. 지표의 계산이 RSI(3) + EMA(5) + EMA(7)로 구성되면 물론 향후 10년 동안 문제가 예상되지 않습니다.
합성에서 (실제로 터미널의 다중 문자 표시기) 개발자는 어떻게 든 여러 문자를 함께 묶는 아이디어를 생각해 냈습니다. 왜이 시스템의 요소를 복제 (이상적이지 않다고 말하자) 표시기에서 프로그래머의 자위? 시스템을 단순화할 수 있다면 그렇게 하지 마십시오. 지구가 여전히 세 마리의 코끼리 위에 서 있을 때 5초짜리 TF가 발명된 데에는 이유가 있습니다.
업데이트 기록 없이 5초 동안 TF를 입력하고 5초에 한 번만 틱을 표시하고 모든 종류의 솔루션을 테스트할 수도 있습니다(5S에서만 작동하도록 일종의 접두사가 있는 표시기를 컴파일하면 다른 표시기가 시작되지 않습니다. it) - 기존 단말의 이념은 건드리지 않기 때문에 솔루션 변경 및 변경이 가능하며, 테스트 중에 최적/최적의 솔루션이 형성됩니다.
(개발 라이브러리, 합성, 분리된 창 등에 대한 SOL. 개발자).
예, 분당 최소 백만 틱입니다. 그렇다고 해서 솔루션 이 작동하지 않는 것은 아닙니다.
예, 분당 최소 백만 틱입니다. 그렇다고 해서 솔루션 이 작동하지 않는 것은 아닙니다.
문제는 솔루션의 실행 가능성에 관한 것이 아닙니다. 알 수없는 수의 틱이 건너 뛰기 전에 도달 한 각 틱에서 표시기를 호출하는 편리함 외에도 틱의 일부 노후화로 간주됩니다 ??? 무언가를 건너뛰고(부하가 증가하면서) 들어오는 틱의 관련성을 알 수 없으므로 이 상황은 시간과 관련된 분석 문제를 해결하지 못합니다. 그렇지 않은 경우 왜 문제를 해결해야 합니까? 일반적으로 표시기로의 틱 흐름을 금지하고 5초마다 한 번씩 플랫폼에서 표시기로 틱을 남겨두십시오. 분당 12틱이면 충분합니다.
문제는 솔루션의 실행 가능성에 관한 것이 아닙니다. 알 수없는 수의 틱이 건너 뛰기 전에 도달 한 각 틱에서 표시기를 호출하는 편리함 외에도 틱의 일부 노후화로 간주됩니다 ??? 무언가를 건너뛰고(부하가 증가하면서) 들어오는 틱의 관련성을 알 수 없기 때문에 이 상황은 시간과 관련된 분석 문제를 해결하지 못합니다. 그렇지 않다면 왜 문제를 일으키겠습니까? 일반적으로 표시기로의 틱 흐름을 금지하고 5초마다 한 번씩 플랫폼에서 표시기로 틱을 남겨두십시오. 분당 12틱이면 충분합니다.
우둔.