2. deal_add가 트리거되지만 주문은 3차원입니다. 나는 슬립을 넣었고, 지난 며칠간 도움이 되는 것 같다. 1초 만에 명령이 기록에 도달합니다. 나는 고주파 로봇이 없고 시장 주문에 따라 일하지 않으므로 이 솔루션이 적합합니다.
3. deal_add는 2번 작동합니다. 즉, 동일한 deal_add가 2번 작동합니다. 지난 거래의 티켓을 확인하고 현재 거래의 티켓과 비교하여 해결합니다.
포인트 1이 남았습니다. 이에 대한 약간의 설명이 있습니다.
어제 나는 Sell_limit를 설정했는데 작동했고 deal_add가 왔지만 포지션이 나타나지 않았고 우리는 그대로 스탑 오더를 열었습니다. 거래 설명을 보기 시작했는데 거래 유형이 DEAL_TYPE_SELL이고 주문 유형이 ORDER_TYPE_BUY인 것을 확인했습니다. 동시에 티켓은 우리 것입니다. 어찌보면 논리적이지 않습니다. 나는 주문 유형과 거래 유형이 방향이 일치해야 한다는 Deal_add 트랜잭션에 대해 OnTradeTransaction을 확인하기로 결정했습니다.
로봇을 데모에 올려놓고 비슷한 거래가 또 나왔는데 이번에는 입장이 바뀌었다. 그러나 우리의 수표로 인해 중지 명령이 내려지지 않았습니다. 무슨 일이야?!
2019.02 . 0816 : 05 : 14 [INFO]: ( FrTrend_2_Si- 3.19 _33) TRADE_TRANSACTION_DEAL_ADDTRADE_TRANSACTION_DEAL_ADDSymbol : Si- 3.19
Deal ticket: 12677775
Deal type: DEAL_TYPE_SELL
Order ticket: 82675535
Order type: ORDER_TYPE_BUY
Order state: ORDER_STATE_STARTED
Order time type: ORDER_TIME_GTC
Order expiration: 1970.01 . 0100 : 00
Price: 66287
Price trigger: 0
Stop Loss: 0
Take Profit: 0Volume : 1
Position: 82675534
Position by: 0
prostotrader, 이것이 터미널에 오는 것이라고 즉시 말할 것입니다. 내 상상 없이.
어제 나는 Sell_limit를 설정했는데 작동했고 deal_add가 왔지만 포지션이 나타나지 않았고 우리는 그대로 스탑 오더를 열었습니다. 거래 설명을 보기 시작했는데 거래 유형이 DEAL_TYPE_SELL이고 주문 유형이 ORDER_TYPE_BUY인 것을 확인했습니다. 동시에 티켓은 우리 것입니다. 어찌보면 논리적이지 않습니다. 나는 주문 유형과 거래 유형이 방향에서 일치해야 하는 deal_add 트랜잭션에 대해 OnTradeTransaction에 체크를 하기로 결정했습니다.
그리고 여기에서 " 거래 거래의 구조 " 참조를 다시 읽을 가치가 있습니다. 거래_추가 유형에 대해 채워지는 필드의 관점에서.
그리고 트랜잭션(채워지지 않았지만 0도 열거형 유형의 일부 값에 해당)에서가 아니라 주문 자체에서 주문 속성을 가져옵니다(현재 사용 가능한 경우). 역사에 대한 명령).
새로운 거래 및 현재 주문의 마술과 해설을 자신/다른 사람의 식별자로 보기만 하면 됩니다.
작업 코드를 표시했습니다. 바로 거기입니다.
OnTradeTransaction 을 통해 문제를 해결하려는 시도는 함정의 수에 대한 좋지 않은 생각입니다. 때때로 특정 작업에서 which를 우회하는 것이 여전히 가능합니다. 그러나 작업이 약간 변경되자마자 OnTradeTransaction 구현 중에 전체 논리가 위반됩니다.
개발자는 이벤트 거래 모델을 만들었지만 단일 거래 작업 예제를 제공하지 않았습니다. 그것은 완전한 엉덩이이기 때문에 코드가 무엇에 쏟아지고 있고 얼마나 많이 각 예제에 따라 달라집니다.
따라서 동기 거래 작업과 OnTrade 기능을 찾는 것이 좋습니다. 모든 것이 훨씬 간단하고 변경에 대한 논리가 매우 유연합니다. 또한, 더 신뢰할 수 있습니다.
Async+Transactions로 전환하는 것은 고급 언어에서 어셈블리 언어로 전환하는 것과 같습니다. 저것들. 그것은 TS 생성의 가장 마지막 단계에서 수행되어야 하며, 완전히 조사되고 REAL에 대한 준비가 되어 있고 마지막으로 남은 것은 거래 논리를 변경하지 않고 거래 작업의 속도를 높이는 것입니다.
안녕하세요.
아무도 두려워하지 않았습니다.
스위치가 없습니다(trans.type)
물론 주어진 경우는 switch(trans.type)입니다. 케이스가 더 많아서 불필요한 정보가 로드되지 않도록 전체 코드를 레이아웃하지 않았습니다.
fxsaber 예를 들어 주셔서 감사합니다!
Alexey , 그게 바로 그것입니다. 그물 모드에서는 동일한 상품에 대해 2개의 다른 로봇을 거래합니다. 인용한 2개의 게시물은 서로를 보완합니다.
주요 변경 트리거인 onTradeTransaction 에서 시작하여 문제를 해결하는 것이 흥미로웠습니다.
현재 충족된 총 문제:
1. deal_add가 작동하지만 포즈가 없습니다. 아무 생각이 없는 동안
2. deal_add가 트리거되지만 주문은 3차원입니다. 나는 슬립을 넣었고, 지난 며칠간 도움이 되는 것 같다. 1초 만에 명령이 기록에 도달합니다. 나는 고주파 로봇이 없고 시장 주문에 따라 일하지 않으므로 이 솔루션이 적합합니다.
3. deal_add는 2번 작동합니다. 즉, 동일한 deal_add가 2번 작동합니다. 지난 거래의 티켓을 확인하고 현재 거래의 티켓과 비교하여 해결합니다.
포인트 1이 남았습니다. 이에 대한 약간의 설명이 있습니다.
어제 나는 Sell_limit를 설정했는데 작동했고 deal_add가 왔지만 포지션이 나타나지 않았고 우리는 그대로 스탑 오더를 열었습니다. 거래 설명을 보기 시작했는데 거래 유형이 DEAL_TYPE_SELL이고 주문 유형이 ORDER_TYPE_BUY인 것을 확인했습니다. 동시에 티켓은 우리 것입니다. 어찌보면 논리적이지 않습니다. 나는 주문 유형과 거래 유형이 방향이 일치해야 한다는 Deal_add 트랜잭션에 대해 OnTradeTransaction을 확인하기로 결정했습니다.
로봇을 데모에 올려놓고 비슷한 거래가 또 나왔는데 이번에는 입장이 바뀌었다. 그러나 우리의 수표로 인해 중지 명령이 내려지지 않았습니다. 무슨 일이야?!
prostotrader, 이것이 터미널에 오는 것이라고 즉시 말할 것입니다. 내 상상 없이.
어제 나는 Sell_limit를 설정했는데 작동했고 deal_add가 왔지만 포지션이 나타나지 않았고 우리는 그대로 스탑 오더를 열었습니다. 거래 설명을 보기 시작했는데 거래 유형이 DEAL_TYPE_SELL이고 주문 유형이 ORDER_TYPE_BUY인 것을 확인했습니다. 동시에 티켓은 우리 것입니다. 어찌보면 논리적이지 않습니다. 나는 주문 유형과 거래 유형이 방향에서 일치해야 하는 deal_add 트랜잭션에 대해 OnTradeTransaction에 체크를 하기로 결정했습니다.
그리고 여기에서 " 거래 거래의 구조 " 참조를 다시 읽을 가치가 있습니다. 거래_추가 유형에 대해 채워지는 필드의 관점에서.
그리고 트랜잭션(채워지지 않았지만 0도 열거형 유형의 일부 값에 해당)에서가 아니라 주문 자체에서 주문 속성을 가져옵니다(현재 사용 가능한 경우). 역사에 대한 명령).
이렇게 하면 상황이 어떻게 돌아가는지 쉽게 분석 할 수 있습니다.
위치, 현재 주문 및 거래 내역의 상태가 거래와 함께 기록되도록 추가할 수 있습니다. 그러면 전체 그림이 됩니다.
그리고 여기에서 " 거래 거래의 구조 " 참조를 다시 읽을 가치가 있습니다. 거래_추가 유형에 대해 채워지는 필드의 관점에서.
그리고 트랜잭션(채워지지 않았지만 0도 열거형 유형의 일부 값에 해당)에서가 아니라 주문 자체에서 주문 속성을 가져옵니다(현재 사용 가능한 경우). 역사에 대한 명령).
동의합니다. 알고 있었지만주의를 기울이지 않았습니다. 알림 주셔서 감사합니다.
그러나 그 입장이 한 경우에 나타나지 않고 다른 경우에 나타났다는 문제는 여전히 이해할 수 없다.
Илья Ребенок :
그러나 그 입장이 한 경우에 나타나지 않고 다른 경우에 나타났다는 문제는 여전히 이해할 수 없다.
Deal_add 거래에 포지션 티켓이 있었는데, 그 포지션은 이전에도 존재하지 않았고 동시에 나타나지도 않았나요? 여기서 이해가 필요합니다.
Deal_add 거래에 포지션 티켓이 있었는데, 그 포지션은 이전에도 존재하지 않았고 동시에 나타나지도 않았나요? 여기서 이해가 필요합니다.
전에 위치 없음
전에 위치 없음
거래에 포지션 티켓이 있었나요?
거래에 포지션 티켓이 있었나요?
제가 위의 글을 잘못 이해했을 수 있습니다. 그 위치는 정지 주문 으로 마감되었습니다. 즉, 포지션의 수가 0이 되었습니다. 그러면 거래는 성공했지만 포지션이 나타나지 않았습니다
나는 그것에 대해 당신을 이해합니다. 거래에는 포지션 티켓에 대한 정보가 포함되어 있지만 이 티켓은 이전 주문의 티켓입니다. 일반적으로 내가 올바르게 이해한다면 그것은 그물 모드에 있어야 합니다.
Position: 82675534제가 위의 글을 잘못 이해했을 수 있습니다. 포지션은 스톱 오더 로 마감되었습니다. 즉, 포지션의 수가 0이 되었습니다. 그러면 거래는 성공했지만 포지션이 나타나지 않았습니다
나는 그것에 대해 당신을 이해합니다. 거래에는 포지션 티켓에 대한 정보가 포함되어 있지만 이 티켓은 이전 주문의 티켓입니다. 내가 올바르게 이해한다면 일반적으로 그물 모드에 있어야 합니다.
기호 위치(모든 로봇과 수동 거래의 누적)가 0.0이 되면 다음 거래는 새 티켓(==주문 티켓)과 함께 새 위치를 엽니다(DEAL_ENTRY_IN).
실제로, 그물을 칠 때 위치를 전혀 볼 필요가 없는 것 같습니다. 각 로봇은 주문에 대한 거래의 결과로 "자신의"를 고려해야 합니다.
위치 및 DEAL_ENTRY 플래그의 존재는 어떤 식으로든 논리에 참여해서는 안 됩니다.
새로운 거래 및 현재 주문의 마술과 해설을 자신/다른 사람의 식별자로 보기만 하면 됩니다.
작업 코드를 표시했습니다. 바로 거기입니다.
OnTradeTransaction 을 통해 문제를 해결하려는 시도는 함정의 수에 대한 좋지 않은 생각입니다. 때때로 특정 작업에서 which를 우회하는 것이 여전히 가능합니다. 그러나 작업이 약간 변경되자마자 OnTradeTransaction 구현 중에 전체 논리가 위반됩니다.
개발자는 이벤트 거래 모델을 만들었지만 단일 거래 작업 예제를 제공하지 않았습니다. 그것은 완전한 엉덩이이기 때문에 코드가 무엇에 쏟아지고 있고 얼마나 많이 각 예제에 따라 달라집니다.
따라서 동기 거래 작업과 OnTrade 기능을 찾는 것이 좋습니다. 모든 것이 훨씬 간단하고 변경에 대한 논리가 매우 유연합니다. 또한, 더 신뢰할 수 있습니다.
Async+Transactions로 전환하는 것은 고급 언어에서 어셈블리 언어로 전환하는 것과 같습니다. 저것들. 그것은 TS 생성의 가장 마지막 단계에서 수행되어야 하며, 완전히 조사되고 REAL에 대한 준비가 되어 있고 마지막으로 남은 것은 거래 논리를 변경하지 않고 거래 작업의 속도를 높이는 것입니다.