zaskok3 : Marketwatch에 새 틱이 도착하는 이벤트입니다. OnTick과 동일하지만 하나의 기호가 아니라 "시장 감시"에 서명된 모든 기호의 새 틱에만 반응합니다.
현재 따옴표 흐름으로 다음 OnTick이 작업하는 동안 자체 틱도 일괄 처리됩니다.
어떤 이유에서인지 많은 사람들은 이벤트가 발생하면 다른 이벤트가 동일한 Expert Advisor에 의해(즉, 병렬로) 처리되더라도 이 이벤트의 핸들러가 바로 그 자리에서 즉시 트위스트한다고 생각합니다. 이것은 사실이 아닙니다.
모든 이벤트는 하나의 Expert Advisor에 대해 하나의 공통 대기열에 정렬됩니다. 전문가가 하나씩 처리합니다. 그리고 여기에서 모든 것은 프로그래머에 달려 있습니다 - 그가 이벤트 처리를 얼마나 효과적으로 구현하는지. 그러나 프로그래머가 슈퍼이고 프로그래머가 슈퍼 수레를 가지고 있어도 이벤트가 많으면 대기열이 팽창합니다 (다른 사람의 캐릭터에서 진드기가있는 경우 더욱 그렇습니다)
외국 기호에서 진드기를 원하는 주장은 무엇입니까? "거래에 늦을 수 있기 때문에 올바른 기호를 추적하기 위해 타이머를 실행하고 싶지 않습니다." 그리고 다른 심볼의 틱 이벤트(특히 여러 심볼이 모니터링되는 경우)는 다른 이벤트의 자체 처리로 인해 대기열에서 지연될 수 있으므로 배포에 늦을 확률이 훨씬 더 높습니다.
저를 믿으십시오, 우리는 다른 사람들의 진드기에 관한 사건에 대해 논의했습니다. 따라서 그들은 "타이머를 사용하는 것이 훨씬 낫다"는 결론에 도달했습니다.
그리고 그들은 서비스 데스크에 귀하의 의견으로는 작동 방식과 거래자의 99%가 이를 필요로 하는 이유에 대한 자세한 설명과 함께 편지를 보낼 것입니다.
o_o :
일반 변수로 작업하는 것을 막는 것은 전혀 없습니다. 대화형 표시기의 경우 실제로 외부 const 매개변수가 전혀 필요하지 않으며 사용자 자신의 상호 작용에 의해 제어되지 않습니다.
당신은 단순히 게으르고 비합리적인 초과를 요구합니다. 이미 작동하는 대안이 있기 때문에 자신이 사용하지 않을 것입니다.
나는 차분한 추론에 대한 그런 공격적인 인식을 이해하지 못합니다. 뭔가 좋지 않은 것 같았습니다 ... 이것은 거기에 없습니다. 모든 것이 정상입니다. 진정하십시오. 당신은 R이 아닙니다 ...
막심 크롤렌코 : 제 생각에는 여기에서 OnTimer()를 사용할 수 있으며 X밀리초마다 이벤트를 호출할 수 있습니다.
o_o : 필요한 기호에 표시기를 표시하고 Expert Advisor 에 사용자 지정 이벤트를 보내기 위해 이 솔루션의 보다 정확한 버전이 오랫동안 개발되었습니다.
그래서 저는 즉시 다음과 같이 썼습니다.
zaskok3 :
어떤 이유로 목발 솔루션은 타이머 또는 더 많은 변태인 OnChartEvent를 통해 제공됩니다.
Slava, 나는 당신의 논리를 잘 이해하지 못합니다:
슬라바 :
외국 기호에서 진드기를 원하는 주장은 무엇입니까? "거래에 늦을 수 있기 때문에 올바른 기호를 추적하기 위해 타이머를 실행하고 싶지 않습니다." 그리고 다른 심볼의 틱 이벤트(특히 여러 심볼이 모니터링되는 경우)는 다른 이벤트의 자체 처리로 인해 대기열에서 지연될 수 있으므로 배포에 늦을 확률이 훨씬 더 높습니다.
저를 믿으십시오, 우리 는 다른 사람들의 진드기에 관한 사건에 대해 정말로 논의했습니다. 따라서 그들은 "타이머를 사용하는 것이 훨씬 낫다" 는 결론에 도달했습니다.
타이머가 자신의 틱 에 충분하다면 OnTick의 목적은 무엇입니까? 내 논리가 제대로 작동하지 않을 수 있습니다. 그러나 나는 다음과 같이 주장한다. OnTick이 있기 때문에 OnMarketWatch가 있어야 한다. OnMarketWatch는 OnTimer를 통해 구현될 수 있으므로 OnTick에서도 동일한 작업을 수행할 수 있습니다. 따라서 OnTick의 존재는 OnMarketWatch의 존재와 동일한 근거를 가지고 있습니다. 그러나 하나는 있고 다른 하나는 그렇지 않습니다.
OnTick 대기열은 현재 OnTick을 실행하는 동안 있었던 틱에 대해 재설정됩니다(이는 Expert Advisors의 경우). 대기열의 오버플로에 대해 - 명확하지 않습니다. 주말에 타이머를 공회전하는 것은 현명하지 않습니다. Expert Advisors에서 OnTick은 모든 틱에서 작동하지 않습니다. 이러한 이유로 EA에서 간격 없이 진드기를 수집하는 것은 불가능합니다. 대기열이 재설정되며 이는 정상입니다. 오버플로가 없습니다.
타이머가 자신의 틱 에 충분하다면 OnTick의 목적은 무엇입니까? 내 논리가 제대로 작동하지 않을 수 있습니다. 그러나 나는 다음과 같이 주장한다. OnTick이 있기 때문에 OnMarketWatch가 있어야 한다. OnMarketWatch는 OnTimer를 통해 구현될 수 있으므로 OnTick에서도 동일한 작업을 수행할 수 있습니다. 따라서 OnTick의 존재는 OnMarketWatch의 존재와 동일한 근거를 가지고 있습니다. 그러나 하나는 있고 다른 하나는 그렇지 않습니다.
OnTick 대기열은 현재 OnTick을 실행하는 동안 있었던 틱에 대해 재설정됩니다(이는 Expert Advisors의 경우). 대기열의 오버플로에 대해 - 명확하지 않습니다. 주말에 타이머를 공회전하는 것은 현명하지 않습니다. Expert Advisors에서 OnTick은 모든 틱에서 작동하지 않습니다. 이러한 이유로 EA에서 간격 없이 진드기를 수집하는 것은 불가능합니다. 대기열이 재설정되며 이는 정상입니다. 오버플로가 없습니다.
쿼드 기능 시작에서 부드럽게 전환된 OnTick
OnTick은 요구 사항의 99%를 커버하며 간단한 프로그램을 작성할 수 있습니다.
대기열 오버플로 문제가 없습니다. 우리는 그 팽창에 대해 이야기하고 있습니다. 이벤트는 손실되지 않습니다.
개별 이벤트에 대한 별도의 대기열이 없습니다(OnTick 대기열). 하나의 Expert Advisor의 모든 이벤트에 공통적인 하나의 대기열이 있습니다.
그러나 대기열은 매우 지능적으로 이벤트로 보충됩니다. 대기열에 처리되지 않은 NewTick 이벤트 가 있으면 다른 NewTick 이벤트가 추가되지 않습니다. 대기열에 처리되지 않은 Timer 이벤트가 있으면 다른 Timer 이벤트가 대기열에 추가되지 않습니다. 등.
타이머의 합리성-불합리성에 대해 사실 타이머는 생각만큼 많은 리소스를 사용하지 않습니다. 그런데 클라이언트 터미널에서는 터미널 자체의 필요에 따라 여러 타이머가 동시에 작동합니다. 항상 실행, CPU 로드 0
99%에서 소스 코드에서 OnTick의 이름을 OnTimer로 변경하고 타이머 초기화를 한 줄 더 만들면 결과가 변경되지 않습니다. 이전과 같이 작동하고 프로그램은 여전히 간단합니다.
쿼드 기능 시작에서 부드럽게 전환된 OnTick
그러나 이것은 예입니다. 대부분 익숙합니다. 이것이 주된 이유입니다.
시간을 내어 설명해 주셔서 감사합니다. 타이머를 통해 인공 OnMarketWatch 구현을 위한 소스 코드를 코드베이스에 추가하라는 요청이 있습니다. 내 구현에서는 모든 기호의 이전 틱을 기억하고 각 타이머 단계에서 현재 값과 비교해야 합니다. 차이가 있을 경우 OnMarketWatch를 호출하는 이벤트를 생성합니다. 그리고 바로 이 행동이 비합리적으로 보입니다. 저것들. 주말에 운전하는 유휴 OnTimer가 작동하지 않습니다. 항상 비교해야 합니다. 아마도 더 나은 솔루션이 있을 것입니다. 따라서 귀하의 버전을 보여달라고 요청합니다. 어떻게 하시겠습니까?
그리고 나는 여전히 OnChartEvent 가 있는 자전거를 변태라고 생각합니다. 왜냐하면 이를 위해서는 Market Watch에 있는 기호 수만큼 차트를 열어야 합니다.
친구 여러분, 아마도 정말 역설적인 상황이 있을 것입니다. 이론적으로 내가 올바르게 이해한다면 신호 가입자가 계정의 레버리지를 1:200에서 1:500으로 늘리면 개설 볼륨이 최소 2배 증가해야 합니다. 오른쪽 ? 그리고 보증금의 부담도 상황은 동일하며, 증가하면 볼륨도 증가해야 합니다. 구독자 중 한 명이 레버리지를 1:200에서 1:500으로, 부하를 50%에서 90%로 늘렸다고 편지를 썼습니다. 그러나 그 후에도 열린 볼륨의 볼륨은 어떤 방향으로도 변경되지 않았습니다. 동시에 그의 계정 잔액은 이를 허용하는 것 이상이어야 합니다. 내가 복사 시스템에서 뭔가를 잘못 이해하고 있는 것은 아닐까?
OnMarketwatch가 없다는 설명도 감사히 받아들입니다.
왜 이 이벤트가 MT에 없는지 이런 종류의 설명을 요구하지 않는 것이 좋습니다.
그리고 그들은 서비스 데스크에 귀하의 의견으로는 작동 방식과 거래자의 99%가 이를 필요로 하는 이유에 대한 자세한 설명과 함께 편지를 보낼 것입니다.
제 생각에는 여기에서 OnTimer()를 사용할 수 있고 X밀리초마다 이벤트를 호출할 수 있습니다.
Marketwatch에 새 틱이 도착하는 이벤트입니다. OnTick과 동일하지만 하나의 기호가 아니라 "시장 감시"에 서명된 모든 기호의 새 틱에만 반응합니다.
현재 따옴표 흐름으로 다음 OnTick이 작업하는 동안 자체 틱도 일괄 처리됩니다.
어떤 이유에서인지 많은 사람들은 이벤트가 발생하면 다른 이벤트가 동일한 Expert Advisor에 의해(즉, 병렬로) 처리되더라도 이 이벤트의 핸들러가 바로 그 자리에서 즉시 트위스트한다고 생각합니다. 이것은 사실이 아닙니다.
모든 이벤트는 하나의 Expert Advisor에 대해 하나의 공통 대기열에 정렬됩니다. 전문가가 하나씩 처리합니다. 그리고 여기에서 모든 것은 프로그래머에 달려 있습니다 - 그가 이벤트 처리를 얼마나 효과적으로 구현하는지. 그러나 프로그래머가 슈퍼이고 프로그래머가 슈퍼 수레를 가지고 있어도 이벤트가 많으면 대기열이 팽창합니다 (다른 사람의 캐릭터에서 진드기가있는 경우 더욱 그렇습니다)
외국 기호에서 진드기를 원하는 주장은 무엇입니까? "거래에 늦을 수 있기 때문에 올바른 기호를 추적하기 위해 타이머를 실행하고 싶지 않습니다." 그리고 다른 심볼의 틱 이벤트(특히 여러 심볼이 모니터링되는 경우)는 다른 이벤트의 자체 처리로 인해 대기열에서 지연될 수 있으므로 배포에 늦을 확률이 훨씬 더 높습니다.
저를 믿으십시오, 우리는 다른 사람들의 진드기에 관한 사건에 대해 논의했습니다. 따라서 그들은 "타이머를 사용하는 것이 훨씬 낫다"는 결론에 도달했습니다.
MQL4++에서 프로그래밍 방식으로 입력 매개변수를 변경 해야 할 때 extern 없이는 할 수 없습니다.
일반 변수로 작업하는 것을 막는 것은 전혀 없습니다. 대화형 표시기의 경우 실제로 외부 const 매개변수가 전혀 필요하지 않으며 사용자 자신의 상호 작용에 의해 제어되지 않습니다.
당신은 단순히 게으르고 비합리적인 초과를 요구합니다. 이미 작동하는 대안이 있기 때문에 자신이 사용하지 않을 것입니다.
다중 모니터 소유자에게 어떤 조언을 하시겠습니까? 터미널을 사용하여 효과적인 작업을 어떻게 구성할 수 있습니까?
모든 탭과 서비스 창(도구 상자, 테스터, 시장 개요, 내비게이터, 데이터 창 , 도구 모음)을 별도의 모니터로 이동합니다.
터미널 창에는 차트만 남겨둡니다. 크기와 해상도 면에서 동일한 특성을 가진 나머지 여러 대의 모니터로 터미널 창 확장
왜 이 이벤트가 MT에 없는지 이런 종류의 설명을 요구하지 않는 것이 좋습니다.
그리고 그들은 서비스 데스크에 귀하의 의견으로는 작동 방식과 거래자의 99%가 이를 필요로 하는 이유에 대한 자세한 설명과 함께 편지를 보낼 것입니다.
일반 변수로 작업하는 것을 막는 것은 전혀 없습니다. 대화형 표시기의 경우 실제로 외부 const 매개변수가 전혀 필요하지 않으며 사용자 자신의 상호 작용에 의해 제어되지 않습니다.
당신은 단순히 게으르고 비합리적인 초과를 요구합니다. 이미 작동하는 대안이 있기 때문에 자신이 사용하지 않을 것입니다.
나는 차분한 추론에 대한 그런 공격적인 인식을 이해하지 못합니다. 뭔가 좋지 않은 것 같았습니다 ... 이것은 거기에 없습니다. 모든 것이 정상입니다. 진정하십시오. 당신은 R이 아닙니다 ...
제 생각에는 여기에서 OnTimer()를 사용할 수 있으며 X밀리초마다 이벤트를 호출할 수 있습니다.
필요한 기호에 표시기를 표시하고 Expert Advisor 에 사용자 지정 이벤트를 보내기 위해 이 솔루션의 보다 정확한 버전이 오랫동안 개발되었습니다.
그래서 저는 즉시 다음과 같이 썼습니다.
zaskok3 :
어떤 이유로 목발 솔루션은 타이머 또는 더 많은 변태인 OnChartEvent를 통해 제공됩니다.
Slava, 나는 당신의 논리를 잘 이해하지 못합니다:
슬라바 :
외국 기호에서 진드기를 원하는 주장은 무엇입니까? "거래에 늦을 수 있기 때문에 올바른 기호를 추적하기 위해 타이머를 실행하고 싶지 않습니다." 그리고 다른 심볼의 틱 이벤트(특히 여러 심볼이 모니터링되는 경우)는 다른 이벤트의 자체 처리로 인해 대기열에서 지연될 수 있으므로 배포에 늦을 확률이 훨씬 더 높습니다.
저를 믿으십시오, 우리 는 다른 사람들의 진드기에 관한 사건에 대해 정말로 논의했습니다. 따라서 그들은 "타이머를 사용하는 것이 훨씬 낫다" 는 결론에 도달했습니다.
타이머가 자신의 틱 에 충분하다면 OnTick의 목적은 무엇입니까? 내 논리가 제대로 작동하지 않을 수 있습니다. 그러나 나는 다음과 같이 주장한다. OnTick이 있기 때문에 OnMarketWatch가 있어야 한다. OnMarketWatch는 OnTimer를 통해 구현될 수 있으므로 OnTick에서도 동일한 작업을 수행할 수 있습니다. 따라서 OnTick의 존재는 OnMarketWatch의 존재와 동일한 근거를 가지고 있습니다. 그러나 하나는 있고 다른 하나는 그렇지 않습니다.
OnTick 대기열은 현재 OnTick을 실행하는 동안 있었던 틱에 대해 재설정됩니다(이는 Expert Advisors의 경우). 대기열의 오버플로에 대해 - 명확하지 않습니다. 주말에 타이머를 공회전하는 것은 현명하지 않습니다. Expert Advisors에서 OnTick은 모든 틱에서 작동하지 않습니다. 이러한 이유로 EA에서 간격 없이 진드기를 수집하는 것은 불가능합니다. 대기열이 재설정되며 이는 정상입니다. 오버플로가 없습니다.
zaskok3 :
Slava, 나는 당신의 논리를 잘 이해하지 못합니다:
타이머가 자신의 틱 에 충분하다면 OnTick의 목적은 무엇입니까? 내 논리가 제대로 작동하지 않을 수 있습니다. 그러나 나는 다음과 같이 주장한다. OnTick이 있기 때문에 OnMarketWatch가 있어야 한다. OnMarketWatch는 OnTimer를 통해 구현될 수 있으므로 OnTick에서도 동일한 작업을 수행할 수 있습니다. 따라서 OnTick의 존재는 OnMarketWatch의 존재와 동일한 근거를 가지고 있습니다. 그러나 하나는 있고 다른 하나는 그렇지 않습니다.
OnTick 대기열은 현재 OnTick을 실행하는 동안 있었던 틱에 대해 재설정됩니다(이는 Expert Advisors의 경우). 대기열의 오버플로에 대해 - 명확하지 않습니다. 주말에 타이머를 공회전하는 것은 현명하지 않습니다. Expert Advisors에서 OnTick은 모든 틱에서 작동하지 않습니다. 이러한 이유로 EA에서 간격 없이 진드기를 수집하는 것은 불가능합니다. 대기열이 재설정되며 이는 정상입니다. 오버플로가 없습니다.
쿼드 기능 시작에서 부드럽게 전환된 OnTick
OnTick은 요구 사항의 99%를 커버하며 간단한 프로그램을 작성할 수 있습니다.
대기열 오버플로 문제가 없습니다. 우리는 그 팽창에 대해 이야기하고 있습니다. 이벤트는 손실되지 않습니다.
개별 이벤트에 대한 별도의 대기열이 없습니다(OnTick 대기열). 하나의 Expert Advisor의 모든 이벤트에 공통적인 하나의 대기열이 있습니다.
그러나 대기열은 매우 지능적으로 이벤트로 보충됩니다. 대기열에 처리되지 않은 NewTick 이벤트 가 있으면 다른 NewTick 이벤트가 추가되지 않습니다. 대기열에 처리되지 않은 Timer 이벤트가 있으면 다른 Timer 이벤트가 대기열에 추가되지 않습니다. 등.
타이머의 합리성-불합리성에 대해 사실 타이머는 생각만큼 많은 리소스를 사용하지 않습니다. 그런데 클라이언트 터미널에서는 터미널 자체의 필요에 따라 여러 타이머가 동시에 작동합니다. 항상 실행, CPU 로드 0
OnTick은 요구 사항의 99%를 커버하며 간단한 프로그램을 작성할 수 있습니다.
99%에서 소스 코드에서 OnTick의 이름을 OnTimer로 변경하고 타이머 초기화를 한 줄 더 만들면 결과가 변경되지 않습니다. 이전과 같이 작동하고 프로그램은 여전히 간단합니다.
쿼드 기능 시작에서 부드럽게 전환된 OnTick
그러나 이것은 예입니다. 대부분 익숙합니다. 이것이 주된 이유입니다.
시간을 내어 설명해 주셔서 감사합니다. 타이머를 통해 인공 OnMarketWatch 구현을 위한 소스 코드를 코드베이스에 추가하라는 요청이 있습니다. 내 구현에서는 모든 기호의 이전 틱을 기억하고 각 타이머 단계에서 현재 값과 비교해야 합니다. 차이가 있을 경우 OnMarketWatch를 호출하는 이벤트를 생성합니다. 그리고 바로 이 행동이 비합리적으로 보입니다. 저것들. 주말에 운전하는 유휴 OnTimer가 작동하지 않습니다. 항상 비교해야 합니다. 아마도 더 나은 솔루션이 있을 것입니다. 따라서 귀하의 버전을 보여달라고 요청합니다. 어떻게 하시겠습니까?
그리고 나는 여전히 OnChartEvent 가 있는 자전거를 변태라고 생각합니다. 왜냐하면 이를 위해서는 Market Watch에 있는 기호 수만큼 차트를 열어야 합니다.
이론적으로 내가 올바르게 이해한다면 신호 가입자가 계정의 레버리지를 1:200에서 1:500으로 늘리면 개설 볼륨이 최소 2배 증가해야 합니다. 오른쪽 ?
그리고 보증금의 부담도 상황은 동일하며, 증가하면 볼륨도 증가해야 합니다.
구독자 중 한 명이 레버리지를 1:200에서 1:500으로, 부하를 50%에서 90%로 늘렸다고 편지를 썼습니다. 그러나 그 후에도 열린 볼륨의 볼륨은 어떤 방향으로도 변경되지 않았습니다. 동시에 그의 계정 잔액은 이를 허용하는 것 이상이어야 합니다.
내가 복사 시스템에서 뭔가를 잘못 이해하고 있는 것은 아닐까?
...