주문 열거 주기의 구성
MT4용 MQL5 라이브러리 출시 테마 계속
#property strict // https://www.mql5.com/ru/docs/standardlibrary/graphics/cgraphic #include <Graphics\Graphic.mqh> // MQL5\Include\Graphics\Graphic.mqh void OnStart () { double Y[] = { 1 , 2 }; GraphPlot(Y); }
종종 테스터에서 속도 슬라이더가 31로 설정된 경우(속도 슬라이더가 32로 설정된 경우 느린) 테스트가 초고속으로 완료됩니다.
카운터를 통해 코드에 지연을 삽입하여 나옵니다.
input int gDelay = 10000 ; // Счетчик для задержки, off=0 void OnTick () { int delayCount = 0 ; while (delayCount < gDelay) ++delayCount; }
어드바이저의 속도와 프로세서의 파워에 따라 입력을 통한 딜레이를 조절할 수 있습니다.
이제 속도 32에서 나에게 맞는 속도로 관심 있는 순간으로 이동할 수 있습니다.
다음 주제는 MT4뿐만 아니라 다른 플랫폼과의 MT5에 관한 것입니다. 그러나 쉽게 인식할 수 있도록 이 스레드에서 논리를 MQL4로 작성합니다.
대부분의 경우 주문 수정/삭제의 백본(성장)은 다음 논리로 귀결됩니다.
// Самый распространенный костяк логики модификации ордеров for ( int i = OrdersTotal () - 1 ; i >= 0 ; i--) if ( OrderSelect (i, SELECT_BY_POS )) OrderModify ( OrderTicket (), Price, SL, TP, OrderExpiration ());
이제 접근 방식은 드물지만 훨씬 더 정확합니다.
// Редкий, но правильный костяк модификации ордеров for ( int i = OrdersTotal () - 1 ; i >= 0 ; i--) if ( OrderSelect (i, SELECT_BY_POS )) if ( OrderModify ( OrderTicket (), Price, SL, TP, OrderExpiration ())) { i = OrdersTotal (); // Хотя бы так // А лучше так // OnTick(); break; // вместо строки выше лучше делать такой вызов (переполнения стека от рекурсивных вызовов быть не должно) }
거래 요청 을 보낸 후 거래 환경이 바뀌므로 거래 서버의 응답 직후 TS의 모든 거래 로직을 처음부터 처음부터 실행하는 것이 좋습니다.
이제 접근 방식은 드물지만 훨씬 더 정확합니다.
이 변형은 오류가 발생하면 목록의 마지막 주문을 수정하는 데 집중하고 1개 이상의 주문이 있는 Expert Advisor는 나머지 모든 주문을 "보이지 않습니다".
내 레시피: 다음 틱 - 다음 접근에서 내 모든 주문을 반복하고 각각을 처리합니다(필요한 경우 시장 정보 업데이트를 처리하기 전에). 어떤 경우에는 오류가 있는 경우 현재 루프가 종료된 직후에 다음 접근 방식(OnTick 호출)을 수행할 수 있습니다.
이 변형은 오류가 발생하면 목록의 마지막 주문을 수정하는 데 집중하고 1개 이상의 주문이 있는 Expert Advisor는 나머지 모든 주문을 "보이지 않습니다".
이 조건으로 인해 루프가 발생하지 않습니다.
if ( OrderModify ( OrderTicket (), Price, SL, TP, OrderExpiration ()))
내 레시피: 다음 틱 - 다음 접근에서 내 모든 주문을 반복하고 각각을 처리합니다(필요한 경우 시장 정보 업데이트를 처리하기 전에). 어떤 경우에는 오류가 있는 경우 현재 루프가 종료된 직후에 다음 접근 방식(OnTick 호출)을 수행할 수 있습니다.
그러면 터미널 로그에 더 많은 거래 요청 오류가 표시됩니다.
수정이 성공하면 목록의 처음부터 처리를 반복하는 것도 불가능하기 때문에 이 경우 하나의 주문도 수정되고(예: 가격으로 풀업) 나머지 주문은 오랫동안 방치될 수 있습니다.
이 논리의 무언가가 처음에 잘못되었습니다. 여기에서 의식적인 선택을 해야 합니다. 하나의 실제 주문이나 관련 없는 많은 주문이 있는 것이 좋습니다.
내 레시피가 켜져 있습니다.
나는 이것을 이해하지 못했다.
OrderModify를 5초 동안 실행합니다. 실행 중에 거래 서버에서 부분 지정가 주문이 여러 번 실행되어 수십 개의 거래가 발생했습니다.
이 논리의 무언가가 처음에 잘못되었습니다. 여기에서 의식적인 선택을 해야 합니다. 하나의 실제 주문이나 관련 없는 많은 주문이 있는 것이 좋습니다.
하나의 주문은 동시에 다른 수준에 있을 수 없습니다. 아니면 각 레벨에 대해 자신의 어드바이저를 시작하시겠습니까? 대다수의 전략에 대한 모호한 결정입니다.
특별한 경우로, 여러 위치(여러 항목이 있는 추세에 의해 획득됨) 및 이들에 대한 후행 정지. 단 한 번의 거래에서 SL을 당기거나 모든 것을 수정하시겠습니까? 동일한 날카로운 후속 롤백이 있는 급격한 움직임에서 하나의 주문만 수정하는 옵션은 많은 손실을 입게 됩니다.
OrderModify를 5초 동안 실행합니다. 실행 중에 거래 서버에서 부분 지정가 주문이 여러 번 실행되어 수십 개의 거래가 발생했습니다.
하자. 처리된(그리고 처리되어야 하는) 모든 주문을 처리하고 다음 틱 또는 첫 번째 주기가 완료된 직후 새 주문으로 이동합니다.
그렇지 않으면 항상 마지막 주문의 마지막 부분으로 작업할 위험이 있습니다. 아마도 가장 작은 부분일 것입니다. 대형 영장을 방치한 채 방치됨.
하나의 주문은 동시에 다른 수준에 있을 수 없습니다. 아니면 각 레벨에 대해 자신의 어드바이저를 시작하시겠습니까? 대다수의 전략에 대한 모호한 결정입니다.
특별한 경우로, 여러 위치(여러 항목이 있는 추세에 의해 획득됨) 및 이들에 대한 후행 정지. 단 한 번의 거래에서 SL을 당기거나 모든 것을 수정하시겠습니까? 동일한 날카로운 후속 롤백이 있는 급격한 움직임에서 하나의 주문만 수정하는 옵션은 많은 손실을 입게 됩니다.
OnTick이 하나의 주문만 수정하는 이유를 이해하지 못합니까? 모두 수정됩니다.
하자. 처리된(그리고 처리되어야 하는) 모든 주문을 처리하고 다음 틱 또는 첫 번째 주기가 완료된 직후 새 주문으로 이동합니다.
그렇지 않으면 항상 마지막 주문의 마지막 부분으로 작업할 위험이 있습니다. 아마도 가장 작은 부분일 것입니다. 대형 영장을 방치한 채 방치됨.
나는 "백본"이라는 단어에주의를 기울입니다. 많은 또는 다른 것에 대한 우선 순위를 선택하는 형태의 고기는 항상 증가 할 수 있습니다. 논리의 기초는 동일하게 유지됩니다. 성공적인 거래 주문 후 모든 거래 논리를 처음부터 시작합니다.
OnTick이 하나의 주문만 수정하는 이유를 이해하지 못합니까? 모두 수정됩니다.
가격이 이동하고 각각의 새로운 OnTick 호출에서 목록의 첫 번째인 동일한 주문의 새로운 수정에 대한 조건이 충족될 것입니다. 특히 수정이 5초 동안 지속되는 경우 ;)
나는 "백본"이라는 단어에주의를 기울입니다. 많은 또는 다른 것에 대한 우선 순위를 선택하는 형태의 고기는 항상 증가 할 수 있습니다. 논리의 기초는 동일하게 유지됩니다. 성공적인 거래 주문 후 모든 거래 논리를 처음부터 시작합니다.
이러한 "백본"은 하나 이상의 주문과 함께 작동하는 Expert Advisor의 논리를 깨뜨릴 것입니다.
한 가지 명령으로 시스템에 아무런 이점도 주지 않고 나머지는 망친다면 무슨 소용이 있겠습니까?
주문을 처리하기 전에 수량 및/또는 가격과의 거리를 기준으로 정렬하는 것이 올바른 결정입니다. 그러나 포럼에서 코드를 복사하는 모든 사람이 이를 구현할 것이라고 가정해서는 안 됩니다.
그런 의미에서 내 코드는 더 안전합니다.
