저것들. 대략적으로 말하면, 주문을 보낸 후 retcode를 분석하지 않고 "AllowTrade" 플래그를 사용하여 작업 주기(OnTick())에서 거래 작업을 비활성화합니다.
거래 금지는 번호로 주문을 검색하고 그 운명을 분석한 후 OnTrade()에서만 잠금 해제됩니다.
두 가지 질문이 있습니다.
1. OnTrade에서 주문 티켓을 어떤 주제로 확인해야 하나요? 그의 인생에서 최종적인 지위는 무엇입니까?
2. Tick-events(OnTick) 대기열이 "삭제"될 수 있다는 것을 알고 있습니다. 저것들. 다음 Tick 이벤트가 도착하고 OnTick 기능(이전 Tick에서)이 아직 작업을 완료하지 않은 경우 현재 이벤트가 "삭제"됩니다. 처리되지 않습니다. Trade 이벤트(OnTrade)와 유사한 접근 방식이 있습니까? 저것들. 예를 들어 메인 주기에서 거래 금지를 설정하고 방금 보낸 주문에 대한 OnTrade 이벤트가 "삭제"될 가능성이 있습니까? 도착 시 해당 거래 요청 을 보내는 것과 동일한 틱으로 다른 것을 계속 처리합니까?
Yedelkin : MqlTradeResult 유형의 변수를 사용하기 전에 일반적으로 0으로 설정됩니다. 따라서 Result.order 필드에는 null 값이 포함됩니다. 거래 요청 이 실패한 후 이 필드가 다른 값을 취하는 것을 본 적이 없습니다.
괜찮으시다면 반환 코드 해석 문제에 대해 자세히 알아보도록 하겠습니다. 선언된 30개의 답변 옵션(선언되지 않은 답변이 발생하지 않기를 바랍니다) 중 24개는 주문을 분명히 거부합니다. 나머지 6개: 1. TRADE_RETCODE_PLACED 지연기를 설정하지 않는다고 가정해 보겠습니다. 시장(SYMBOL_TRADE_EXECUTION_MARKET)에서 거래할 때 이러한 대응이 가능한가요? 2. TRADE_RETCODE_DONE 그러면 아무것도 다시 확인할 필요가 없습니다. 모든 것이 고문이 요구한 대로 진행되었습니다. 3. TRADE_RETCODE_DONE_PARTIAL 내 생각에 우리가 지연기를 거래하지 않는다면 이 답변은 ORDER_FILLING_IOC 모드를 고려할 때 TRADE_RETCODE_DONE과 유사합니다. 4. TRADE_RETCODE_ORDER_CHANGED 이것은 우리 무역 주문에 대한 명백한 거부를 의미합니까? 5. TRADE_RETCODE_LOCKED 최악의 경우라고 생각합니다. 이 경우 어떻게 진행합니까? 아직 영장이 없는 것 같아요. 거래 흐름이 바쁘다. 거래가 불가능하며, 거래 흐름의 차단 해제에 대해 알아내는 방법이 명확하지 않습니다. 6. TRADE_RETCODE_FROZEN 이것은 우리 무역 주문에 대한 명백한 거부를 의미합니까? 각 항목에 대해 의견을 보내주십시오.
voix_kas : Если не возражаете, хотелось бы углубиться в вопрос интерпритации кодов возврата. Из 30 задекларированных вариантов ответа (будем надеятся, что с недекларированными мы не столкнёмся) 24 - указывают на явный отказ в размещении ордера. Остальные 6:
1. TRADE_RETCODE_PLACED 레이어웨이를 배치하지 않는다고 가정해 봅시다. 시장(SYMBOL_TRADE_EXECUTION_MARKET)에서 거래할 때 이러한 대응이 가능한가요?
2. TRADE_RETCODE_DONE 그러면 아무것도 다시 확인할 필요가 없습니다. 모든 것이 고문이 요구한 대로 진행되었습니다.
3. TRADE_RETCODE_DONE_PARTIAL 내 생각에 우리가 지연기를 거래하지 않는다면 이 답변은 ORDER_FILLING_IOC 모드를 고려할 때 TRADE_RETCODE_DONE과 유사합니다.
4. TRADE_RETCODE_ORDER_CHANGED 이것은 우리 무역 주문에 대한 명백한 거부를 의미합니까?
5. TRADE_RETCODE_LOCKED 최악의 경우라고 생각합니다. 이 경우 어떻게 진행합니까? 아직 영장이 없는 것 같아요. 거래 흐름이 바쁘다. 거래가 불가능하며, 거래 흐름의 차단 해제에 대해 알아내는 방법이 명확하지 않습니다.
6. TRADE_RETCODE_FROZEN 이것은 우리 무역 주문에 대한 명백한 거부를 의미합니까?
각 항목에 대해 의견을 보내주십시오.
불행히도, 나의 지식은 각 요점에 대한 본격적인 논평에 충분하지 않습니다. 글쎄, 그렇다면 동료들이 수정할 것입니다.
1. 한 포럼에서 서브 브로커로 거래 계좌를 개설할 수 있는 상황에 대해 언급했습니다. 이 경우 하위 브로커는 추가 처리를 위해 거래 요청을 (브로커에게) 보내고 TRADE_RETCODE_PLACED를 클라이언트 단말로 보낼 수 있습니다. 브로커가 결국 그러한 거래 요청을 처리할지 여부는 미리 알려지지 않았습니다.
2. 네, 저도 그렇게 생각합니다. 기억해야 할 것은 이 주문에 대한 정보가 터미널 베이스에 비동기적으로 전송된다는 것입니다.
3. ORDER_FILLING_IOC 및 ORDER_FILLING_RETURN 모드에서 거래 요청의 부분 실행에 대해 이야기하고 있다고 생각합니다.
불행히도, 나의 지식은 각 요점에 대한 본격적인 논평에 충분하지 않습니다. 글쎄, 그렇다면 동료들이 수정할 것입니다.
1. 한 포럼에서 서브 브로커로 거래 계좌를 개설할 수 있는 상황에 대해 언급했습니다. 이 경우 하위 브로커는 추가 처리를 위해 거래 요청을 (브로커에게) 보내고 TRADE_RETCODE_PLACED를 클라이언트 단말로 보낼 수 있습니다. 브로커가 결국 그러한 거래 요청을 처리할지 여부는 미리 알려지지 않았습니다.
2. 네, 저도 그렇게 생각합니다. 기억해야 할 것은 이 주문에 대한 정보가 터미널 베이스에 비동기적으로 전송된다는 것입니다.
3. ORDER_FILLING_IOC 및 ORDER_FILLING_RETURN 모드에서 거래 요청의 부분 실행에 대해 이야기하고 있다고 생각합니다.
이 주제에 대한 기사를 기다리는 동안 거래 작업 분석의 일반적인 개념을 올바르게 이해합니다.
저것들. 대략적으로 말하면, 주문을 보낸 후 retcode를 분석하지 않고 "AllowTrade" 플래그를 사용하여 작업 주기(OnTick())에서 거래 작업을 비활성화합니다.
거래 금지는 번호로 주문을 검색하고 그 운명을 분석한 후 OnTrade()에서만 잠금 해제됩니다.
두 가지 질문이 있습니다.
1. OnTrade에서 주문 티켓을 어떤 주제로 확인해야 하나요? 그의 인생에서 최종적인 지위는 무엇입니까?
2. Tick-events(OnTick) 대기열이 "삭제"될 수 있다는 것을 알고 있습니다. 저것들. 다음 Tick 이벤트가 도착하고 OnTick 기능(이전 Tick에서)이 아직 작업을 완료하지 않은 경우 현재 이벤트가 "삭제"됩니다. 처리되지 않습니다. Trade 이벤트(OnTrade)와 유사한 접근 방식이 있습니까? 저것들. 예를 들어 메인 주기에서 거래 금지를 설정하고 방금 보낸 주문에 대한 OnTrade 이벤트가 "삭제"될 가능성이 있습니까? 도착 시 해당 거래 요청 을 보내는 것과 동일한 틱으로 다른 것을 계속 처리합니까?
이 주제를 이해하지 못했지만 핸드북에서는 다음과 같이 말합니다.
이 주제를 이해하지 못했지만 핸드북에서는 다음과 같이 설명합니다.
일반적으로 이해할 수 있습니다. papaklass 가 이미 https://www.mql5.com/en/articles/232 기사에서 지적하고 언급했듯이 :
거래 계정에서 변경된 사항을 정확히 알아낼 수 있는 보장된 방법은 단 한 가지뿐입니다 . 이 방법은 거래 및 거래 이력의 상태를 기억하고 저장된 상태와 새 상태를 비교하는 것입니다.
Expert Advisor에는 서비스 블록이 하나 더 있습니다. :(
실제로 문제는... 코드 크기를 줄이는 프레임워크 내에서 모든 변수(주문/거래/포지션)를 분석하지 않고 주문에만 집중할 수 있습니까? OrderSend의 결과는? 아니면 이 번호가 고유하지 않거나 기록에 반영되지 않을 수 있습니까?
틀림없이. 거래 요청을 보낸 결과 주문 티켓을 받을 수 있었다면 이 티켓은 고유하며 이를 사용하여 주문의 전체 운명을 추적할 수 있습니다.
주문 티켓이 기록에서 어떻게 사용되는지 확인하세요: MQL5 Reference / Trade Functions / HistoryOrderGetInteger
틀림없이. 거래 요청을 보낸 결과 주문 티켓을 받을 수 있었다면 이 티켓은 고유하며 이를 사용하여 주문의 전체 운명을 추적할 수 있습니다.
MqlTradeResult 유형의 변수를 사용하기 전에 일반적으로 0으로 설정됩니다. 따라서 Result.order 필드에는 null 값이 포함됩니다. 거래 요청 이 실패한 후 이 필드가 다른 값을 취하는 것을 본 적이 없습니다.
voix_kas : Если не возражаете, хотелось бы углубиться в вопрос интерпритации кодов возврата. Из 30 задекларированных вариантов ответа (будем надеятся, что с недекларированными мы не столкнёмся) 24 - указывают на явный отказ в размещении ордера. Остальные 6:
1. TRADE_RETCODE_PLACED 레이어웨이를 배치하지 않는다고 가정해 봅시다. 시장(SYMBOL_TRADE_EXECUTION_MARKET)에서 거래할 때 이러한 대응이 가능한가요?
2. TRADE_RETCODE_DONE 그러면 아무것도 다시 확인할 필요가 없습니다. 모든 것이 고문이 요구한 대로 진행되었습니다.
3. TRADE_RETCODE_DONE_PARTIAL 내 생각에 우리가 지연기를 거래하지 않는다면 이 답변은 ORDER_FILLING_IOC 모드를 고려할 때 TRADE_RETCODE_DONE과 유사합니다.
4. TRADE_RETCODE_ORDER_CHANGED 이것은 우리 무역 주문에 대한 명백한 거부를 의미합니까?
5. TRADE_RETCODE_LOCKED 최악의 경우라고 생각합니다. 이 경우 어떻게 진행합니까? 아직 영장이 없는 것 같아요. 거래 흐름이 바쁘다. 거래가 불가능하며, 거래 흐름의 차단 해제에 대해 알아내는 방법이 명확하지 않습니다.
6. TRADE_RETCODE_FROZEN 이것은 우리 무역 주문에 대한 명백한 거부를 의미합니까?
각 항목에 대해 의견을 보내주십시오.
불행히도, 나의 지식은 각 요점에 대한 본격적인 논평에 충분하지 않습니다. 글쎄, 그렇다면 동료들이 수정할 것입니다.
1. 한 포럼에서 서브 브로커로 거래 계좌를 개설할 수 있는 상황에 대해 언급했습니다. 이 경우 하위 브로커는 추가 처리를 위해 거래 요청을 (브로커에게) 보내고 TRADE_RETCODE_PLACED를 클라이언트 단말로 보낼 수 있습니다. 브로커가 결국 그러한 거래 요청을 처리할지 여부는 미리 알려지지 않았습니다.
2. 네, 저도 그렇게 생각합니다. 기억해야 할 것은 이 주문에 대한 정보가 터미널 베이스에 비동기적으로 전송된다는 것입니다.
3. ORDER_FILLING_IOC 및 ORDER_FILLING_RETURN 모드에서 거래 요청의 부분 실행에 대해 이야기하고 있다고 생각합니다.
4. https://www.mql5.com/ru/forum/1111/page124#comment_18407
5. 나는 이 코드에 대해 전혀 모른다. 공식적으로는 브로커 내부 사정으로 요청이 처리되지 않은 것으로 드러났습니다. 추후 처리 여부는 미지수다. 나 자신은 이 코드를 거래 요청 거부와 동일시합니다.
6. https://www.mql5.com/ru/forum/1111/page123#comment_18372
.. 그리고 일반적으로 - 포럼 키워드 검색을 시도하십시오. 더 많은 정보를 보실 수 있습니다:)
불행히도, 나의 지식은 각 요점에 대한 본격적인 논평에 충분하지 않습니다. 글쎄, 그렇다면 동료들이 수정할 것입니다.
1. 한 포럼에서 서브 브로커로 거래 계좌를 개설할 수 있는 상황에 대해 언급했습니다. 이 경우 하위 브로커는 추가 처리를 위해 거래 요청을 (브로커에게) 보내고 TRADE_RETCODE_PLACED를 클라이언트 단말로 보낼 수 있습니다. 브로커가 결국 그러한 거래 요청을 처리할지 여부는 미리 알려지지 않았습니다.
2. 네, 저도 그렇게 생각합니다. 기억해야 할 것은 이 주문에 대한 정보가 터미널 베이스에 비동기적으로 전송된다는 것입니다.
3. ORDER_FILLING_IOC 및 ORDER_FILLING_RETURN 모드에서 거래 요청의 부분 실행에 대해 이야기하고 있다고 생각합니다.
4. https://www.mql5.com/ru/forum/1111/page124#comment_18407
5. 나는 이 코드에 대해 전혀 모른다. 공식적으로는 브로커 내부 사정으로 요청이 처리되지 않은 것으로 드러났습니다. 추후 처리 여부는 미지수다. 나 자신은 이 코드를 거래 요청 거부와 동일시합니다.
6. https://www.mql5.com/ru/forum/1111/page123#comment_18372
.. 그리고 일반적으로 - 포럼 키워드 검색을 시도하십시오. 더 많은 정보를 확인하실 수 있습니다 :)
총 30개의 코드 중 26개(TRADE_RETCODE_ORDER_CHANGED 및 TRADE_RETCODE_FROZEN 포함) - 요청에 대한 명백한 거부(주문을 생성하지 않음)가 있습니다.
TRADE_RETCODE_DONE 및 TRADE_RETCODE_DONE_PARTIAL - 보장된 주문이 생성되었습니다.
TRADE_RETCODE_PLACED(연기가 아님) 및 TRADE_RETCODE_LOCKED를 올바르게 해결하는 방법은 질문입니다. MQ는 이 두 코드에 대한 의견을 주시면 감사하겠습니다.