제 생각에는 반대로 열거를 확장할 필요는 없지만 줄여야 합니다. 따라서 DEAL_ENTRY_INOUT 은 아무 것도 하지 않는 추가 엔터티입니다.
지금 어떻게 생겼는지의 예입니다.
에; +1.0; 아이디 0
에; +0.2; 아이디 0
인/아웃; -2.0; ID 1 // 새로운 ID를 가진 새로운 포지션이 등장했지만, 그 포지션에 거래가 없고, 모든 거래는 이전 포지션의 거래이므로 커미션과 스왑은 0.0입니다.
에; +0.2; ID 1 // 목록에 나타난 첫 번째 거래이며 목록에 있는 유일한 거래입니다.
따라서 볼륨의 일부가 새 위치로 이동하지 않고 어디에도 표시되지 않으므로 위치 ID 1에 있는 볼륨의 이 부분에 대한 스왑 및 커미션은 고려되지 않습니다(파란색 및 녹색 해당 거래 목록)
이제 내가 볼 때 논리적으로 그리고 역사적으로 어떻게 되어야 하는지(MQ가 내릴 결정은 추측만 가능):
에; +1.0; 아이디 0
에; +0.2; 아이디 0
밖으로; -1.2; ID 0 // 포지션을 청산하는 데 사용되는 거래량의 일부
에; -0.8; ID 1 // 새 ID를 가진 새 위치가 나타났습니다. 잔고로 거래가 있고, 거래가 목록에 있고 첫 번째 거래입니다.
에; +0.2; ID 1 // 목록의 두 번째 거래
따라서 IN/Out 거래 유형이 전혀 필요하지 않습니다. 이 방법을 사용하면 모든 것이 올바르게 고려되고 위치의 거래 목록이 완성되므로 해당 거래에 대한 커미션 및 스왑 값을 적절하게 얻을 수 있습니다. 그리고 어떤 거래(한 부분은 청산되고 다른 부분은 새 위치를 열 때)가 한 주문의 일부인지 결정해야 하는 경우 이를 결정하는 것은 매우 쉽습니다. OUT 및 IN 거래는 동일한 시간을 갖습니다( 굵게).
https://www.mql5.com/ru/forum/162399/page3#comment_3894115
잠시 동안 위치가 반전되면 위치 ID가 변경됩니다. 이것은 도움말에 나와 있습니다. 따라서 불일치.
그게 문제가 아닙니다.
서비스 데스크는 그들이 그것을 고칠 것이고, 오늘의 빌드에서 그 수정을 사용할 수 있을 것이라고 대답했습니다.
서비스 데스크에서 그들은 그것을 고칠 것이라고 대답했으며 오늘의 빌드에서 수정 사항을 사용할 수 있습니다.
1491 - 수정되지 않았습니다.
불행하게도.
그건 그렇고, 기존 포지션 회계 시스템에서 이전 포지션을 마감한 포지션 부분과 새로운 포지션의 나머지 부분을 어떻게 나눌지 (지금은 그런 구분이 없음) 명확하지 않습니다. 문제는 언뜻보기에 보이는 것보다 더 깊은 것처럼 보입니다.
불행하게도.
그건 그렇고, 기존 포지션 회계 시스템에서 이전 포지션을 마감한 포지션 부분과 새로운 포지션의 나머지 부분을 어떻게 나눌지 (지금은 그런 구분이 없음) 명확하지 않습니다. 문제는 언뜻보기에 보이는 것보다 더 깊은 것처럼 보입니다.
ENUM_DEAL_PROPERTY_ *를 확장할 때까지는 아무 소용이 없습니다.
그래서 이것에 대해
제 생각에는 반대로 열거를 확장할 필요는 없지만 줄여야 합니다. 따라서 DEAL_ENTRY_INOUT 은 아무 것도 하지 않는 추가 엔터티입니다.
지금 어떻게 생겼는지의 예입니다.
에; +1.0; 아이디 0
에; +0.2; 아이디 0
인/아웃; -2.0; ID 1 // 새로운 ID를 가진 새로운 포지션이 등장했지만, 그 포지션에 거래가 없고, 모든 거래는 이전 포지션의 거래이므로 커미션과 스왑은 0.0입니다.
에; +0.2; ID 1 // 목록에 나타난 첫 번째 거래이며 목록에 있는 유일한 거래입니다.
따라서 볼륨의 일부가 새 위치로 이동하지 않고 어디에도 표시되지 않으므로 위치 ID 1에 있는 볼륨의 이 부분에 대한 스왑 및 커미션은 고려되지 않습니다(파란색 및 녹색 해당 거래 목록)
이제 내가 볼 때 논리적으로 그리고 역사적으로 어떻게 되어야 하는지(MQ가 내릴 결정은 추측만 가능):
에; +1.0; 아이디 0
에; +0.2; 아이디 0
밖으로; -1.2; ID 0 // 포지션을 청산하는 데 사용되는 거래량의 일부
에; -0.8; ID 1 // 새 ID를 가진 새 위치가 나타났습니다. 잔고로 거래가 있고, 거래가 목록에 있고 첫 번째 거래입니다.
에; +0.2; ID 1 // 목록의 두 번째 거래
따라서 IN/Out 거래 유형이 전혀 필요하지 않습니다. 이 방법을 사용하면 모든 것이 올바르게 고려되고 위치의 거래 목록이 완성되므로 해당 거래에 대한 커미션 및 스왑 값을 적절하게 얻을 수 있습니다. 그리고 어떤 거래(한 부분은 청산되고 다른 부분은 새 위치를 열 때)가 한 주문의 일부인지 결정해야 하는 경우 이를 결정하는 것은 매우 쉽습니다. OUT 및 IN 거래는 동일한 시간을 갖습니다( 굵게).
제 생각에는 반대로 열거를 확장할 필요는 없지만 줄여야 합니다. 따라서 DEAL_ENTRY_INOUT 은 아무 것도 하지 않는 추가 엔터티입니다.
거래는 어떤 식으로든 플랫폼에 의존하지 않는 실행 엔티티입니다. 그리고 ENTRY 플래그는 MQ 개념입니다.
시장에 하나의 거래가 있었다면 편리하더라도 둘로 나타낼 수 없습니다.
MQ가 회의에 참석하여 가상화 - 헤지 모드를 추가했습니다. 거래소를 위해 단순한 가상화라도 하는 것은 잘못된 결정입니다.
그러나 거래 속성의 확장은 잠재적인 목발 없이 편리함을 제공합니다.
거래는 어떤 식으로든 플랫폼에 의존하지 않는 실행 엔티티입니다. 그리고 ENTRY 플래그는 MQ 개념입니다.
시장에 하나의 거래가 있었다면 편리하더라도 둘로 나타낼 수 없습니다.
MQ가 회의에 참석하여 가상화 - 헤지 모드를 추가했습니다. 거래소를 위해 단순한 가상화라도 하는 것은 잘못된 결정입니다.
그러나 거래 속성의 확장은 잠재적인 목발 없이 편리함을 제공합니다.
글쎄요, 저는 제 의견을 표현했을 뿐입니다.
그리고 어떤 확장이 그 날을 구했을까요? 마찬가지로, 트랜잭션의 어느 부분이 이전 위치와 관련되고 어떤 부분이 새 위치와 관련되는지 어떻게든 결정해야 합니다.
그리고 어떤 확장이 그 날을 구했을까요? 마찬가지로, 트랜잭션의 어느 부분이 이전 위치와 관련되고 어떤 부분이 새 위치와 관련되는지 어떻게든 결정해야 합니다.
1491 - Alpari-MT5-데모. 같은 장소의 스크린샷.
단말기
리얼 틱 테스터
양초가 일치하지 않습니다. 테스터에서 푹신합니다. 또한 테스터와 단말기의 과거 시간은 1시간 차이가 난다.
터미널의 CopyTicks는 테스터에서와 같이 한 시간 동안 데이터를 반환합니다. 따라서 눈금은 막대에 완전히 해당하지 않습니다.
글쎄, 완전한 자기 불신 이있을 때 테스터 인 MT5를 어떻게 신뢰합니까? 왜 개발자들은 테스터에서 실행할 참조 테스트 Expert Advisors가 없고 명확하게 작동하는지 정확히 알지 못합니까? 완전한 혼란.