지금까지 이 코드는 여러 브로커에서 잘 작동합니다. 변경 후 아직 여러 주문 문제가 발견되지 않았습니다. BlindMist는 이 코드를 시도하여 해당 브로커와의 다중 주문 문제를 피할 수 있는지 확인할 수 있습니다.
안녕하세요 FinanceEngineer 님, 원래 코드에서 if { } 및 else { }에 Print("OrderSend Code: "...)가 있다는 점에 유의하십시오.
그러나 그렇지 않으면 { }에 중단이 발생하고 디버그 코드에 retcode = 10008 (TRADE_RETCODE_PLACED) x 10이 표시됩니다.
따라서 추론에 따르면 if { } 조건 디버그를 인쇄하고 있었고 중단은 사용되지 않았습니다.
if (! OrderSend (request,result) || result.deal== 0 )
{
Print ( "OrderSend Code: " ,result.retcode);
if (result.retcode== TRADE_RETCODE_TRADE_DISABLED ) break ;
if (result.retcode== TRADE_RETCODE_MARKET_CLOSED ) break ;
if (result.retcode== TRADE_RETCODE_NO_MONEY ) break ;
if (result.retcode== TRADE_RETCODE_TOO_MANY_REQUESTS ) Sleep ( 5000 );
if (result.retcode== TRADE_RETCODE_FROZEN ) break ;
if (result.retcode== TRADE_RETCODE_CONNECTION ) Sleep ( 15000 );
if (result.retcode== TRADE_RETCODE_LIMIT_VOLUME ) break ;
}
elseif (result.retcode== 10009 || result.retcode== 10008 )
{
Print ( "OrderSend Code: " ,result.retcode);
volume-=result.volume; //If order was successful then reduce volume to 0.0, then the loop will be terminated.if (Type == POSITION_TYPE_BUY ) {mBuyPositionCnt = mBuyPositionCnt + 1.0 ; cntLotCalculation = cntLotCalculation + 1 ;}
if (Type == POSITION_TYPE_SELL ) {mSellPositionCnt = mSellPositionCnt + 1.0 ; cntLotCalculation = cntLotCalculation + 1 ;}
break ;
}
이제 코드를 변경하고 더 명확해 보이지만 OrderSend()의 반환 값을 더 이상 테스트하지 않고 result.retcode만 테스트합니다. 이전에 질문한 checkOrderSend 변수(*** 여기 참조)를 사용하여 이를 수정할 수 있습니다.
bool checkOrderSend= OrderSend (request,result);
if (checkOrderSend) // (*** look here)
{
if (result.retcode== 10009 || result.retcode== 10008 )
{
Print ( "OrderSend was successful. Code: " ,result.retcode);
volume-=result.volume; //If order was successful then reduce volume to 0.0, then the loop will be terminated.break ;
}
else
{
Print (ResultRetcodeDescription(result.retcode));
}
}
else
{
Print ( "OrderSend execution error." );
}
따라서 제 생각에 가장 먼저 할 일은 이 테스트를 수정하고 보고한 것과 동일한 문제 브로커를 사용하여 다시 확인하는 것입니다. 문제가 다시 발생하지 않는다면 축하합니다. 정말 버그를 해결한 것 입니다. 즉, 코드가 미래에 사용할 수 있거나 가장 안전한 것은 아니지만 버그를 발견했다는 의미입니다.
실제로 버그가 발생하지 않았기 때문에 코드를 다시 변경하는 것을 잊거나 피할 수 있지만 이 경우 더 이상 OrderSend()의 반환 값을 테스트하지 않는다는 점에 주의해야 합니다.
안녕하세요 FinanceEngineer 님, 원래 코드에서 if { } 및 else { }에 Print("OrderSend Code: "...)가 있다는 점에 유의하십시오.
그러나 그렇지 않으면 { }에 중단이 발생하고 디버그 코드에 retcode = 10008 (TRADE_RETCODE_PLACED) x 10이 표시됩니다.
따라서 추론에 따르면 if { } 조건 디버그를 인쇄하고 있었고 중단은 사용되지 않았습니다.
이제 코드를 변경하고 더 명확해 보이지만 OrderSend()의 반환 값을 더 이상 테스트하지 않고 result.retcode만 테스트합니다. 이전에 질문한 checkOrderSend 변수(*** 여기 참조)를 사용하여 이를 수정할 수 있습니다.
따라서 제 생각에 가장 먼저 할 일은 이 테스트를 수정하고 보고한 것과 동일한 문제 브로커를 사용하여 다시 확인하는 것입니다. 문제가 다시 발생하지 않는다면 축하합니다. 정말 버그를 해결한 것 입니다. 즉, 코드가 미래에 사용할 수 있거나 가장 안전한 것은 아니지만 버그를 발견했다는 의미입니다.
실제로 버그가 발생하지 않았기 때문에 코드를 다시 변경하는 것을 잊거나 피할 수 있지만 이 경우 더 이상 OrderSend()의 반환 값을 테스트하지 않는다는 점에 주의해야 합니다.
이 정보가 도움이 되기를 바랍니다.
반환된 코드 10010은 어떻습니까?
이중 항목 주문은 모든 브로커에서 발생할 수 있습니다. Alpari로 주문을 받을 확률은 더 많은 틱을 받을수록 더 커집니다.
안녕하세요 FinanceEngineer 님, 원래 코드에서 if { } 및 else { }에 Print("OrderSend Code: "...)가 있다는 점에 유의하십시오.
그러나 그렇지 않으면 { }에 중단이 발생하고 디버그 코드에 retcode = 10008 (TRADE_RETCODE_PLACED) x 10이 표시됩니다.
따라서 추론에 따르면 if { } 조건 디버그를 인쇄하고 있었고 중단은 사용되지 않았습니다.
이제 코드를 변경하고 더 명확해 보이지만 OrderSend()의 반환 값을 더 이상 테스트하지 않고 result.retcode만 테스트합니다. 이전에 질문한 checkOrderSend 변수(*** 여기 참조)를 사용하여 이를 수정할 수 있습니다.
따라서 제 생각에 가장 먼저 할 일은 이 테스트를 수정하고 보고한 것과 동일한 문제 브로커를 사용하여 다시 확인하는 것입니다. 문제가 다시 발생하지 않는다면 축하합니다. 정말 버그를 해결한 것 입니다. 즉, 코드가 미래에 사용할 수 있거나 가장 안전한 것은 아니지만 버그를 발견했다는 의미입니다.
실제로 버그가 발생하지 않았기 때문에 코드를 다시 변경하는 것을 잊거나 피할 수 있지만 이 경우 더 이상 OrderSend()의 반환 값을 테스트하지 않는다는 점에 주의해야 합니다.
이 정보가 도움이 되기를 바랍니다.
여보세요
이상하게 들린다는 것을 알고 있습니다. 이전 코드에서 OrderSend(request,result)의 반환 값을 확인했을 때 다중 주문 문제가 발생했습니다. 이제 새 코드에서 OrderSend(request,result)의 반환 값을 확인하지 않습니다(그러나 터미널의 새 빌드에서 오류를 피하기 위해 반환 값을 일부 변수에 할당했습니다.
새 코드를 사용하면 여러 주문 문제가 발생하지 않습니다. 진드기를 많이 보낸다고 소문난 Alpari UK를 사용했습니다. 내 코드는 완벽하지 않을 수 있지만 이렇게 생각하십시오. Meta Trader 5에서 확인해야 할 반환 코드가 꽤 있습니다.
첫 번째는 OrderCheck에서 반환된 값이고 두 번째는 OrderSend에서 반환된 값이고 세 번째는 result.retcode에 할당된 반환 값입니다. 처음 두 개의 반환 값이 무엇이든 가장 신경써야 할 것은 마지막 값에 실제로 실행된 볼륨의 양을 더한 것입니다.
그래서 이 사실을 바탕으로 바로 result.retcode를 확인하기 위해 코드를 더 간단하게 만들었습니다. 내가 틀렸다면 저를 수정하십시오. MT5의 주문 실행은 확실히 MT4보다 훨씬 더 정교하고 많은 사람들이 혼란스러워합니다.
논리만으로 명확한 사례를 만들 수 없다면 실험을 통해 명확한 사례를 만들 수 있습니다. 그래서 저는 BlindMist 또는 다른 사람들이 OrderSend 기능을 확인하기 위해 건너뛰는 것이 실제로 도움이 될 수 있는지 알아보기 위해 브로커와 함께 이 코드를 시도할 것을 권장합니다.
이상하게 들린다는 것을 알고 있습니다. 이전 코드에서 OrderSend(request,result)의 반환 값을 확인했을 때 다중 주문 문제가 발생했습니다. 이제 새 코드에서 OrderSend(request,result)의 반환 값을 확인하지 않습니다(그러나 터미널의 새 빌드에서 오류를 피하기 위해 반환 값을 일부 변수에 할당했습니다.
새 코드를 사용하면 여러 주문 문제가 발생하지 않습니다. 진드기를 많이 보낸다고 소문난 Alpari UK를 사용했습니다. 내 코드는 완벽하지 않을 수 있지만 이렇게 생각하십시오. Meta Trader 5에서 확인해야 할 반환 코드가 꽤 있습니다.
첫 번째는 OrderCheck에서 반환된 값이고 두 번째는 OrderSend에서 반환된 값이고 세 번째는 result.retcode에 할당된 반환 값입니다. 처음 두 개의 반환 값이 무엇이든 가장 신경써야 할 것은 마지막 값에 실제로 실행된 볼륨의 양을 더한 것입니다.
그래서 이 사실을 바탕으로 바로 result.retcode를 확인하기 위해 코드를 더 간단하게 만들었습니다. 내가 틀렸다면 저를 수정하십시오. MT5의 주문 실행은 확실히 MT4보다 훨씬 더 정교하고 많은 사람들이 혼란스러워합니다.
논리만으로 명확한 사례를 만들 수 없다면 실험을 통해 명확한 사례를 만들 수 있습니다. 그래서 저는 BlindMist 또는 다른 사람들이 OrderSend 기능을 확인하기 위해 건너뛰는 것이 실제로 도움이 될 수 있는지 알아보기 위해 브로커와 함께 이 코드를 시도할 것을 권장합니다.
감사합니다.
OrderSend() 반환 코드를 건너뛰는 것은 이중 주문 문제와 관련이 없습니다. 단순한 우연의 일치.
OrderCheck()도 관련이 없습니다. 주문을 보내기 전에 일부 오류를 방지하기 위한 것일 뿐입니다.
OrderSend()가 false를 반환했다면 문제가 있는 것이므로 어떤 문제가 있는지 확인 하고 필요에 따라 처리할 수 있습니다.
OrderSend()가 true를 반환하면 여기에서 어려움이 시작됩니다. 다음 메시지를 참조하십시오.
안녕하세요 FinanceEngineer님 , 원래 코드의 다중 주문 문제를 확인하는 것이 더 나을 것입니다. 이렇게 하면 여기에서 다른 중요한 사항을 해결하고 초점을 잃지 않을 것이기 때문입니다. 어떻게 생각하세요?
안녕하세요 피겨리
이것은 내 새 코드입니다. 이 스레드에서 여러 주문 문제를 제기한 이후로 변경했습니다.
지금까지 이 코드는 여러 브로커에서 잘 작동합니다. 변경 후 아직 여러 주문 문제가 발견되지 않았습니다. BlindMist는 이 코드를 시도하여 해당 브로커와의 다중 주문 문제를 피할 수 있는지 확인할 수 있습니다.
안녕하세요 피겨리
이것은 내 새 코드입니다. 이 스레드에서 여러 주문 문제를 제기한 이후로 변경했습니다.
지금까지 이 코드는 여러 브로커에서 잘 작동합니다. 변경 후 아직 여러 주문 문제가 발견되지 않았습니다. BlindMist는 이 코드를 시도하여 해당 브로커와의 다중 주문 문제를 피할 수 있는지 확인할 수 있습니다.
코드를 게시할 때 SRC 버튼을 사용하십시오.
귀하가 게시한 코드는 (전체) 이중 주문을 피할 수 없으며, 반대로 경우에 따라 이중 주문을 유발할 수 있습니다.
코드를 게시할 때 SRC 버튼을 사용하십시오.
귀하가 게시한 코드는 (전체) 이중 주문을 피할 수 없으며, 반대로 경우에 따라 이중 주문을 유발할 수 있습니다.
안녕하세요 피겨리
이것은 내 새 코드입니다. 이 스레드에서 여러 주문 문제를 제기한 이후로 변경했습니다.
지금까지 이 코드는 여러 브로커에서 잘 작동합니다. 변경 후 아직 여러 주문 문제가 발견되지 않았습니다. BlindMist는 이 코드를 시도하여 해당 브로커와의 다중 주문 문제를 피할 수 있는지 확인할 수 있습니다.
안녕하세요 FinanceEngineer 님, 원래 코드에서 if { } 및 else { }에 Print("OrderSend Code: "...)가 있다는 점에 유의하십시오.
그러나 그렇지 않으면 { }에 중단이 발생하고 디버그 코드에 retcode = 10008 (TRADE_RETCODE_PLACED) x 10이 표시됩니다.
따라서 추론에 따르면 if { } 조건 디버그를 인쇄하고 있었고 중단은 사용되지 않았습니다.
이제 코드를 변경하고 더 명확해 보이지만 OrderSend()의 반환 값을 더 이상 테스트하지 않고 result.retcode만 테스트합니다. 이전에 질문한 checkOrderSend 변수(*** 여기 참조)를 사용하여 이를 수정할 수 있습니다.
따라서 제 생각에 가장 먼저 할 일은 이 테스트를 수정하고 보고한 것과 동일한 문제 브로커를 사용하여 다시 확인하는 것입니다. 문제가 다시 발생하지 않는다면 축하합니다. 정말 버그를 해결한 것 입니다. 즉, 코드가 미래에 사용할 수 있거나 가장 안전한 것은 아니지만 버그를 발견했다는 의미입니다.
실제로 버그가 발생하지 않았기 때문에 코드를 다시 변경하는 것을 잊거나 피할 수 있지만 이 경우 더 이상 OrderSend()의 반환 값을 테스트하지 않는다는 점에 주의해야 합니다.
이 정보가 도움이 되기를 바랍니다.
안녕하세요 FinanceEngineer 님, 원래 코드에서 if { } 및 else { }에 Print("OrderSend Code: "...)가 있다는 점에 유의하십시오.
그러나 그렇지 않으면 { }에 중단이 발생하고 디버그 코드에 retcode = 10008 (TRADE_RETCODE_PLACED) x 10이 표시됩니다.
따라서 추론에 따르면 if { } 조건 디버그를 인쇄하고 있었고 중단은 사용되지 않았습니다.
이제 코드를 변경하고 더 명확해 보이지만 OrderSend()의 반환 값을 더 이상 테스트하지 않고 result.retcode만 테스트합니다. 이전에 질문한 checkOrderSend 변수(*** 여기 참조)를 사용하여 이를 수정할 수 있습니다.
따라서 제 생각에 가장 먼저 할 일은 이 테스트를 수정하고 보고한 것과 동일한 문제 브로커를 사용하여 다시 확인하는 것입니다. 문제가 다시 발생하지 않는다면 축하합니다. 정말 버그를 해결한 것 입니다. 즉, 코드가 미래에 사용할 수 있거나 가장 안전한 것은 아니지만 버그를 발견했다는 의미입니다.
실제로 버그가 발생하지 않았기 때문에 코드를 다시 변경하는 것을 잊거나 피할 수 있지만 이 경우 더 이상 OrderSend()의 반환 값을 테스트하지 않는다는 점에 주의해야 합니다.
이 정보가 도움이 되기를 바랍니다.
반환된 코드 10010은 어떻습니까?
이중 항목 주문은 모든 브로커에서 발생할 수 있습니다. Alpari로 주문을 받을 확률은 더 많은 틱을 받을수록 더 커집니다.
반환된 코드 10010은 어떻습니까?
이중 항목 주문은 모든 브로커에서 발생할 수 있습니다. Alpari로 주문을 받을 확률은 더 많은 틱을 받을수록 더 커집니다.
안녕하세요 FinanceEngineer 님, 원래 코드에서 if { } 및 else { }에 Print("OrderSend Code: "...)가 있다는 점에 유의하십시오.
그러나 그렇지 않으면 { }에 중단이 발생하고 디버그 코드에 retcode = 10008 (TRADE_RETCODE_PLACED) x 10이 표시됩니다.
따라서 추론에 따르면 if { } 조건 디버그를 인쇄하고 있었고 중단은 사용되지 않았습니다.
이제 코드를 변경하고 더 명확해 보이지만 OrderSend()의 반환 값을 더 이상 테스트하지 않고 result.retcode만 테스트합니다. 이전에 질문한 checkOrderSend 변수(*** 여기 참조)를 사용하여 이를 수정할 수 있습니다.
따라서 제 생각에 가장 먼저 할 일은 이 테스트를 수정하고 보고한 것과 동일한 문제 브로커를 사용하여 다시 확인하는 것입니다. 문제가 다시 발생하지 않는다면 축하합니다. 정말 버그를 해결한 것 입니다. 즉, 코드가 미래에 사용할 수 있거나 가장 안전한 것은 아니지만 버그를 발견했다는 의미입니다.
실제로 버그가 발생하지 않았기 때문에 코드를 다시 변경하는 것을 잊거나 피할 수 있지만 이 경우 더 이상 OrderSend()의 반환 값을 테스트하지 않는다는 점에 주의해야 합니다.
이 정보가 도움이 되기를 바랍니다.
여보세요
이상하게 들린다는 것을 알고 있습니다. 이전 코드에서 OrderSend(request,result)의 반환 값을 확인했을 때 다중 주문 문제가 발생했습니다. 이제 새 코드에서 OrderSend(request,result)의 반환 값을 확인하지 않습니다(그러나 터미널의 새 빌드에서 오류를 피하기 위해 반환 값을 일부 변수에 할당했습니다.
새 코드를 사용하면 여러 주문 문제가 발생하지 않습니다. 진드기를 많이 보낸다고 소문난 Alpari UK를 사용했습니다. 내 코드는 완벽하지 않을 수 있지만 이렇게 생각하십시오. Meta Trader 5에서 확인해야 할 반환 코드가 꽤 있습니다.
첫 번째는 OrderCheck에서 반환된 값이고 두 번째는 OrderSend에서 반환된 값이고 세 번째는 result.retcode에 할당된 반환 값입니다. 처음 두 개의 반환 값이 무엇이든 가장 신경써야 할 것은 마지막 값에 실제로 실행된 볼륨의 양을 더한 것입니다.
그래서 이 사실을 바탕으로 바로 result.retcode를 확인하기 위해 코드를 더 간단하게 만들었습니다. 내가 틀렸다면 저를 수정하십시오. MT5의 주문 실행은 확실히 MT4보다 훨씬 더 정교하고 많은 사람들이 혼란스러워합니다.
논리만으로 명확한 사례를 만들 수 없다면 실험을 통해 명확한 사례를 만들 수 있습니다. 그래서 저는 BlindMist 또는 다른 사람들이 OrderSend 기능을 확인하기 위해 건너뛰는 것이 실제로 도움이 될 수 있는지 알아보기 위해 브로커와 함께 이 코드를 시도할 것을 권장합니다.
감사합니다.
만약 당신이 저에게 묻는다면, 제가 이전에 말했듯이, 저는 이 코드가 미래를 보장하고 충분히 안전하다고 생각하지 않으며 이것은 리턴 코드가 없다는 것에 대한 한 가지 예일 뿐이므로 다시 읽으십시오.
나는 이 주제에 참여하는 모든 사람들에게 물었다. 코드 10010에 대한 메시지를 놓쳤습니다. 어디에 있습니까?
나는 이 주제에 참여하는 모든 사람들에게 물었다. 코드 10010에 대한 메시지를 놓쳤습니다. 어디에 있습니까?
안녕 알랭
우리는 FinanceEngineer 의 새 코드에 대해 이야기하고 있고 원래 코드에서 변경된 OrderSend()의 반환 코드 테스트에 대한 조언에 대해 이야기하고 있기 때문에 알아야 할 사항이 명확하지 않습니다.
그의 원래 코드와 그의 새 코드에는 코드 10010 테스트가 없습니다. 따라서 귀하와 관련이 있다면 그의 첫 번째 게시물 이후로 왜 묻지 않았습니까?
어쨌든, FOK 채우기 정책 에 대해 코드 10010 테스트가 필요한 이유를 설명할 수 있습니까?
귀하와 다른 중재자가 이야기하는 것을 보는 것은 이번이 처음이 아니기 때문에 FOK(Fill Or Kill) 주문에 대한 이 코드 테스트가 정말로 필요한 경우를 알고 있습니까? 공유할 수 있습니까?
미리 감사드립니다.
여보세요
이상하게 들린다는 것을 알고 있습니다. 이전 코드에서 OrderSend(request,result)의 반환 값을 확인했을 때 다중 주문 문제가 발생했습니다. 이제 새 코드에서 OrderSend(request,result)의 반환 값을 확인하지 않습니다(그러나 터미널의 새 빌드에서 오류를 피하기 위해 반환 값을 일부 변수에 할당했습니다.
새 코드를 사용하면 여러 주문 문제가 발생하지 않습니다. 진드기를 많이 보낸다고 소문난 Alpari UK를 사용했습니다. 내 코드는 완벽하지 않을 수 있지만 이렇게 생각하십시오. Meta Trader 5에서 확인해야 할 반환 코드가 꽤 있습니다.
첫 번째는 OrderCheck에서 반환된 값이고 두 번째는 OrderSend에서 반환된 값이고 세 번째는 result.retcode에 할당된 반환 값입니다. 처음 두 개의 반환 값이 무엇이든 가장 신경써야 할 것은 마지막 값에 실제로 실행된 볼륨의 양을 더한 것입니다.
그래서 이 사실을 바탕으로 바로 result.retcode를 확인하기 위해 코드를 더 간단하게 만들었습니다. 내가 틀렸다면 저를 수정하십시오. MT5의 주문 실행은 확실히 MT4보다 훨씬 더 정교하고 많은 사람들이 혼란스러워합니다.
논리만으로 명확한 사례를 만들 수 없다면 실험을 통해 명확한 사례를 만들 수 있습니다. 그래서 저는 BlindMist 또는 다른 사람들이 OrderSend 기능을 확인하기 위해 건너뛰는 것이 실제로 도움이 될 수 있는지 알아보기 위해 브로커와 함께 이 코드를 시도할 것을 권장합니다.
감사합니다.