그렇게 며칠이 흘렀습니다. 이 기간 동안 여러 전문가가 작업을 수행했습니다. 다음은 로그입니다(이러한 로그를 생성하는 코드는 위에 있음). 여전히 개발자의 응답을 기다리고 있습니다. 적어도 '문제가 인식되면 시정하겠다'는 수준에서다.
로그 1: 구매 시도, 시도 0 실패, 오류 6 구매 시도, 시도 1 실패, 오류 129 구매 시도, 시도 2 실패, 오류 129 구매 시도, 3번 시도 실패, 오류 129 구매 시도, 시도 4 실패, 오류 129 지그재그 구매 오류: 4050 2.28000000, 0.02700000, 0.00000000 구매 시도, 시도 0 실패, 오류 6 구매 시도 중 1번 성공
주문은 7번째 시도부터 열립니다. 그 과정에서 현실과 관련이 없는 몇 가지 오류 메시지를 포착했습니다.
로그 2. 2005년 7월 9일 11:0:15, 신호: Sell7.9.2005 11:0:15 판매 시도, 시도 0 매도: 1.24820000, 손절매: 0.00600000, 이익실현: 0.00000000 실패, 오류 6 2005년 7월 9일 11:0:15 판매 시도, 시도 1 매도: 1.24820000, 손절매: 0.00600000, 이익실현: 0.00000000 성공적
두 번째 시도부터. 여섯 번째 실수, 전체 스레드가 백 개 이상의 게시물에 전념했습니다. 개발자인 Roche와 Composter의 조언에 따라 오류율이 "매번"에서 "5분의 1"로 감소했습니다. 하지만 그녀는 머물렀다.
로그 3. 롱 포지션 청산 시도, 티켓: 1784257 2005년 6월 9일 12:0:13 이 티켓이 아직 있는 주문, 다시 시도 중 2005년 6월 9일 12:0:13 이 티켓이 아직 있는 주문, 다시 시도 중 2005년 6월 9일 12:0:13 이 티켓이 아직 있는 주문, 다시 시도 중 2005년 6월 9일 12:0:13 이 티켓이 아직 있는 주문, 다시 시도 중 2005년 6월 9일 12:0:13 이 티켓이 아직 있는 주문, 다시 시도 중
5번의 실패, 오류 코드 없음. 프로그램은 포지션이 마감된 것으로 간주했습니다. 루프에서 티켓을 잡았습니다. 티켓을 잡지 않았다면 문제가 감지되지 않았을 것입니다.
이 작업이 완료되면 오류가 마스킹될 가능성이 큽니다. 그리고 그 임무는 모든 것이 순환 없이 작동하도록 개발자가 그것을 찾도록 돕는 것입니다.
Sleep의 의미는 실패의 원인이 되는 조건이 사라질 때까지 기다리는 것입니다(핑이 통과하기 시작할 것입니다). 왜냐하면 - 거래 작업 이 제어권을 "제거"하고 반환될 때까지 해제하지 않는다는 점을 감안할 때 오류가 있는 경우 즉시 나타나야 합니다. 그렇지 않다면 버그입니다.
유일하게 가능한 예외는 방금 마감된 포지션의 티켓을 확인하는 루프입니다. 그러나 여기에서도 시스템이 이상적으로 작동하는 방식에 대해 논쟁할 수 있습니다.
반복합니다. 문제는 오류가 OCCUR일 뿐만 아니라 오류 코드가 천장에서 가져오고 때로는 코드가 전혀 없다는 것입니다. 작업 성공 코드가 반환됩니다.
내가 설명한다. Expert Advisors 중 한 명의 조건에 따르면 현재 매도호가가 보류 중인매도 주문의 손절매를 초과하면 다음과 같은 여러 조치가 수행됩니다. 1. 해당 주문에 대한 철회의사를 SMS로 발송합니다. 2. 주문 취소를 시도한 경우 3. OrderDelete() 함수의 결과를 분석하여 음수일 경우(주문이 취소되지 않은 경우) 4. 실패에 대한 SMS가 전송됩니다.
어제 2개의 SMS 메시지가 모두 규정에 따라 왔지만 로그에 따르면 주문은 같은 시간에 철회되었습니다. 이것은 EA 가 주문 취소 작업 의 결과를 수신한 결과보다 몇 분의 1초 먼저 결과를 얻으려고 시도했음을 의미합니다. 감자를 심고 다음날 파낸 중국인에 대한 농담처럼. "뭐야, 너무 빨리 익어"라는 질문에 "아니요,하지만 당신을 물고 싶습니다"라고 대답했습니다. :)
물론입니다. 하지만: 1. 나는 실제 주문에 대해 이 모든 소란을 제기했습니다. 그리고 그들이 이렇게 행동한다면 고쳐야 합니다. 2. 아이디어는 MT Expert Advisors가 지연이 있는 주기 없이 거래할 수 있다는 것입니다. 이것이 그렇게 되어야만 하는 방법입니다. 나는 연기를 할 것이지만 그들이 말하는 것처럼 "완전히 기쁨이 없다" :)
바로 지금 생각했습니다. 주문을 수정하는 작업과 이 작업의 결과를 확인하는 작업 사이에 일시 중지를 사용하도록 제안하면 EA가 비동기식이라고 가정합니다. 즉, 주문 수정을 시도하면서 서버로 요청을 보내고, 알고리즘에 따라 어드바이저는 응답을 기다리지 않고 더 긁는다. 기본적으로 부정적인 응답은 서버의 응답이 도착할 때까지 그에게 전달됩니다. 그가 응답을 기다렸다면 - 응답은 실제이고, 기다리지 않았다면 - 응답은 가상입니다.
테스트를 했습니다. 한 명의 전문가 고문이 작동하여 포지션을 열고 닫습니다(또는 매수 및 매도). 모든 거래 작업 사이의 최소 일시 중지는 10초입니다.
테스트 시간(알파리): 02:00 - 09:30(즉, 7.5시간) OrderSend 시도 : 996 럭키*: 888 오류**: 108
* - "성공적인" 시도란 다음을 의미합니다. 주문 전송은 티켓 번호를 반환했고 GetLastError는 0을 반환했으며 오픈 포지션은 주문 선택에 의해 성공적으로 선택되었습니다. ** - 모든 오류 #148 "trade context is busy" - Slava가 다음 스레드에서 질문한 내용 - "isTradeAllowed 검사가 비활성화된 경우 어떻게 됩니까?". 오류는 07:16:46에 시작되어 지금까지 계속 쏟아지고 있습니다)
* - "성공적인" 닫기 시도는 다음을 의미합니다. orderclose는 true를 반환하고 GetLastError는 0을 반환하고 닫힌 위치 위치는 mode_history에서 orderselect를 성공적으로 선택했습니다. ** - 152개의 오류 #1 "오류 없음", 하나는 #6 및 하나는 #138(재인용됨)
그리고 보류중인 주문 :(((
로그 1:
구매 시도, 시도 0 실패, 오류 6
구매 시도, 시도 1 실패, 오류 129
구매 시도, 시도 2 실패, 오류 129
구매 시도, 3번 시도 실패, 오류 129
구매 시도, 시도 4 실패, 오류 129
지그재그 구매 오류: 4050
2.28000000, 0.02700000, 0.00000000
구매 시도, 시도 0 실패, 오류 6
구매 시도 중 1번 성공
주문은 7번째 시도부터 열립니다. 그 과정에서 현실과 관련이 없는 몇 가지 오류 메시지를 포착했습니다.
로그 2.
2005년 7월 9일 11:0:15, 신호: Sell7.9.2005 11:0:15 판매 시도, 시도 0
매도: 1.24820000, 손절매: 0.00600000, 이익실현: 0.00000000
실패, 오류 6
2005년 7월 9일 11:0:15 판매 시도, 시도 1
매도: 1.24820000, 손절매: 0.00600000, 이익실현: 0.00000000
성공적
두 번째 시도부터. 여섯 번째 실수, 전체 스레드가 백 개 이상의 게시물에 전념했습니다. 개발자인 Roche와 Composter의 조언에 따라 오류율이 "매번"에서 "5분의 1"로 감소했습니다. 하지만 그녀는 머물렀다.
로그 3.
롱 포지션 청산 시도, 티켓: 1784257
2005년 6월 9일 12:0:13 이 티켓이 아직 있는 주문, 다시 시도 중
2005년 6월 9일 12:0:13 이 티켓이 아직 있는 주문, 다시 시도 중
2005년 6월 9일 12:0:13 이 티켓이 아직 있는 주문, 다시 시도 중
2005년 6월 9일 12:0:13 이 티켓이 아직 있는 주문, 다시 시도 중
2005년 6월 9일 12:0:13 이 티켓이 아직 있는 주문, 다시 시도 중
5번의 실패, 오류 코드 없음. 프로그램은 포지션이 마감된 것으로 간주했습니다. 루프에서 티켓을 잡았습니다. 티켓을 잡지 않았다면 문제가 감지되지 않았을 것입니다.
글쎄, 등등.
무효 CloseBuy(문자열 strExpertName)
{
int nTicket = OrderTicket();
SaveComment("\r\n\t롱 포지션 청산 시도, 티켓: " + nTicket);
int nResult = OrderClose(OrderTicket(), OrderLots(), Bid, nSlip, Aqua);
수면(10000);
if(n결과 == -1)
{
정수 nError = GetLastError();
경고(strExpertName + ", 오류: " + nError);
}
}
텍스트를 굵게 만들기 위해 따옴표를 사용해야 했습니다.
Sleep의 의미는 실패의 원인이 되는 조건이 사라질 때까지 기다리는 것입니다(핑이 통과하기 시작할 것입니다). 왜냐하면 - 거래 작업 이 제어권을 "제거"하고 반환될 때까지 해제하지 않는다는 점을 감안할 때 오류가 있는 경우 즉시 나타나야 합니다. 그렇지 않다면 버그입니다.
유일하게 가능한 예외는 방금 마감된 포지션의 티켓을 확인하는 루프입니다. 그러나 여기에서도 시스템이 이상적으로 작동하는 방식에 대해 논쟁할 수 있습니다.
반복합니다. 문제는 오류가 OCCUR일 뿐만 아니라 오류 코드가 천장에서 가져오고 때로는 코드가 전혀 없다는 것입니다. 작업 성공 코드가 반환됩니다.
이해가 안되는 부분이 있으면 설명 부탁드립니다.
1. 해당 주문에 대한 철회의사를 SMS로 발송합니다.
2. 주문 취소를 시도한 경우
3. OrderDelete() 함수의 결과를 분석하여 음수일 경우(주문이 취소되지 않은 경우)
4. 실패에 대한 SMS가 전송됩니다.
어제 2개의 SMS 메시지가 모두 규정에 따라 왔지만 로그에 따르면 주문은 같은 시간에 철회되었습니다.
이것은 EA 가 주문 취소 작업 의 결과를 수신한 결과보다 몇 분의 1초 먼저 결과를 얻으려고 시도했음을 의미합니다. 감자를 심고 다음날 파낸 중국인에 대한 농담처럼. "뭐야, 너무 빨리 익어"라는 질문에 "아니요,하지만 당신을 물고 싶습니다"라고 대답했습니다. :)
1. 나는 실제 주문에 대해 이 모든 소란을 제기했습니다. 그리고 그들이 이렇게 행동한다면 고쳐야 합니다.
2. 아이디어는 MT Expert Advisors가 지연이 있는 주기 없이 거래할 수 있다는 것입니다. 이것이 그렇게 되어야만 하는 방법입니다.
나는 연기를 할 것이지만 그들이 말하는 것처럼 "완전히 기쁨이 없다" :)
나는 그것을 스스로 믿지 않는다. 개발자들이 내가 얼마나 틀렸는지 설명할 수 있을까?
이 스레드의 37개 게시물에 대해 개발자가 작성한 게시물이 1개뿐이라는 사실이 다소 당황스럽습니다.
이미 생산적인 토론을 방해하는 이유
그리고 여기 제품이 있습니다 =)
테스트를 했습니다. 한 명의 전문가 고문이 작동하여 포지션을 열고 닫습니다(또는 매수 및 매도). 모든 거래 작업 사이의 최소 일시 중지는 10초입니다.
OrderSend 시도 : 996
럭키*: 888
오류**: 108
* - "성공적인" 시도란 다음을 의미합니다. 주문 전송은 티켓 번호를 반환했고 GetLastError는 0을 반환했으며 오픈 포지션은 주문 선택에 의해 성공적으로 선택되었습니다.
** - 모든 오류 #148 "trade context is busy" - Slava가 다음 스레드에서 질문한 내용 - "isTradeAllowed 검사가 비활성화된 경우 어떻게 됩니까?". 오류는 07:16:46에 시작되어 지금까지 계속 쏟아지고 있습니다)
-------------------------------------------------- -------------------------------------------------- --------------------
주문 닫기 시도 : 890
럭키*: 736
오류**: 154
* - "성공적인" 닫기 시도는 다음을 의미합니다. orderclose는 true를 반환하고 GetLastError는 0을 반환하고 닫힌 위치 위치는 mode_history에서 orderselect를 성공적으로 선택했습니다.
** - 152개의 오류 #1 "오류 없음", 하나는 #6 및 하나는 #138(재인용됨)
잡히지 않은 상황... 즉. 모든 마감된 위치는 실제로 마감되었습니다.