TP/SL이 필요한 제한 자체는 부분적으로 실행할 수 있습니다. 동시에, 한계 형태의 TP는 유사합니다. 예를 들어, TP는 볼륨의 1/3로 완료되었습니다. SL을 같은 양만큼 줄여야 합니다.
일반적으로 모든 농담을 잡기위한 다소 불쾌한 논리.
ZY 작업은 OnTrade에서 구현됩니다. 어렵지 않았을 것입니다.
일
보류 중인 주문은 Netting에 배치됩니다(다방향 및 각 유형의 수에 제한 없음). 원래 보류 주문이 실행될 때마다 SL/TP를 Stop/Limit 보류 주문 형태로 배치해야 합니다. 동시에 SL/TP 주문은 종속되어야 합니다. 하나는 작동하고 두 번째는 남습니다. 초기 및 SL/TP 보류 주문이 부분적으로 트리거될 수 있습니다. Expert Advisor는 다른 터미널로 이동하는 것을 포함하여 언제든지 다시 로드할 수 있습니다.
voidOnTradeTransaction ( constMqlTradeTransaction &trans,
constMqlTradeRequest &request,
constMqlTradeResult &result )
{
switch (trans.type) //<<---- ОТФИЛЬТРОВАТЬ ПО ТИПУ ТРАЗАКЦИИ!!!!!!!!!!!!!!!!!!!!!!
{
//А вот здесь уже TRADE_TRANSACTION_DEAL_ADD
}
}
이 경우 요청의 주문 티켓을 어딘가에 저장해야 나중에 거래의 티켓과 비교할 수 있습니다. 그리고 지역 변수 의 모든 저장에서 벗어나 지역 기반 시설 위험을 평준화하기 위해 시장/터미널에서만 정보를 받고 싶습니다.
당신은 조금 순진합니다.
이 Expert Advisor의 모든 거래에는 단 하나의 마법이 있습니다!
그러나 주문은 다릅니다(고유)!
나는 Otkryvashka에서 실제 거래하고 데모에서 테스트하지만 재사용 가능한 긍정적 인 점이 없습니다.
TRADE_TRANSACTION_DEAL_ADD 에 대한 코드를 게시하세요.
나는 오늘 이것을 가지고 있었다. 위에 동일한 로봇에 대한 2개의 동일한 트랜잭션에 대한 로그의 일부를 게시했습니다.
2019.02.08 10:55:29 [정보]: (PChBreak_RTS-3.19_22) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEAL_ADD
기호: RTS-3.19
거래 티켓: 12674810
거래 유형: DEAL_TYPE_BUY
주문 티켓: 82646001
주문 유형: ORDER_TYPE_BUY
주문 상태: ORDER_STATE_STARTED
주문 시간 유형: ORDER_TIME_GTC
주문 만료: 1970.01.01 00:00
가격: 119700
가격 트리거: 0
손절매: 0
이익실현: 0
볼륨: 1
위치: 82646001
위치 기준: 0
2019.02.08 10:55:32 [정보]: (PChBreak_RTS-3.19_22) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEAL_ADD
기호: RTS-3.19
거래 티켓: 12674810
거래 유형: DEAL_TYPE_BUY
주문 티켓: 82646001
주문 유형: ORDER_TYPE_BUY
주문 상태: ORDER_STATE_STARTED
주문 시간 유형: ORDER_TIME_GTC
주문 만료: 1970.01.01 00:00
가격: 119700
가격 트리거: 0
손절매: 0
이익실현: 0
볼륨: 1
위치: 82646001
위치 기준: 0
deal_add에 대한 코드
두 개의 동일한 트랜잭션이 있는 버그 이후에 현재 트랜잭션의 티켓이 이전 트랜잭션과 같지 않은지 확인하는 기능이 추가되었습니다.
나는 오늘 이것을 가지고 있었다. 위에 동일한 로봇에 대한 2개의 동일한 트랜잭션에 대한 로그의 일부를 게시했습니다.
2019.02.08 10:55:29 [정보]: (PChBreak_RTS-3.19_22) TRADE_TRANSACTION_DEAL_ADD
TRADE_TRANSACTION_DEAL_ADD
기호: RTS-3.19
거래 티켓: 12674810
거래 유형: DEAL_TYPE_BUY
주문 티켓: 82646001
주문 유형: ORDER_TYPE_BUY
주문 상태: ORDER_STATE_STARTED
.......
deal_add에 대한 코드
두 개의 동일한 트랜잭션이 있는 버그 이후에 현재 트랜잭션의 티켓이 이전 트랜잭션과 같지 않은지 확인하는 기능이 추가되었습니다.
분명한.
주문 상태: ORDER_STATE_STARTED - 이것은 TRADE_TRANSACTION_DEAL_ADD 에 있을 수 없습니다 !
추가됨
나는 당신이하지 않을 것이라고 확신합니다 ( Ilya Baranov 도 마찬가지입니다)
추가됨
이 포럼에는 "거래소 거래" 섹션이 있습니다.
분명한.
주문 상태: ORDER_STATE_STARTED - 이것은 TRADE_TRANSACTION_DEAL_ADD에 있을 수 없습니다 !
추가됨
나는 당신이하지 않을 것이라고 확신합니다
추가됨
이 포럼에는 "거래소 거래" 섹션이 있습니다.
나는 오래 전에 그것을 옮겼을 것입니다. 그러나 @Ilya Rebenok 은 한 번도 말하지 않았습니다. 그는 증권 거래소에서 거래하거나 단순히 외환을 차감했습니다. 여기 앉아서 기다리고 있어요...
나는 오래 전에 그것을 옮겼을 것입니다. 그러나 @Ilya Rebenok 은 한 번도 말하지 않았습니다. 그는 증권 거래소에서 거래하거나 단순히 외환을 차감했습니다. 여기 앉아서 기다리고 있어요...
기호: RTS-3.19는 FORTS입니다.
기호: RTS-3.19는 FORTS 입니다.
이해가 안 돼요 . 외환이 있고 증권 거래소가 있습니다. 다른 모든 것은 헛소리에서 나온 것입니다.
이해가 안 돼요 . 외환이 있고 증권 거래소가 있습니다. 다른 모든 것은 헛소리에서 나온 것입니다.
FORTS는 RTS 선물 및 옵션( 모스크바 거래소 파생상품 시장 섹션)입니다.
분명한.
주문 상태: ORDER_STATE_STARTED - 이것은 TRADE_TRANSACTION_DEAL_ADD 에 있을 수 없습니다 !
추가됨
나는 당신이하지 않을 것이라고 확신합니다 ( Ilya Baranov 도 마찬가지입니다)
추가됨
이 포럼에는 "거래소 거래" 섹션이 있습니다.
나는 당신을 잘 이해하지 못했습니다. 여기 내 거래 처리가 있습니다
거래의 주문 상태에 관한 것입니다. 당신은 내가 그것을 스스로 발명하지 않는다는 것을 이해합니다. 이것은 모든 deal_add 트랜잭션의 주문 상태입니다. 마켓이 되었지만 지연이 발생하였으니 참고 부탁드립니다.
이제 오해의 또 다른 부분이 도착했습니다. 거래 Deal_add가 도착했지만 포지션이 나타나지 않고 존재하지 않는 포지션에 대한 지연이 발생했습니다.
추가되었습니다.
거래 Deal_add가 도착했지만 포지션이 나타나지 않고 존재하지 않는 포지션에 대한 지연이 발생했습니다. 거래 유형은 판매, 주문 유형은 구매입니다. 처음에는 한도가 Sell_limit이었지만
TP/SL이 필요한 제한 자체는 부분적으로 실행할 수 있습니다. 동시에, 한계 형태의 TP는 유사합니다. 예를 들어, TP는 볼륨의 1/3로 완료되었습니다. SL을 같은 양만큼 줄여야 합니다.
일반적으로 모든 농담을 잡기위한 다소 불쾌한 논리.
ZY 작업은 OnTrade에서 구현됩니다. 어렵지 않았을 것입니다.
일
보류 중인 주문은 Netting에 배치됩니다(다방향 및 각 유형의 수에 제한 없음). 원래 보류 주문이 실행될 때마다 SL/TP를 Stop/Limit 보류 주문 형태로 배치해야 합니다. 동시에 SL/TP 주문은 종속되어야 합니다. 하나는 작동하고 두 번째는 남습니다. 초기 및 SL/TP 보류 주문이 부분적으로 트리거될 수 있습니다. Expert Advisor는 다른 터미널로 이동하는 것을 포함하여 언제든지 다시 로드할 수 있습니다.
결정
나는 당신을 잘 이해하지 못했습니다. 여기 내 거래 처리가 있습니다
스위치가 없습니다(trans.type)