그러나 제 생각에는 모든 것이 논리적입니다. 서버는 먼저 주문이 실행되었다고 보고하고 터미널은 해당 주문을 아카이브로 삭제한 다음 (나중에) 서버에서 포지션이 열렸거나 일부 오류로 인해 열리지 않았을 수 있다고 보고합니다. , 0-0이어야 합니다.
이 포럼이나 다른 곳에서 내가 관리자 Renat의 게시물(아마도 빠른 포럼)을 읽었다고 말하지는 않겠지만, 그는 주문이 서버에서 전달되는 유일한 확인은 마진 요구 사항을 확인하는 것이라고 쓴 것 같습니다. 주문이 거래소의 커넥터를 통해 "비행"하면 주문 실행이 불확실한 상황이 원칙적으로 가능하며 서버는 주문이 실행된 가격을 모릅니다
"일반" 로봇에서는 내가 설명한 경우를 전혀 눈치채지 못했습니다. 그러나 하나는 보안 시스템을 만들라는 요청을 받았습니다. 조건은 포지션이 항상 잠겨 있다는 것이었습니다(실제 포지션이든 보류 중인 주문 이든), 즉, 매수 매수는 매도 매수와 같습니다. 이 사례를 통해 상위 5위 안에 드는 주문/포지션/거래를 계산하는 뉘앙스를 알게 되었습니다.
차이점은 제가 스스로 설명했듯이:) 브로커로부터 응답을 받은 네 명은 먼저 "테이블"을 열린 주문 및 기록과 동기화한 다음 사용자에게 브로커의 응답을 알려줍니다. 5개는 즉시 이 답변을 우리에게 브로드캐스트하고 병렬로 "테이블"을 편집합니다(모든 mql 프로그램은 이 "테이블"에서 데이터를 읽습니다). 밀리세컨드 타이머를 포착하는 것은 바로 이 순간입니다. 그러나 테스터에서 이것을 실행하지 않는 이유는 무엇입니까?
동의한다. 하지만 안타깝게도 MT5에서는 MT4와 달리 거래 환경이 현실과 맞지 않을 수 있습니다. 예를 들어, 보류 주문이 몇 밀리초 동안 실행되면 아무데도 없을 수 있습니다. 그리고 OnTradeTransaction 도 여기에 도움이 되지 않습니다.
아마도 OnTrade는 내가 이해하는 한 이미 거래를 기반으로 터미널 자체에서 생성됩니다.
아니면 OnTrade 핸들러에서 지연이 발생했을 때 새로운 오픈 포지션을 감지하지 못할 수 있다는 말씀을 하고 싶으신가요?
아마도 OnTrade는 내가 이해하는 한 이미 거래를 기반으로 터미널 자체에서 생성됩니다.
아니면 OnTrade 핸들러에서 지연이 발생했을 때 새로운 오픈 포지션을 감지하지 못할 수 있다는 말씀을 하고 싶으신가요?
모든 On 기능에서. 그런 의미에서 MT5는 구멍이다. 패치할 가능성은 거의 없습니다.
모든 On 기능에서. 그런 의미에서 MT5는 구멍이다. 패치할 가능성은 거의 없습니다.
그렇다면 슬픈 일입니다. OnTrade의 의미는 사실상 상실되었습니다. 확인해야 할 것입니다. 이상적으로는 보류가 트리거될 때 OnTrade가 대략 몇 번 호출되어야 합니다.
정류장:
- 시장가 주문 생성 및 전송
- 보류 중인 주문이 기록으로 이동됨
- 주문 완료 거래 기록
- 시장 주문이 역사로 이동
- 포지션 생성
리미터의 경우:
- 한도가 활성화되고 거래가 기록됩니다.
- 보류 중인 주문이 기록으로 이동됨
- 포지션 생성
마지막 사람이 이미 자리를 갖고 있어야 하고 이전 자리가 없다고 가정한다면, 그렇지 않은 것이 논리적이지 않습니까?
OnTrade에서 거래, 포지션, 주문 등 모든 거래 상태를 확인하는 기능을 호출했습니다. 지금까지는 모든 것이 괜찮은 것 같지만 그렇게 복잡한 거래 작업 은 없었습니다.
그렇다면 슬픈 일입니다. OnTrade의 의미는 사실상 상실되었습니다. 확인해야 할 것입니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
라이브러리: MT4Orders
fxsaber , 2019.11.19 07:26
스레드가 큽니다. 아래는 관심 게시물 목록입니다.
https://www.mql5.com/ru/forum/93352/page11#comment_4071950
추신
oh-yo, 내가 왜 포럼에 올라 갔습니까? 해결되지 않은 문제가 너무 많습니다))
감사합니다. 살펴보겠습니다. 강조 표시된 것을 읽는 동안 제 생각에는 이것은 문제가 아니라 기능입니다. 데이터베이스에서, 그리고 실제로 트랜잭션의 개념은 모든 것이
쿼리를 실행하고 올바른 DB를 유지하는 데 필요한 작업이 완료되었으며 트랜잭션 후에 데이터베이스로 작업할 수 있으면 오류가 발생하지 않습니다.
조치 중 하나라도(심지어 테이블에 행을 쓰려면 둘 이상을 수행해야 하고 이전 조치가 성공적으로 완료되었는지 확인해야 함)
실패하면 변경 사항이 롤백되고 트랜잭션이 실패합니다. 내가 왜 MT에서 DBMS 수준을 기대해서는 안 된다는 사실에:)
여기에서 모든 중간 작업을 살펴보고 확인해야 합니다. 다시 한 번 이것이 더 큰 유연성을 제공하는 곳입니다.
그러나 제 생각에는 모든 것이 논리적입니다. 서버는 먼저 주문이 실행되었다고 보고하고 터미널은 해당 주문을 아카이브로 삭제한 다음 (나중에) 서버에서 포지션이 열렸거나 일부 오류로 인해 열리지 않았을 수 있다고 보고합니다. , 0-0이어야 합니다.
더 확인해보고 결과에 대해 포스팅하겠습니다.
그러나 제 생각에는 모든 것이 논리적입니다. 서버는 먼저 주문이 실행되었다고 보고하고 터미널은 이를 아카이브로 삭제한 다음 (나중에) 서버가 포지션을 열었다고 보고합니다
역사와 현재의 질서에는 질서가 없다. 그리고 입장이 없습니다. 즉, 아무것도 없습니다.
그러나 제 생각에는 모든 것이 논리적입니다. 서버는 먼저 주문이 실행되었다고 보고하고 터미널은 해당 주문을 아카이브로 삭제한 다음 (나중에) 서버에서 포지션이 열렸거나 일부 오류로 인해 열리지 않았을 수 있다고 보고합니다. , 0-0이어야 합니다.
이 포럼이나 다른 곳에서 내가 관리자 Renat의 게시물(아마도 빠른 포럼)을 읽었다고 말하지는 않겠지만, 그는 주문이 서버에서 전달되는 유일한 확인은 마진 요구 사항을 확인하는 것이라고 쓴 것 같습니다. 주문이 거래소의 커넥터를 통해 "비행"하면 주문 실행이 불확실한 상황이 원칙적으로 가능하며 서버는 주문이 실행된 가격을 모릅니다
fxsaber가 제공한 예 외에도 실제로 지연과 열린 위치 모두에 티켓이 있는 또 다른 경우가 있습니다. 상황은 또한 몇 밀리초 동안 계속됩니다(최신 빌드에서는 확인하지 않았지만). 검증 메커니즘이 달라야 하니 미리 준비하세요 :)
저는 MT4 고문의 경우 모든 것이 MT4에서와 같은 방식으로 MT5에 남아 있도록 이 상황을 처리합니다. 그러나 팬텀 주문의 경우 추가해야 합니다.
"일반" 로봇에서는 내가 설명한 경우를 전혀 눈치채지 못했습니다. 그러나 하나는 보안 시스템을 만들라는 요청을 받았습니다. 조건은 포지션이 항상 잠겨 있다는 것이었습니다(실제 포지션이든 보류 중인 주문 이든), 즉, 매수 매수는 매도 매수와 같습니다. 이 사례를 통해 상위 5위 안에 드는 주문/포지션/거래를 계산하는 뉘앙스를 알게 되었습니다.
차이점은 제가 스스로 설명했듯이:) 브로커로부터 응답을 받은 네 명은 먼저 "테이블"을 열린 주문 및 기록과 동기화한 다음 사용자에게 브로커의 응답을 알려줍니다. 5개는 즉시 이 답변을 우리에게 브로드캐스트하고 병렬로 "테이블"을 편집합니다(모든 mql 프로그램은 이 "테이블"에서 데이터를 읽습니다). 밀리세컨드 타이머를 포착하는 것은 바로 이 순간입니다. 그러나 테스터에서 이것을 실행하지 않는 이유는 무엇입니까?
결론부터 말하자면...