거래 환경에서 작업할 때 일반적인 실수와 이를 제거하는 방법 - 페이지 2

 

fxsaber :

함수는 래퍼가 필요함을 나타내는 빨간색으로 표시됩니다. 그녀의 문제는 여기 에 설명되어 있습니다. 누군가는 이것이 고대에 Sleep을 통해 해결되었던 포지션을 다시 여는 고대 문제라는 것을 기억하고 OrderSend 이후에 포지션이 열리기를 기다리게 될 것입니다. 그러나 사실 이 문제는 OrderSend와 아무 관련이 없습니다. 거래 환경을 올바르게 읽을 수 있어야 합니다.

간단한 예에 대한 올바른 옵션 ...

위치 목록과 마찬가지로 주문 목록은 즉시 업데이트되지 않습니다. 잠목발 없이는 하지말아요.

아마도 더 정확하게 통해 거래 중 거래

 
Aleksey Lebedev :

위치 목록과 마찬가지로 주문 목록은 즉시 업데이트되지 않습니다. 잠목발 없이는 하지말아요.

아마도 더 정확하게 통해 거래 중 거래

거래 환경의 업데이트를 기다리는 것이 문제라면 Sleep이 어떻게 도움이 될까요? 그는 돕거나 하지 않습니다.

따라서 접근 방식은 반대편에 있어야 합니다. 포지션을 열거나 보류 중인 주문을 하기 위해 주문을 보내십시오. 결과를 기다려야 하며 더 이상 열거나 배치할 주문을 보내지 마십시오. 이것은 우리가 스스로 관리하고 프로그램 실행을 지연시킬 뿐인 Sleep을 신뢰하지 않는 플래그가 필요하다는 것을 의미합니다. that - 플래그를 설정하고 이미 결과를 기다리는 논리에서 작동합니다. 우리는 결과를 기다렸습니다. 그들은 깃발을 제거했습니다.

 
Artyom Trishkin :

질문: 거래 요청을 보낸 후 다음 틱까지 시장가 주문이 서버에 의해 배치되지 않으면 어떻게 됩니까?

MT4와 정확히 동일합니다. 아무것도 없으면 계산되지 않습니다.


우리는 그러한 거래 주문이 나타나는 몇 가지 이유에 대해 이야기할 수 있습니다.

  1. 타사 OrderSend 또는 OrderSendAsync - 거래 환경을 읽는 프로그램이 아닙니다. 프로그램이 실행되는 터미널에서도 아닐 수 있습니다. 이 경우 아무 것도 할 수 없습니다. 이러한 상황에서는 모든 것이 MT4와 동일합니다.
  2. 자체 OrderSend 또는 OrderSendAsync - 거래 환경도 읽는 프로그램에서 시작됩니다. OrderSend의 경우 모든 것이 명확합니다. OrderSend는 명확한 결과로 실행을 마칩니다. OrderSendAsync의 경우 두 가지 작업을 수행할 수 있습니다 . 첫 번째 패러다임 에 따라 다음 이벤트에 데이터를 전달하거나 MT4에서 일반 비동기 데이터 전송을 시뮬레이션할 때 수행되는 것처럼 OrdersAsyncWait()(코드가 없음)를 수행합니다. (여러 거래 스레드를 통한 구현).
MT4의 OrderSendAsync에 대해 몇 마디 말할 가치가 있습니다. 거기에서 프로그램 실행의 모든 단계에서 해당 거래 흐름의 사용과 정확히 무엇을 사용하는지 볼 수 있습니다. 이러한 의미에서 MT4의 이러한 사용자 지정 비동기는 MT5의 표준 비동기보다 훨씬 더 많은 기회를 제공합니다. 그러나 MT4에서는 각 차트의 "클라이언트" 시작을 통해 구현됩니다. 값비싼. MT5에서는 많은 차트 없이도 동일한 기능을 작성할 수 있습니다. OBJ_CHART 개체에서 스크립트를 실행하지만 여전히 약간의 지연이 있습니다. 저것들. OrderSendAsyncCustom은 일반 OrderSendAsync에 비해 실행 속도가 약간 떨어지지만 OrderSend보다 훨씬 빠를 것이며 사용자 정의 구현의 모든 이점을 보너스로 제공합니다.
 
Aleksey Lebedev :

위치 목록과 마찬가지로 주문 목록은 즉시 업데이트되지 않습니다. 잠목발 없이는 하지말아요.

아마도 더 정확하게 통해 거래 중 거래

MqlTradeTransaction은 OrderSendAsync로 작업할 때 적절한 패러다임을 선택한 경우에만 필요할 수 있습니다. 다른 경우 OnTradeTransaction == OnTrade는 의미상 OnTick 또는 OnTimer보다 더 많은 역할을 하지 않습니다.


