" 이러한 거래가 터미널에 도착하는 순서는 보장되지 않으므로 다른 거래가 도착한 후 일부 거래 거래가 도착하기를 기다리는 거래 알고리즘을 구축할 수 없습니다. " https://www.mql5.com/ ko/docs/event_handlers/ontradetransaction
그리고 경험상 TRADE_TRANSACTION_ORDER_DELETE , TRADE_TRANSACTION_DEAL_ADD , TRADE_TRANSACTION_HISTORY_ADD 거래는 어떤 순서로든 올 수 있습니다.
따라서 히스토리에 아직 거래 및 주문이 없지만 더 이상 주문이 없는 상황이 발생합니다. 또는 그 반대의 경우에도 여전히 주문이 있지만 이미 거래가 있습니다. 그것은 명령이 현재와 역사 모두에 있는 상황일 뿐이며 거의 불가능합니다.
사실, 그것이 그가 CTrade 클래스 사용을 거부한 이유입니다. 그는 이 모든 갈퀴를 밟습니다.
투쟁 방식 - 각 고문은 자신의 명령 목록을 유지 관리하고 상태를 모니터링합니다. 포함 "비표준"은 "주문이 전송되었지만 아직 활성 주문에 나타나지 않았습니다"(여기서 두 배로 늘릴 수 있음), "주문이 삭제되었지만 내역에 나타나지 않음"을 나타냅니다. 동시에, 네팅 중에 하나의 심볼에 대해 동시에 작업하는 데 도움이 됩니다.
MT4Orders 수준에서 이 지점을 우회하는 것이 좋습니다.
이제 불행히도 이중 주문이 있습니다. 아마도 이것 때문일 것입니다.
https://www.mql5.com/ru/forum/93352/page40#comment_13943845인가요?
https://www.mql5.com/ru/forum/93352/page40#comment_13943845인가요?
불행히도 이 목발에서도 배가 발생합니다.
디버깅 방법을 모르겠습니다.
불행히도 이 목발에서도 배가 발생합니다.
디버깅 방법을 모르겠습니다.
여기에 이유가 있습니다(다른 사람이 없다는 사실이 아님).
P.6. 가장 불쾌한. 이 버그를 해결하는 방법 MT5 - 생각해내지 못했습니다.
여기에 이유가 있습니다(다른 사람이 없다는 사실이 아님).
P.6. 가장 불쾌한. 이 버그를 해결하는 방법 MT5 - 생각해내지 못했습니다.
여기에서 "누락된" 주문에 대한 검사가 작동합니다. 그리고 그녀는 일하지 않습니다.
분명히 그는 뭔가를 망쳤습니다.
여기에서 "누락된" 주문에 대한 검사가 작동합니다. 그리고 그녀는 일하지 않습니다.
분명히 그는 뭔가를 망쳤습니다.
단락 7에서. "누락"된 것이 있지만 여전히 위치가 없습니다.
단락 7에서. "누락"된 것이 있지만 여전히 위치가 없습니다.
이것은 MT4Orders::OrdersTotal() 루프가 주문이나 위치를 볼 수 없다는 것을 의미합니까?
나는 이 순간이 해결되었다고 생각했습니다. 목록에 주문/위치가 있거나 주문이 "사라진" 것입니다. 어떻게 세 번째 일이 일어날 수 있습니까?
이것은 MT4Orders::OrdersTotal() 루프가 주문이나 위치를 볼 수 없다는 것을 의미합니까?
6항과 7항을 제외한 모든 문단 에서 한 위치가 보이는 것으로 나타난다.
나는 이 순간이 해결되었다고 생각했습니다. 목록에 주문/위치가 있거나 주문이 "사라진" 것입니다. 어떻게 세 번째 일이 일어날 수 있습니까?
당신의 고문이 어떤 종류의 질서가 있었다는 사실에 대해 아무것도 모른 채 6번 항목에 빠진다고 상상해 보십시오. 이 경우 영장실질심사에 해당하는 상황인지 알 길이 없다.
당신의 고문이 어떤 종류의 질서가 있었다는 사실에 대해 아무것도 모른 채 6번 항목에 빠진다고 상상해 보십시오. 이 경우 영장실질심사에 해당하는 상황인지 알 길이 없다.
가격과 일정 거리(스프레드가 아님)에서 한도가 사용된다면 그런 상황은 상상할 수 없습니다.
그는 항상 목록에서 정해진 순서를 볼 시간이 있습니다. 그리고 그 이후에 주문은 "잃어버리거나" 포지션이 됩니다.
나는 다른 고문이 현재 가격에 주문을 던지고 즉시 범람하기 시작했다면 그러한 상황이 가능하다는 것을 인정합니다 (p. 6).
그러나 첫 번째 EA가 MT4Orders::OrdersTotal() 목록 에서 주문(마법과 함께)을 보지 않는 이유는 여전히 설명하지 않습니다.
놀랍게도 전투 고문의 상황을 쉽게 재현했습니다. 명령 중 하나를 실행하는 순간 고문은 두 번째 명령을 보지 못했습니다.
그러나 재생산을 위해 간단한 예를 조립하려고 할 때 모든 것이 명확하게 작동합니다. 그는 실제로 코드의 어딘가에 버그를 도입한 것 같습니다.
다음은 문서에서 가져온 것입니다.
" 이러한 거래가 터미널에 도착하는 순서는 보장되지 않으므로 다른 거래가 도착한 후 일부 거래 거래가 도착하기를 기다리는 거래 알고리즘을 구축할 수 없습니다. " https://www.mql5.com/ ko/docs/event_handlers/ontradetransaction
그리고 경험상 TRADE_TRANSACTION_ORDER_DELETE , TRADE_TRANSACTION_DEAL_ADD , TRADE_TRANSACTION_HISTORY_ADD 거래는 어떤 순서로든 올 수 있습니다.
따라서 히스토리에 아직 거래 및 주문이 없지만 더 이상 주문이 없는 상황이 발생합니다. 또는 그 반대의 경우에도 여전히 주문이 있지만 이미 거래가 있습니다. 그것은 명령이 현재와 역사 모두에 있는 상황일 뿐이며 거의 불가능합니다.
사실, 그것이 그가 CTrade 클래스 사용을 거부한 이유입니다. 그는 이 모든 갈퀴를 밟습니다.
투쟁 방식 - 각 고문은 자신의 명령 목록을 유지 관리하고 상태를 모니터링합니다. 포함 "비표준"은 "주문이 전송되었지만 아직 활성 주문에 나타나지 않았습니다"(여기서 두 배로 늘릴 수 있음), "주문이 삭제되었지만 내역에 나타나지 않음"을 나타냅니다. 동시에, 네팅 중에 하나의 심볼에 대해 동시에 작업하는 데 도움이 됩니다.