NM010:29:25.562거래: 88ms 후 실행을 위해 배치된 시장에서 2.00 SBRF-9.14 교환 구매
미네소타010:29:25.562거래: 거래 #4522433 6903에서 2.00 SBRF-9.14 구매 완료(주문 #4988264 기준)
즉010:29:26.640거래: 시장에서 2.00 SBPR-9.14 교환 판매
DL010:29:26.734거래: 시장에서 2.00 SBPR-9.14 교환 판매 허용
MQ010:29:26.734거래: 92ms 후 실행을 위해 배치된 시장에서 2.00 SBPR-9.14 교환 판매
KF010:29:26.734거래: 거래 #4522434 1.00 SBPR-9.14를 5255에 판매 완료(주문 #4988265 기준)
DK010:29:26.734거래: 거래 #4522435 1.00 SBPR-9.14를 5255에 판매 완료(주문 #4988265 기준)
이제 부분 실행입니다.
얘들아, 너 뭐야? 이 목록은 하나의 주문( #4988265 )이 두 개의 거래( #4522435 � )로 채워지고 부분 채우기와 관련이 없음을 보여줍니다.
작동 방식은 다음과 같습니다. 시장에서 50개의 VTBR-9.14 계약을 구매하고 싶다고 가정해 보겠습니다. 우리는 판매를 위해 지정가 주문을 하는 유동성 공급자에게서만 구매할 수 있습니다. 레벨과 부피는 유리의 위쪽 절반에서 볼 수 있습니다. 한번 볼까:
우리는 구매 주문을 합니다. 우리의 주문은 4명의 다른 판매자만 채울 수 있습니다. 다양한 거래 수준에서 지정가 매도 주문을 한 사람. 1계약을 3874, 40계약을 3875, 1계약을 3876, 28계약을 3877에 매수할 수 있음을 알 수 있습니다. 이는 4명의 판매자가 한 번, 네 가지 트랜잭션으로:
거래 번호
가격
용량/
사용 가능한 볼륨
총
용량
시간
하나
3874
1/1
하나
12:21:341
2
3875
40/40
41
12:21:351
삼
3876
1/1
42
12:21:363
4
3878
8/28
오십
12:21:365
시간에주의하십시오. 거래 체결 시간이 주문 시간과 반드시 일치하는 것은 아닙니다. 더 명확하게 하기 위해 다른 예를 들겠습니다.
부분 실행
100개의 VTBR-9.14 계약을 3873 보다 낮은 가격으로 구매하고 싶다고 가정해 보겠습니다. 우리는 3873 레벨에서 100 계약의 수량을 가진 BuyLimit를 설정했습니다. 그러나 주문이 이루어질 때까지 이미 주문에 표시된 것보다 더 나은 가격으로 계약을 판매하는 여러 판매자가 있습니다.
용량
가격
하나
3871
삼
3872
하나
3872
39
3872
26
3872
이 지정가 주문을 한 직후 70 계약(1+3+1+39+26)의 양으로 지정가 주문을 부분적으로 채울 5개의 거래가 있을 것입니다.
완료된 거래는 거래 내역에 포함되며 지정가 주문 자체는 여전히 활성 상태이며 "거래" 탭에서 다음 형식으로 관찰됩니다.
우리 주문이 반대 방향으로 지정가 주문을 마감한 후, 그 가격은 계약을 판매하려는 사람들에게 가장 좋은 제안이 될 것입니다.
용량
가격
30 (이것은 우리의 응용 프로그램입니다)
3873
2 (다른 참가자의 제안이 더 나쁨)
3872
12
3871
왜냐하면 우리의 제안이 더 좋고 시장이 유동적이면 우리 주문은 카운터, 시장 또는 보류 중인 주문을 사용하여 다른 시장 참가자에 의해 채워질 것입니다.
얼마 후 주문이 실행되어 "히스토리" 보물로 이전됩니다.
전체 프로세스를 제 시간에 고려하면 다음을 얻습니다.
1. 지정가 주문을 하십시오. 설정 시간은 ORDER_TIME_SETUP_MSC에 해당합니다.
2. 이 주문에 의해 시작된 거래가 작동하기 시작합니다. 이러한 거래는 즉시 기록에 남습니다. 주문 자체는 여전히 "Trade" 탭에 있으며 위 그림과 같이 보입니다.
3. 일정 시간이 지나면 모든 트랜잭션이 트리거되고 주문이 필요한 양을 확보하고 주문 내역으로 전송됩니다. 그의 실행 시간 ORDER_TIME_DONE은 일반적으로 마지막으로 완료된 트랜잭션에 해당합니다.
어떤 이유(유동성 부족, 주문 만료)로 인해 주문이 필요한 양을 얻지 못할 수 있습니다. 이 경우 "일부 실행" 상태에서 이력으로 이관됩니다. 저것들. 여기에 명시된 모든 볼륨이 트랜잭션으로 실행되는 것은 아닙니다.
이 주문의 스크린샷을 살펴보세요.
주문은 25초(!) 이내에 실행되었으며 이번에는 활성 주문 탭에 있었습니다. 그리고 마지막 거래로 만 역사가 이전되었습니다. 따라서 ORDER_TIME_DONE은 마지막 거래 시간과 동일해졌습니다.
OrderGetInteger - 시장에서 보류 중인 주문과 독점적으로 작동합니다.
HistoryOrderGetInteger - 기록의 채워진 주문 과 함께 작동합니다.
그래도 관심이 있으신 분들을 위해 코드, 실행 파일, 전문가 로그를 첨부파일에 있습니다.
MT-5 요새
결과:
1. 주문이 완전히 실행되거나 철회될 때까지 내역이 없습니다.
2. 부분적으로 실행된 주문에는 ORDER_POSITION_ID 가 없습니다.
모두 감사합니다.
DK 0 10:29:26.734 거래 : 거래 #4522435 1.00 SBPR-9.14를 5255에 판매 완료(주문 #4988265 기준)
이제 부분 실행입니다.
얘들아, 너 뭐야? 이 목록은 하나의 주문( #4988265 )이 두 개의 거래( #4522435 & #4522434 )로 채워지고 부분 채우기와 관련이 없음을 보여줍니다.
작동 방식은 다음과 같습니다. 시장에서 50개의 VTBR-9.14 계약을 구매하고 싶다고 가정해 보겠습니다. 우리는 판매를 위해 지정가 주문을 하는 유동성 공급자에게서만 구매할 수 있습니다. 레벨과 부피는 유리의 위쪽 절반에서 볼 수 있습니다. 한번 볼까:
우리는 구매 주문을 합니다. 우리의 주문은 4명의 다른 판매자만 채울 수 있습니다. 다양한 거래 수준에서 지정가 매도 주문을 한 사람. 1계약을 3874, 40계약을 3875, 1계약을 3876, 28계약을 3877에 매수할 수 있음을 알 수 있습니다. 이는 4명의 판매자가 한 번, 네 가지 트랜잭션으로:
용량/
사용 가능한 볼륨
총
용량
시간에주의하십시오. 거래 체결 시간이 주문 시간과 반드시 일치하는 것은 아닙니다. 더 명확하게 하기 위해 다른 예를 들겠습니다.
부분 실행
100개의 VTBR-9.14 계약을 3873 보다 낮은 가격으로 구매하고 싶다고 가정해 보겠습니다. 우리는 3873 레벨에서 100 계약의 수량을 가진 BuyLimit를 설정했습니다. 그러나 주문이 이루어질 때까지 이미 주문에 표시된 것보다 더 나은 가격으로 계약을 판매하는 여러 판매자가 있습니다.
이 지정가 주문을 한 직후 70 계약(1+3+1+39+26)의 양으로 지정가 주문을 부분적으로 채울 5개의 거래가 있을 것입니다.
완료된 거래는 거래 내역에 포함되며 지정가 주문 자체는 여전히 활성 상태이며 "거래" 탭에서 다음 형식으로 관찰됩니다.
우리 주문이 반대 방향으로 지정가 주문을 마감한 후, 그 가격은 계약을 판매하려는 사람들에게 가장 좋은 제안이 될 것입니다.
왜냐하면 우리의 제안이 더 좋고 시장이 유동적이면 우리 주문은 카운터, 시장 또는 보류 중인 주문을 사용하여 다른 시장 참가자에 의해 채워질 것입니다.
얼마 후 주문이 실행되어 "히스토리" 보물로 이전됩니다.
전체 프로세스를 제 시간에 고려하면 다음을 얻습니다.
1. 지정가 주문을 하십시오. 설정 시간은 ORDER_TIME_SETUP_MSC에 해당합니다.
2. 이 주문에 의해 시작된 거래가 작동하기 시작합니다. 이러한 거래는 즉시 기록에 남습니다. 주문 자체는 여전히 "Trade" 탭에 있으며 위 그림과 같이 보입니다.
3. 일정 시간이 지나면 모든 트랜잭션이 트리거되고 주문이 필요한 양을 확보하고 주문 내역으로 전송됩니다. 그의 실행 시간 ORDER_TIME_DONE은 일반적으로 마지막으로 완료된 트랜잭션에 해당합니다.
어떤 이유(유동성 부족, 주문 만료)로 인해 주문이 필요한 양을 얻지 못할 수 있습니다. 이 경우 "일부 실행" 상태에서 이력으로 이관됩니다. 저것들. 여기에 명시된 모든 볼륨이 트랜잭션으로 실행되는 것은 아닙니다.
이 주문의 스크린샷을 살펴보세요.
주문은 25초(!) 이내에 실행되었으며 이번에는 활성 주문 탭에 있었습니다. 그리고 마지막 거래로 만 역사가 이전되었습니다. 따라서 ORDER_TIME_DONE은 마지막 거래 시간과 동일해졌습니다.
P/S 약속한 대로( 서비스데스크 답변 게시에 대해 ).
불필요하게 지원을 철회했기 때문에 서비스 데스크에서 응답이 없습니다.
테스트 EA를 작성하도록 제안한 komposter에게 감사합니다.
자세한 로그.
괜찮은!? 그리고 저녁 내내 장난을 치고 THINK를 하게 만든 정수님, 감사합니다.
그런 태도 후에 도움이 ...
괜찮은!? 그리고 저녁 내내 장난을 치고 THINK를 하게 만든 정수님, 감사합니다.
그런 태도 후에 도움이 ...
이것은 그의 실수입니다. 그가 생각하도록 돕는 것이 아니라 그를 위해 해야 합니다.
샌덱스:
당신은 잘못된 부분, OrderGetInteger ( ORDER_POSITION_ID )를 보고 있습니다 - 당신은 포지션의 개설/변경/청산에 관여하지 않은 부분을 보려고 하고 있습니다
다음과 같아야 합니다. HistoryOrderGetInteger(ticket,ORDER_POSITION_ID)
------------------
당신의 진술?
계속하시겠습니까?
샌덱스:
당신은 잘못된 부분, OrderGetInteger ( ORDER_POSITION_ID )를 보고 있습니다 - 당신은 포지션의 개설/변경/청산에 관여하지 않은 부분을 보려고 하고 있습니다
다음과 같아야 합니다. HistoryOrderGetInteger(ticket,ORDER_POSITION_ID)
------------------
당신의 진술?
계속하시겠습니까?
무엇 때문에? 왜 그래? 사람이 말도 안되는 글을 쓴 것처럼? 당신이 당신의 헛소리를 쓰지 않았다면 이런 헛소리는 없었을 것입니다. 당신은 주문에 대한 기록이 주문 내역에 나타나는 동시에 시장에 매달려 있다고 썼습니다.
계속하시겠습니까?
끝, 마지막이라고 생각합니다.
이전에 참여하고 참여한 포럼이 없습니다.
포럼 회원의 서로에 대한 그러한 태도는 없습니다!
포럼은 공동으로 결정(토론)하는 같은 생각을 가진 사람들의 커뮤니티입니다.
참가자들이 서로 돕는 방향의 몇 가지 문제.
사람은 모두 다릅니다. 한 사람은 문제의 본질을 즉석에서 "파악"하고 다른 사람은 시간이 필요합니다.
이해하고 이해합니다.
여유롭게 생각해보세요!
P / S 그리고 Yurich와 komposter 덕분에 나는 정확히 다음과 같은 사실에 대해 말했습니다.
그들은 비즈니스와 존경심에 대해서만 불필요한 단어를 한 마디도 말하지 않았습니다.
사람에게 (그가 틀리거나 실수하더라도).
여기 그들은 포럼의 실제 회원의 예입니다!
나는 이미 매점에 앉았다. 기대됩니다... :)