예, "5줄" 쓰기에서 SB의 도움으로 해결되지 않는 경우 이것이 제가 찾고 있던 솔루션입니다.
그러나 하나의 SB CTrade 가 내 문제를 해결할 수 없다는 것을 얼마나 이해했습니까? 그리고 CPositionInfo를 사용해야 했나? - 여러 TF에서 동시에 9개 포지션을 함께 하고 싶다면?
추신: 저는 스마트 TV에 앉아서 MQL5 도움말을 스크롤하고 있습니다. 거래 기능 이 아주 잘 설명되어 있고 SB의 사용이 의심스럽습니다. ... 원시 전략은 SB를 사용하는 것이 합리적으로 보이지만 조금 더 복잡합니다. 기능이 충분하지 않거나 명확하지 않은 사용, 아마도 연습이 필요할 수 있습니다. "비틀림"을 더 많이 시도할 것입니다.
다시 한번 감사합니다!
테스터의 "오픈-클로즈 포지션"의 경우 - 규범, 음, 또는 교체용 교육 코드. 나머지는 다양한 뉘앙스를 고려하여 거래 작업을 수행하기 위한 본격적인 수업을 구성하기 위해 직접 하거나 CTrade에서 상속받아야 합니다. SB에는 훨씬 더 좋은 것들이 있습니다 - 당신은 그것에 대해 알고 사용합니다.
그래서 이 좋은 것들은 오해의 소지가 있습니다! - 수년 동안 SB 개발자들이 핥아서 원하는 기능을 만들었으면 하는 바램이 있었고, 저는 그냥 2클릭으로 SB를 못쓰는 유저일뿐 유저가 아닌걸로 밝혀졌습니다- 슬픔, 일반적으로 슬픔 !!!
추신: MQL5 도움말은 매우 정교하고 주문으로 가득 차 있습니다... 하지만 그들은 말했습니다 - 당신이 단어 순서를 잊어버릴 때까지 당신은 희망이 없습니다!!!
여기에서는 모든 것이 간단합니다. 주문 -> 거래 -> 포지션. MQL5에서는 주문에서 벗어날 수 없습니다. 주문이 있고 모든 것이 주문과 함께 시작됩니다. 우리는 서버에 거래 요청을 보내고(이것은 주문입니다), 서버는 그것을 수락/수락하지 않고 코드를 반환합니다. 때때로 - 요청이 잘못 구성된 경우 주문이 서버로 전혀 전송되지 않고 터미널 수준에서 전송이 차단됩니다. 주문이 서버로 성공적으로 전송되고 실행 대기열에 들어간 후 트랜잭션(주문 트리거 - 시장 또는 보류 중)의 결과로 이 주문이 실행(실행, 즉 거래)될 것으로 예상합니다. , 위치가 형성됩니다 (항상 네팅은 아니며 동일한 방향의 위치가있는 경우 거래량은 단순히 기존 거래량에 추가되고 반대 방향의 경우 거래량에 따라 현재 위치가 부분적으로 닫히거나 닫히거나 롤오버됨)
주문에는 자체 티켓도 있습니다. 마치 거래와 포지션처럼. 그러나 위치에는 식별자도 있습니다. 위치 ID는 항상 첫 번째 주문의 티켓(이 위치를 여는 주문)과 동일합니다.
시장가 주문에는 티켓만 있습니다. 그리고 해당 위치 식별자 속성은 주문이 트리거될 때까지 채워지지 않습니다. 즉, 역사적 주문에만 위치 식별자가 있습니다. 이 식별자는 거래가 이루어진 순간에 채워집니다. 이 주문이 실행되는 순간입니다. 이것이 원격 보류 주문 인 경우 해당 위치 식별자도 채워지지 않습니다. 각각에 대한 거래나 위치가 없습니다.
거래에는 티켓(해당 티켓), 주문 ID(이 거래의 결과로 생성됨) 및 위치 ID(이 거래의 결과로 나타난 위치 또는 다음으로 인해 변경된 위치)가 있습니다. 이 거래
위치에는 열리거나 수정될 때 할당되는 티켓이 있습니다. 위치가 막 열리면 해당 티켓은 해당 식별자와 동일합니다. 즉, 해당 위치의 수명 동안 변경되지 않는 고유한 위치 번호입니다. 위치의 티켓이 반복적으로 변경되고 주문의 티켓과 일치할 수 있지만 이 주문을 실행한 결과 이 위치를 변경하는 새 트랜잭션이 나타납니다. 이 주문의 티켓은 해당 위치의 티켓에 할당됩니다.
한 위치에서 이러한 모든 변형을 주의 깊게 관찰하면 부분적으로 닫혀 있을 때 mql4의 위치 동작을 쉽게 볼 수 있습니다. 해당 위치의 티켓도 변경됩니다.
주문에는 자체 티켓도 있습니다. 마치 거래와 포지션처럼. 그러나 위치에는 식별자도 있습니다. 위치 ID는 항상 첫 번째 주문의 티켓(이 위치를 여는 주문)과 동일합니다.
시장가 주문에는 티켓만 있습니다. 그리고 해당 위치 식별자 속성은 주문이 트리거될 때까지 채워지지 않습니다. 즉, 역사적 주문에만 위치 식별자가 있습니다. 이 식별자는 거래가 이루어진 순간에 채워집니다. 이 주문이 실행되는 순간입니다. 이것이 원격 보류 주문 인 경우 해당 위치 식별자도 채워지지 않습니다. 각각에 대한 거래나 위치가 없습니다.
거래에는 티켓(해당 티켓), 주문 ID(이 거래의 결과로 생성됨) 및 위치 ID(이 거래의 결과로 나타난 위치 또는 다음으로 인해 변경된 위치)가 있습니다. 이 거래
위치에는 열리거나 수정될 때 할당되는 티켓이 있습니다. 위치가 막 열리면 해당 티켓은 해당 식별자와 동일합니다. 즉, 해당 위치의 수명 동안 변경되지 않는 고유한 위치 번호입니다. 위치의 티켓이 반복적으로 변경되고 주문의 티켓과 일치할 수 있지만 이 주문을 실행한 결과 이 위치를 변경하는 새 트랜잭션이 나타납니다. 이 주문의 티켓은 해당 위치의 티켓에 할당됩니다.
한 위치에서 이러한 모든 변형을 주의 깊게 관찰하면 부분적으로 닫혀 있을 때 mql4의 위치 동작을 쉽게 볼 수 있습니다. 해당 위치의 티켓도 변경됩니다.
불일치 는 주문을 거래로 변환하는 지연으로 인한 것으로 밝혀졌습니다. 테스터에서도?... 꺼져.
그래서, 주문을 한 후, 당신은 여전히 포지션이 열렸는지 확인해야 합니다... 그리고 얼마나 기다려야 합니까? 모든 변형이 확인될 때까지 올빼미를 걸어야 합니까? 아니면 일반적으로 어떻습니까?
덕분에!
예, "5줄" 쓰기에서 SB의 도움으로 해결되지 않는 경우 이것이 제가 찾고 있던 솔루션입니다.
그러나 하나의 SB CTrade 가 내 문제를 해결할 수 없다는 것을 얼마나 이해했습니까? 그리고 CPositionInfo를 사용해야 했나? - 여러 TF에서 동시에 9개 포지션을 함께 하고 싶다면?
추신: 저는 스마트 TV에 앉아서 MQL5 도움말을 스크롤하고 있습니다. 거래 기능 이 아주 잘 설명되어 있고 SB의 사용이 의심스럽습니다. ... 원시 전략은 SB를 사용하는 것이 합리적으로 보이지만 조금 더 복잡합니다. 기능이 충분하지 않거나 명확하지 않은 사용, 아마도 연습이 필요할 수 있습니다. "비틀림"을 더 많이 시도할 것입니다.
다시 한번 감사합니다!
테스터의 "오픈-클로즈 포지션"의 경우 - 규범, 음, 또는 교체용 교육 코드. 나머지는 다양한 뉘앙스를 고려하여 거래 작업을 수행하기 위한 본격적인 수업을 구성하기 위해 직접 하거나 CTrade에서 상속받아야 합니다.
SB에는 훨씬 더 좋은 것들이 있습니다 - 당신은 그것에 대해 알고 사용합니다.
오류가 없기 때문에 목록은 HistorySelectByPosition을 통해 구성됩니다.
예, 나는 이것이 완전한 목록이 아니라는 것을 간과했습니다.
SB에는 훨씬 더 좋은 것들이 있습니다 - 당신은 그것에 대해 알고 사용합니다.
그래서 이 좋은 것들은 오해의 소지가 있습니다! - 수년 동안 SB 개발자들이 핥아서 원하는 기능을 만들었으면 하는 바램이 있었고, 저는 그냥 2클릭으로 SB를 못쓰는 유저일뿐 유저가 아닌걸로 밝혀졌습니다- 슬픔, 일반적으로 슬픔 !!!
추신: MQL5 도움말은 매우 정교하고 주문으로 가득 차 있습니다... 하지만 그들은 말했습니다 - 당신이 단어 순서를 잊어버릴 때까지 당신은 희망이 없습니다!!!
그래서 이 좋은 것들은 오해의 소지가 있습니다! - 수년 동안 SB 개발자들이 핥아서 원하는 기능을 만들었으면 하는 바램이 있었고, 저는 그냥 2클릭으로 SB를 못쓰는 유저일뿐 유저가 아닌걸로 밝혀졌습니다- 슬픔, 일반적으로 슬픔 !!!
추신: MQL5 도움말은 매우 정교하고 주문으로 가득 차 있습니다... 하지만 그들은 말했습니다 - 당신이 단어 순서를 잊어버릴 때까지 당신은 희망이 없습니다!!!
여기에서는 모든 것이 간단합니다. 주문 -> 거래 -> 포지션. MQL5에서는 주문에서 벗어날 수 없습니다. 주문이 있고 모든 것이 주문과 함께 시작됩니다. 우리는 서버에 거래 요청을 보내고(이것은 주문입니다), 서버는 그것을 수락/수락하지 않고 코드를 반환합니다. 때때로 - 요청이 잘못 구성된 경우 주문이 서버로 전혀 전송되지 않고 터미널 수준에서 전송이 차단됩니다. 주문이 서버로 성공적으로 전송되고 실행 대기열에 들어간 후 트랜잭션(주문 트리거 - 시장 또는 보류 중)의 결과로 이 주문이 실행(실행, 즉 거래)될 것으로 예상합니다. , 위치가 형성됩니다 (항상 네팅은 아니며 동일한 방향의 위치가있는 경우 거래량은 단순히 기존 거래량에 추가되고 반대 방향의 경우 거래량에 따라 현재 위치가 부분적으로 닫히거나 닫히거나 롤오버됨)
주문에는 자체 티켓도 있습니다. 마치 거래와 포지션처럼. 그러나 위치에는 식별자도 있습니다. 위치 ID는 항상 첫 번째 주문의 티켓(이 위치를 여는 주문)과 동일합니다.
시장가 주문에는 티켓만 있습니다. 그리고 해당 위치 식별자 속성은 주문이 트리거될 때까지 채워지지 않습니다. 즉, 역사적 주문에만 위치 식별자가 있습니다. 이 식별자는 거래가 이루어진 순간에 채워집니다. 이 주문이 실행되는 순간입니다. 이것이 원격 보류 주문 인 경우 해당 위치 식별자도 채워지지 않습니다. 각각에 대한 거래나 위치가 없습니다.
거래에는 티켓(해당 티켓), 주문 ID(이 거래의 결과로 생성됨) 및 위치 ID(이 거래의 결과로 나타난 위치 또는 다음으로 인해 변경된 위치)가 있습니다. 이 거래
위치에는 열리거나 수정될 때 할당되는 티켓이 있습니다. 위치가 막 열리면 해당 티켓은 해당 식별자와 동일합니다. 즉, 해당 위치의 수명 동안 변경되지 않는 고유한 위치 번호입니다. 위치의 티켓이 반복적으로 변경되고 주문의 티켓과 일치할 수 있지만 이 주문을 실행한 결과 이 위치를 변경하는 새 트랜잭션이 나타납니다. 이 주문의 티켓은 해당 위치의 티켓에 할당됩니다.
한 위치에서 이러한 모든 변형을 주의 깊게 관찰하면 부분적으로 닫혀 있을 때 mql4의 위치 동작을 쉽게 볼 수 있습니다. 해당 위치의 티켓도 변경됩니다.
위치에서 이러한 모든 변형을주의 깊게 관찰하면
고맙습니다! 그래서 나는 두 번째 날을보고 있지만 여기서는 연습 만 필요합니다. 오늘은 안보리와 함께 알아 냈습니다 ... 글쎄, 일반적으로 알아 냈습니다.)
추신: 당신은 잘 설명, 확실히 재능입니다!
고맙습니다! 그래서 나는 두 번째 날을보고 있지만 여기서는 연습 만 필요합니다. 오늘은 안보리와 함께 알아 냈습니다 ... 글쎄, 일반적으로 알아 냈습니다.)
추신: 당신은 잘 설명, 확실히 재능입니다!
도와드리게 되어 기쁩니다 ;)
..................
주문에는 자체 티켓도 있습니다. 마치 거래와 포지션처럼. 그러나 위치에는 식별자도 있습니다. 위치 ID는 항상 첫 번째 주문의 티켓(이 위치를 여는 주문)과 동일합니다.
시장가 주문에는 티켓만 있습니다. 그리고 해당 위치 식별자 속성은 주문이 트리거될 때까지 채워지지 않습니다. 즉, 역사적 주문에만 위치 식별자가 있습니다. 이 식별자는 거래가 이루어진 순간에 채워집니다. 이 주문이 실행되는 순간입니다. 이것이 원격 보류 주문 인 경우 해당 위치 식별자도 채워지지 않습니다. 각각에 대한 거래나 위치가 없습니다.
거래에는 티켓(해당 티켓), 주문 ID(이 거래의 결과로 생성됨) 및 위치 ID(이 거래의 결과로 나타난 위치 또는 다음으로 인해 변경된 위치)가 있습니다. 이 거래
위치에는 열리거나 수정될 때 할당되는 티켓이 있습니다. 위치가 막 열리면 해당 티켓은 해당 식별자와 동일합니다. 즉, 해당 위치의 수명 동안 변경되지 않는 고유한 위치 번호입니다. 위치의 티켓이 반복적으로 변경되고 주문의 티켓과 일치할 수 있지만 이 주문을 실행한 결과 이 위치를 변경하는 새 트랜잭션이 나타납니다. 이 주문의 티켓은 해당 위치의 티켓에 할당됩니다.
한 위치에서 이러한 모든 변형을 주의 깊게 관찰하면 부분적으로 닫혀 있을 때 mql4의 위치 동작을 쉽게 볼 수 있습니다. 해당 위치의 티켓도 변경됩니다.
불일치 는 주문을 거래로 변환하는 지연으로 인한 것으로 밝혀졌습니다. 테스터에서도?... 꺼져.
그래서, 주문을 한 후, 당신은 여전히 포지션이 열렸는지 확인해야 합니다... 그리고 얼마나 기다려야 합니까? 모든 변형이 확인될 때까지 올빼미를 걸어야 합니까? 아니면 일반적으로 어떻습니까?
불일치 는 주문을 거래로 변환하는 지연으로 인한 것으로 밝혀졌습니다. 테스터에서도?... 꺼져.
그래서, 주문을 한 후, 당신은 여전히 포지션이 열렸는지 확인해야 합니다... 그리고 얼마나 기다려야 합니까? 모든 변형이 확인될 때까지 올빼미를 걸어야 합니까? 아니면 일반적으로 어떻습니까?
우리는 거래 주문(거래 티켓을 기억함)을 설정하고 대기 플래그를 올렸습니다. OnTradeTransaction에서 보장된 작업을 얻는 즉시 거래 유형 TRADE_TRANSACTION_DEAL_ADD - 거래 티켓을 확인합니다. 모든 것이 일치한다면 괜찮습니다.
이것은 실생활입니다. 이벤트는 다른 간격으로 올 수 있고 통신 중단이 가능합니다 ... 예, 많은 일이 있을 수 있습니다. 이것은 현실입니다. 단단한 사슬은 없습니다.
우리는 거래 요청(거래 티켓 기억)을 넣고 대기 플래그를 올렸습니다. OnTradeTransaction에서 보장된 작업을 얻는 즉시 거래 유형 TRADE_TRANSACTION_DEAL_ADD가 거래 티켓을 확인합니다. 모든 것이 일치한다면 괜찮습니다.
이것은 실생활입니다. 이벤트는 다른 간격으로 올 수 있고 통신 중단이 가능합니다 ... 예, 많은 일이 있을 수 있습니다. 이것은 현실입니다. 단단한 사슬은 없습니다.
글쎄, 이것은 사실 고문을 교수형에 처한 것입니다 ... 확인이 올 때까지 기다리십시오 또는 오지 않을 것입니다 ... 뭔가 혼란 스럽습니다 ... 이 기대치를 어떻게 구성합니까? while()을 통해?
글쎄, 이것은 사실 고문을 교수형에 처한 것입니다 ... 확인이 올 때까지 기다리십시오 또는 오지 않을 것입니다 ... 뭔가 혼란 스럽습니다 ... 이 기대치를 어떻게 구성합니까? while()을 통해?
아니요. Sleep 및 While은 엄격히 금지됩니다.