거래 처리 OnTradeTransaction - 페이지 2 12345678910 새 코멘트 Ilya Rebenok 2019.02.07 20:16 #11 fxsaber : >=2개의 테이크 및 스톱이 동시에 있을 수 있습니까? 네, 맞습니다. 초기 입력을 완료하고 TP를 설정하고 주문을 중지합니다 . 그런 다음 잠시 후 토핑이 발생할 수 있으며 다른 TP 및 스탑 오더가 배치됩니다. JRandomTrader 2019.02.07 21:55 #12 이벤트 분실의 경우, 주문한 주문, 마지막으로 계상된 거래의 티켓, 상태의 마지막 기록(변경) 시간을 기억하고, 초기화 뿐만 아니라 주기적으로 주문 목록을 동기화합니다. 미확인 거래를 확인합니다. 임의의 순서로 이벤트가 도착하는 것은 규범입니다. 주문과 기록 모두에서 주문의 부재(일시적)는 드문 일이 아니며 거래가 나타나기 전후에 발생할 수 있습니다. 네팅 중 위치는 첫 번째 주문의 티켓을 받고 닫힐 때까지(즉, 0.0이 될 때까지) 추가 거래(변경)에 유지합니다. 글쎄요, 주문량에 따라 여러 트랜잭션을 생성할 수 있습니다. prostotrader 2019.02.07 23:09 #13 Илья Ребенок : 경험과 아이디어를 공유해 주세요. 당신은 처음부터 잘못하고 있습니다. 왜 마법과 모든 종류의 검사입니까? 주문 티켓(티켓) - 고유 식별자입니다. 동기 주문을 보내면 함수 실행의 결과로 티켓을 받게 됩니다. 주문이 비동기식으로 전송되면 OnTradeTransaction 에서 티켓이 수신됩니다. 추가됨 그리고 여기 https://www.mql5.com/ru/forum/67298/page2#comment_2089220 순서를 확인하는 좋은 기능 ФОРТС: В помощь начинающим 2015.11.25www.mql5.com Установка отложенного ордера командой OrderSend(). fxsaber 2019.02.08 06:40 #14 Илья Ребенок : 네, 맞습니다. 초기 입력을 완료하고 TP를 설정하고 주문을 중지합니다 . 그런 다음 잠시 후 토핑이 발생할 수 있으며 다른 TP 및 스탑 오더가 배치됩니다. TP/SL이 필요한 제한 자체는 부분적으로 실행할 수 있습니다. 동시에, 한계 형태의 TP는 유사합니다. 예를 들어, TP는 볼륨의 1/3로 완료되었습니다. SL을 같은 양만큼 줄여야 합니다. 일반적으로 모든 농담을 잡기위한 다소 불쾌한 논리. ZY 작업은 OnTrade에서 구현됩니다. 어렵지 않았을 것입니다. Ilya Rebenok 2019.02.08 08:36 #15 prostotrader : 당신은 처음부터 잘못하고 있습니다. 왜 마법과 모든 종류의 검사를 합니까? 주문 티켓(티켓) - 고유 식별자입니다. 동기 주문을 보내면 함수 실행의 결과로 티켓을 받게 됩니다. 주문이 비동기식으로 전송되면 OnTradeTransaction 에서 티켓이 수신됩니다. 추가됨 그리고 여기 https://www.mql5.com/ru/forum/67298/page2#comment_2089220 순서를 확인하는 좋은 기능 고마워, 내가 읽을게. 제이랜덤 트레이더 : 이벤트 분실의 경우, 주문한 주문, 마지막으로 계상된 거래의 티켓, 상태의 마지막 기록(변경) 시간을 기억하고, 초기화 뿐만 아니라 주기적으로 주문 목록을 동기화합니다. 미계상 거래를 확인합니다. 임의의 순서로 이벤트가 도착하는 것은 규범입니다. 주문과 기록 모두에서 주문의 부재(일시적)는 드문 일이 아니며 거래가 나타나기 전후에 발생할 수 있습니다. 네팅 중 위치는 첫 번째 주문의 티켓을 받고 닫힐 때까지(즉, 0.0이 될 때까지) 추가 거래(변경)에 유지합니다. 글쎄요, 주문량에 따라 여러 트랜잭션을 생성할 수 있습니다. 로봇의 목표 중 하나는 지역 의존에서 벗어나는 것이었습니다. 즉, 단말이나 PC의 변수를 참고하지 않고 시장에서만 데이터를 수신하는 것이다. 즉, 긴급하게 다른 PC로 전환해야 하는 경우 로봇이 모든 것을 픽업합니다. 이제 또 다른 흥미로운 버그를 보았습니다. 2개의 동일한 거래 TRADE_TRANSACTION_DEAL_ADD가 도착했습니다. 뭐야, 미안?) 결과적으로 로봇은 1 거래에 대해 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 OnTradeTransaction processing 초보자의 질문 MQL5 MT5 코딩하는 방법? Ilya Baranov 2019.02.08 08:39 #16 거래 이벤트( TRADE_TRANSACTION_DEAL_ADD) 는 여러 번 정기적으로 발생합니다. 다행스럽게도 최신 버전만 반복됩니다(최소한 이전 버전의 도착을 포착하지 못했습니다). 필터링하려면 거래 티켓이 이전 티켓과 일치하는지 확인하는 것으로 충분합니다. prostotrader 2019.02.08 09:06 #17 Ilya Baranov : 거래 이벤트( TRADE_TRANSACTION_DEAL_ADD) 는 여러 번 정기적으로 발생합니다. 다행히도 최신 항목만 반복됩니다(어쨌든 이전 항목의 도착을 포착하지 못했습니다). 필터링하려면 거래 티켓이 이전 티켓과 일치하는지 확인하는 것으로 충분합니다. 몇 번이 아니라 현재 터미널에서 일하고 있는 Expert Advisors의 수만큼. 따라서 각 고문은 자체 주문을 처리해야 합니다. case TRADE_TRANSACTION_DEAL_ADD : if ((BuyOrder.ticket > 0 ) && (trans.order == BuyOrder.ticket)) // Buy order { //Сделка этого советника } break ; Ilya Baranov 2019.02.08 09:14 #18 prostotrader : 몇 번이 아니라 현재 터미널에서 일하고 있는 Expert Advisors의 수만큼. 따라서 각 고문은 자체 주문을 처리해야 합니다. 귀하의 코드는 이것이 이 EA의 거래라는 사실로부터 보호합니다. TS와 저는 TRADE_TRANSACTION_DEAL_ADD 유형의 OnTradeTransaction이 하나의 거래에 대해 여러 번 호출 되는 경우에 대해 이야기하고 있습니다. 나머지 MqlTradeTransaction 필드는 정확히 동일한 데이터를 포함합니다. 즉, 귀하의 경우 처리 코드를 여러 번 실행할 수 있습니다. 이것은 모든 브로커에서 발생하지 않을 수 있습니다. 그러나 내가 일한 모든 증권 거래소에서 이것은 정기적으로 발생합니다. prostotrader 2019.02.08 09:23 #19 Ilya Baranov : 귀하의 코드는 이것이 이 EA의 거래라는 사실로부터 보호합니다. TS와 저는 TRADE_TRANSACTION_DEAL_ADD 유형의 OnTradeTransaction이 하나의 거래에 대해 여러 번 호출 되는 경우에 대해 이야기하고 있습니다. 나머지 MqlTradeTransaction 필드는 정확히 동일한 데이터를 포함합니다. 즉, 귀하의 경우 처리 코드를 여러 번 실행할 수 있습니다. 이것은 모든 브로커에서 발생하지 않을 수 있습니다. 그러나 내가 일한 모든 증권 거래소에서 이것은 정기적으로 발생합니다. 나는 Otkryvashka에서 실제 거래하고 데모에서 테스트하지만 재사용 가능한 긍정적 인 점이 없습니다. TRADE_TRANSACTION_DEAL_ADD 에 대한 코드를 게시하세요. Ilya Rebenok 2019.02.08 09:31 #20 Ilya Baranov : 거래 이벤트( TRADE_TRANSACTION_DEAL_ADD) 는 여러 번 정기적으로 발생합니다. 다행스럽게도 최신 버전만 반복됩니다(최소한 이전 버전의 도착을 포착하지 못했습니다). 필터링하려면 거래 티켓이 이전 티켓과 일치하는지 확인하는 것으로 충분합니다. 네 감사합니다! 그것이 바로 그가 본 후에 그가 한 일입니다. 초기 문제에 따르면 주문을 삭제하고 내역을 추가하는 트랜잭션이 펌핑 될 수 있도록 슬립을 넣었습니다. 내가보고 있어요. 이와 관련하여 플랫폼의 불완전성은 매우 슬프다. 뭉쳐야 할 것들은 따로 떼어 놓는다. 단순 상인 : 몇 번이 아니라 현재 터미널에서 일하고 있는 Expert Advisors의 수만큼. 따라서 각 고문은 자체 주문을 처리해야 합니다. 이 경우 요청의 주문 티켓을 어딘가에 저장해야 나중에 거래의 티켓과 비교할 수 있습니다. 그리고 저는 지역 변수 의 모든 저장에서 벗어나 지역 기반 시설 위험을 평준화하기 위해 독점적으로 시장/터미널에서 정보를 받고 싶습니다. 12345678910 새 코멘트 트레이딩 기회를 놓치고 있어요: 무료 트레이딩 앱 복사용 8,000 이상의 시그널 금융 시장 개척을 위한 경제 뉴스 등록 로그인 공백없는 라틴 문자 비밀번호가 이 이메일로 전송될 것입니다 오류 발생됨 Google으로 로그인 웹사이트 정책 및 이용약관에 동의합니다. 계정이 없으시면, 가입하십시오 MQL5.com 웹사이트에 로그인을 하기 위해 쿠키를 허용하십시오. 브라우저에서 필요한 설정을 활성화하시지 않으면, 로그인할 수 없습니다. 사용자명/비밀번호를 잊으셨습니까? Google으로 로그인
>=2개의 테이크 및 스톱이 동시에 있을 수 있습니까?
네, 맞습니다. 초기 입력을 완료하고 TP를 설정하고 주문을 중지합니다 . 그런 다음 잠시 후 토핑이 발생할 수 있으며 다른 TP 및 스탑 오더가 배치됩니다.
이벤트 분실의 경우, 주문한 주문, 마지막으로 계상된 거래의 티켓, 상태의 마지막 기록(변경) 시간을 기억하고, 초기화 뿐만 아니라 주기적으로 주문 목록을 동기화합니다. 미확인 거래를 확인합니다.
임의의 순서로 이벤트가 도착하는 것은 규범입니다. 주문과 기록 모두에서 주문의 부재(일시적)는 드문 일이 아니며 거래가 나타나기 전후에 발생할 수 있습니다.
네팅 중 위치는 첫 번째 주문의 티켓을 받고 닫힐 때까지(즉, 0.0이 될 때까지) 추가 거래(변경)에 유지합니다.
글쎄요, 주문량에 따라 여러 트랜잭션을 생성할 수 있습니다.경험과 아이디어를 공유해 주세요.
당신은 처음부터 잘못하고 있습니다.
왜 마법과 모든 종류의 검사입니까?
주문 티켓(티켓) - 고유 식별자입니다.
동기 주문을 보내면 함수 실행의 결과로 티켓을 받게 됩니다.
주문이 비동기식으로 전송되면 OnTradeTransaction 에서 티켓이 수신됩니다.
추가됨
그리고 여기 https://www.mql5.com/ru/forum/67298/page2#comment_2089220
순서를 확인하는 좋은 기능
네, 맞습니다. 초기 입력을 완료하고 TP를 설정하고 주문을 중지합니다 . 그런 다음 잠시 후 토핑이 발생할 수 있으며 다른 TP 및 스탑 오더가 배치됩니다.
TP/SL이 필요한 제한 자체는 부분적으로 실행할 수 있습니다. 동시에, 한계 형태의 TP는 유사합니다. 예를 들어, TP는 볼륨의 1/3로 완료되었습니다. SL을 같은 양만큼 줄여야 합니다.
일반적으로 모든 농담을 잡기위한 다소 불쾌한 논리.
ZY 작업은 OnTrade에서 구현됩니다. 어렵지 않았을 것입니다.
당신은 처음부터 잘못하고 있습니다.
왜 마법과 모든 종류의 검사를 합니까?
주문 티켓(티켓) - 고유 식별자입니다.
동기 주문을 보내면 함수 실행의 결과로 티켓을 받게 됩니다.
주문이 비동기식으로 전송되면 OnTradeTransaction 에서 티켓이 수신됩니다.
추가됨
그리고 여기 https://www.mql5.com/ru/forum/67298/page2#comment_2089220
순서를 확인하는 좋은 기능
이벤트 분실의 경우, 주문한 주문, 마지막으로 계상된 거래의 티켓, 상태의 마지막 기록(변경) 시간을 기억하고, 초기화 뿐만 아니라 주기적으로 주문 목록을 동기화합니다. 미계상 거래를 확인합니다.
임의의 순서로 이벤트가 도착하는 것은 규범입니다. 주문과 기록 모두에서 주문의 부재(일시적)는 드문 일이 아니며 거래가 나타나기 전후에 발생할 수 있습니다.
네팅 중 위치는 첫 번째 주문의 티켓을 받고 닫힐 때까지(즉, 0.0이 될 때까지) 추가 거래(변경)에 유지합니다.
글쎄요, 주문량에 따라 여러 트랜잭션을 생성할 수 있습니다.로봇의 목표 중 하나는 지역 의존에서 벗어나는 것이었습니다. 즉, 단말이나 PC의 변수를 참고하지 않고 시장에서만 데이터를 수신하는 것이다. 즉, 긴급하게 다른 PC로 전환해야 하는 경우 로봇이 모든 것을 픽업합니다.
이제 또 다른 흥미로운 버그를 보았습니다. 2개의 동일한 거래 TRADE_TRANSACTION_DEAL_ADD가 도착했습니다. 뭐야, 미안?) 결과적으로 로봇은 1 거래에 대해 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
거래 이벤트( TRADE_TRANSACTION_DEAL_ADD) 는 여러 번 정기적으로 발생합니다.
다행스럽게도 최신 버전만 반복됩니다(최소한 이전 버전의 도착을 포착하지 못했습니다).
필터링하려면 거래 티켓이 이전 티켓과 일치하는지 확인하는 것으로 충분합니다.
거래 이벤트( TRADE_TRANSACTION_DEAL_ADD) 는 여러 번 정기적으로 발생합니다.
다행히도 최신 항목만 반복됩니다(어쨌든 이전 항목의 도착을 포착하지 못했습니다).
필터링하려면 거래 티켓이 이전 티켓과 일치하는지 확인하는 것으로 충분합니다.
몇 번이 아니라 현재 터미널에서 일하고 있는 Expert Advisors의 수만큼.
따라서 각 고문은 자체 주문을 처리해야 합니다.
몇 번이 아니라 현재 터미널에서 일하고 있는 Expert Advisors의 수만큼.
따라서 각 고문은 자체 주문을 처리해야 합니다.
귀하의 코드는 이것이 이 EA의 거래라는 사실로부터 보호합니다.
TS와 저는 TRADE_TRANSACTION_DEAL_ADD 유형의 OnTradeTransaction이 하나의 거래에 대해 여러 번 호출 되는 경우에 대해 이야기하고 있습니다. 나머지 MqlTradeTransaction 필드는 정확히 동일한 데이터를 포함합니다.
즉, 귀하의 경우 처리 코드를 여러 번 실행할 수 있습니다.
이것은 모든 브로커에서 발생하지 않을 수 있습니다. 그러나 내가 일한 모든 증권 거래소에서 이것은 정기적으로 발생합니다.
귀하의 코드는 이것이 이 EA의 거래라는 사실로부터 보호합니다.
TS와 저는 TRADE_TRANSACTION_DEAL_ADD 유형의 OnTradeTransaction이 하나의 거래에 대해 여러 번 호출 되는 경우에 대해 이야기하고 있습니다. 나머지 MqlTradeTransaction 필드는 정확히 동일한 데이터를 포함합니다.
즉, 귀하의 경우 처리 코드를 여러 번 실행할 수 있습니다.
이것은 모든 브로커에서 발생하지 않을 수 있습니다. 그러나 내가 일한 모든 증권 거래소에서 이것은 정기적으로 발생합니다.
나는 Otkryvashka에서 실제 거래하고 데모에서 테스트하지만 재사용 가능한 긍정적 인 점이 없습니다.
TRADE_TRANSACTION_DEAL_ADD 에 대한 코드를 게시하세요.
거래 이벤트( TRADE_TRANSACTION_DEAL_ADD) 는 여러 번 정기적으로 발생합니다.
다행스럽게도 최신 버전만 반복됩니다(최소한 이전 버전의 도착을 포착하지 못했습니다).
필터링하려면 거래 티켓이 이전 티켓과 일치하는지 확인하는 것으로 충분합니다.
네 감사합니다! 그것이 바로 그가 본 후에 그가 한 일입니다.
초기 문제에 따르면 주문을 삭제하고 내역을 추가하는 트랜잭션이 펌핑 될 수 있도록 슬립을 넣었습니다. 내가보고 있어요.
이와 관련하여 플랫폼의 불완전성은 매우 슬프다. 뭉쳐야 할 것들은 따로 떼어 놓는다.
몇 번이 아니라 현재 터미널에서 일하고 있는 Expert Advisors의 수만큼.
따라서 각 고문은 자체 주문을 처리해야 합니다.