OnTradeTransaction 에서 사용해야 합니다. 캐시는 필수 정보가 아니며 속도 향상을 위해서만 사용됩니다. 따라서 즉시 고려되지 않습니다.

  • 이벤트 입력(OnTick, OnTimer 등)은 서로 종속되지 않습니다. 모든 항목은 깨끗한 슬레이트입니다. 대략, 각 이벤트에 대해 독자적으로 실행하는 스크립트 와 같습니다.
  • 강조 표시된 것은 동일한 거래 코드 가 각 On-function에서 실행됨을 의미합니다. 적절한 비 거래 코드가 나머지를 수행합니다.

     
    fxsaber :

    MT4와 정확히 동일합니다. 아무것도 없으면 계산되지 않습니다.

    음, 즉 - 다음 틱에서 프로그램은 열기 위해 새 요청을 보냅니다. 결과적으로 동일한 문제가 있습니다. 즉, 여러 개입니다.

    로직은 EA에서 다음과 같아야 합니다.

    1. 포지션을 열거나 보류 주문 을 하라는 신호를 받았습니다.
    2. 새로운 주문/포지션을 여는 데 적합하지 않은 주문/포지션의 수를 확인했습니다. 종료(1단계로)
    3. 서버 응답을 기다리는 플래그를 확인했습니다.
      1. 플래그가 켜져 있음 - 종료(항목 1로)
      2. 플래그 다운 - 계속
    4. 대기 플래그가 생략되었습니다. 거래 요청을 보내고(시도 횟수가 제한됨) 반환 코드를 확인합니다.
      1. 주문이 실행됩니다 - 우리는 대기 플래그를 설정합니다
      2. 주문이 실행되지 않았습니다. 거래 주문을 조정하는 함수를 호출하고 4단계로 이동합니다.
    5. 대기 플래그 발생 - 거래 환경의 변화 확인
      1. 거래 환경은 변경되지 않았습니다 - 종료(포인트 1로)
      2. 거래 환경이 변경되었습니다 - 보류 주문이 제출되었거나 포지션이 열렸습니다 - 대기 플래그를 제거하고 종료(1단계로)
     
    Artyom Trishkin :

    음, 즉 - 다음 틱에서 프로그램은 열기 위해 새 요청을 보냅니다. 결과적으로 동일한 문제가 있습니다. 즉, 여러 개입니다.

    전체 게시물을 읽는 것이 좋을 것입니다.

    로직은 EA에서 다음과 같아야 합니다.

    1. 포지션을 열거나 보류 주문 을 하라는 신호를 받았습니다.
    2. 새로운 주문/포지션을 여는 데 적합하지 않은 주문/포지션의 수를 확인했습니다. 종료(1단계로)
    3. 서버 응답 대기 플래그를 확인했습니다 .
      1. 플래그가 켜져 있음 - 종료(항목 1로)
      2. 플래그 다운 - 계속
    4. 대기 플래그가 생략되었습니다. 거래 요청을 보내고(시도 횟수가 제한됨) 반환 코드를 확인합니다.
      1. 주문이 실행됩니다 - 우리는 대기 플래그를 설정합니다
      2. 주문이 실행되지 않았습니다. 거래 주문을 조정하는 함수를 호출하고 4단계로 이동합니다.
    5. 대기 플래그 발생 - 거래 환경의 변화 확인
      1. 거래 환경은 변경되지 않았습니다 - 종료(포인트 1로)
      2. 거래 환경이 변경되었습니다 - 보류 주문이 제출되었거나 포지션이 열렸습니다 - 대기 플래그를 제거하고 종료(1단계로)

    대기 플래그는 두 번째 경우 와 OrderSendAsync에만 가능합니다. OrderSend에는 대기 플래그가 전혀 필요하지 않습니다. 대기 플래그가 없는 OrderSendAsync - OrdersAsyncWait().

    어떤 이론이든 실제로 테스트할 수 있습니다.

    나는 실질적인 결과에 의해 인도됩니다.
     
    fxsaber :

    전체 게시물을 읽는 것이 좋을 것입니다.

    대기 플래그는 두 번째 경우 와 OrderSendAsync에만 가능합니다. OrderSend에는 대기 플래그가 전혀 필요하지 않습니다. 대기 플래그가 없는 OrderSendAsync - OrdersAsyncWait().

    어떤 이론이든 실제로 테스트할 수 있습니다.

    나는 실질적인 결과에 의해 인도됩니다.

    글쎄, 나는 또한 비동기 모드에 대해 썼다. 동기식을 사용하면 기다릴 필요가 없습니다. 결과는 이미 요청에 대한 응답에 있습니다.

     
    Artyom Trishkin :

    글쎄, 나는 또한 비동기 모드에 대해 썼다.

    자세한 답변 은 초기에 제공되었습니다.

     
    fxsaber :

    자세한 답변 은 초기에 제공되었습니다.

    제가 잘못 읽었나 봅니다 :)

    나는 여러 개 열림의 오류를 우회하는 단계를 보지 못했습니다. 일반적인 "패러다임"만;)

    그렇기 때문에 중복되는 예시적인 논리를 던졌습니다. 플래그는 포지션 열기/대기 주문 설정을 위한 함수(래퍼)에서 확인됩니다. 또는 신호 추적 기능에서.

    무엇이 최선인지 생각해야 합니다.

     
    Artyom Trishkin :

    플래그는 오픈 포지션/보류 주문 설정을 위한 함수(래퍼)에서 확인됩니다. 또는 신호 추적 기능에서.

    On-function의 종료가 항상 일시 중단된 상태 없이 수행되는 경우 OrdersAsyncWait() 솔루션이 훨씬 더 마음에 듭니다. 그런 다음 처음부터 거래 환경을 읽는 것이 가능한 한 적절합니다.

    OrderSendAsync를 사용 하는 것은 항상 의미가 있습니다. 이것이 발생하는 유일한 상황은 여러(> 1)개의 독립적인 거래 주문이 하나의 신호로 전송되는 경우입니다. 따라서 다른 모든 경우에 OrderSendAsync를 차단하는 것은 의미가 없습니다.


    위협 OrderSendAsync가 매우 관련성이 높은 별도의 주제가 있습니다. 다중 어드바이저: 하나의 어드바이저에 여러 독립 TS가 있습니다. OrderSend는 거의 적합하지 않으며 OrderAsyncWait( const string Symb )조차도 원칙적으로 Sleep이 허용되지 않기 때문에 적합하지 않습니다.