그러나 대본에는 그렇지 않습니다. 예, 고문에게는 매우 어렵습니다. 왜냐하면. 불확실한 상황에서 OnTick 밖으로 날아가는 것이 좋습니다. 그리고 이러한 상황은 고문의 곱창 깊숙한 곳에서 발생할 수 있습니다. 결과적으로 OnTick을 종료하려면 그곳을 빠져나와야 할 뿐만 아니라, 예를 들어 한 번에 두 개의 포지션(라 바스켓)을 열어야 할 수도 있습니다. 그러나 동시에 첫 번째 항목이 성공적으로 열린 경우에만 두 번째 항목을 여십시오. 이 상황에서 첫 번째 OrderSend 후 OnTick에서 날아가는 것은 가볍게 말해서 나쁜 것입니다.
그러나 대본에는 그렇지 않습니다. 예, 고문에게는 매우 어렵습니다. 왜냐하면. 불확실한 상황에서 OnTick 밖으로 날아가는 것이 좋습니다. 그리고 이러한 상황은 고문의 곱창 깊숙한 곳에서 발생할 수 있습니다. 결과적으로 OnTick을 종료하려면 그곳을 빠져나와야 할 뿐만 아니라, 예를 들어 한 번에 두 개의 포지션(라 바스켓)을 열어야 할 수도 있습니다. 그러나 동시에 첫 번째 것이 성공적으로 완료된 경우에만 두 번째 것을 여십시오. 이 상황에서 첫 번째 OrderSend 후에 OnTick을 떠나는 것은 가볍게 말해서 나쁜 것입니다.
Expert Advisor... Expert Advisor에서는 포지션 개설 기능의 논리에서 이것을 고려해야 합니다. 이들은 작업 결과를 반환하면서 Expert Advisor에서 호출됩니다. 시장 주문이 있을 때의 결과는 false를 반환합니다. 그런 다음 고문은 그 안에 포함된 논리에 따라 작동합니다. 예, 동의합니다. 그러한 가능성을 즉시 고려하는 것보다 기성품에 구현하는 것이 더 어렵습니다. 그러나 다른 사람들이 지식을 알고 사용할 수 있도록 분기가 여기에 있습니다.
Expert Advisor... Expert Advisor에서는 포지션 개설 기능의 논리에서 이것을 고려해야 합니다. 이들은 작업 결과를 반환하면서 Expert Advisor에서 호출됩니다. 시장 주문이 있을 때의 결과는 false를 반환합니다. 그런 다음 고문은 그 안에 포함된 논리에 따라 작동합니다. 예, 동의합니다. 그러한 가능성을 즉시 고려하는 것보다 기성품에 구현하는 것이 더 어렵습니다. 그러나 다른 사람들이 지식을 알고 사용할 수 있도록 분기가 여기에 있습니다.
거래가 완료되는 순간까지 조금만 기다리면 됩니다. 다음 틱 전에 TC를 떠나는 것은 끔찍한 결정입니다.
거래가 완료되는 순간까지 조금만 기다리면 됩니다. 다음 틱 전에 TC를 떠나는 것은 끔찍한 결정입니다.
글쎄, 그 코드에서는 지정된 시간에 대한 기대가 충족됩니다. 그러나 몇 시간 동안 기다릴 수는 없습니다. 유효한 환경을 얻으려는 주어진 횟수의 시도는 얼마 동안 기다린 다음 결과와 함께 종료됩니다. 그렇지 않고 오래 기다리다 보면 거래 환경이 많이 바뀔 수도 있고, 보르조미를 마시기에는 너무 늦을 것입니다 :)
//+------------------------------------------------------------------+//| Заполняет массивы тикетов позиций |//+------------------------------------------------------------------+bool FillingListTickets( constuint number_of_attempts)
{
//--- Проверка состояния окруженияint n= 0 ,attempts= int (number_of_attempts< 1 ? 1 : number_of_attempts);
while (IsUncertainStateEnv(symb,InpMagic) && n<attempts && ! IsStopped ())
{
n++;
Sleep (sleep);
}
if (n>=attempts && IsUncertainStateEnv(symb,InpMagic))
{
Print ( __FUNCTION__ , ": Uncertain state of the environment. Please try again." );
returnfalse ;
}
//---
글쎄, 그 코드에서는 지정된 시간에 대한 기대가 충족됩니다. 그러나 몇 시간 동안 기다릴 수는 없습니다. 유효한 환경을 얻으려는 주어진 횟수의 시도는 얼마 동안 기다린 다음 결과와 함께 종료됩니다. 그렇지 않고 오래 기다리다 보면 거래 환경이 많이 바뀔 수도 있고, 보르조미를 마시기에는 너무 늦을 것입니다 :)
어쨌든 PositionsTotal() 에 초점을 맞춘 IMHO는 잘못된 결정입니다. 귀하의 요청을 처리하는 과정에서, 예를 들어 여러 전문가 고문이 작업하는 경우 계정의 다른 위치가 열리거나 닫힐 수 있습니다. 개발자가 의도한 대로 서버의 응답을 확인하지 못하는 이유는 무엇입니까?
사실 저는 PositionsTotal에서 일반적인 제어를 제외하고는 별 의미가 없습니다. EA는 직위의 티켓을 명확하게 제어하고 이에 대해서만 작업해야 합니다.
ChartIndicatorGet()을 사용한 후에는 IndicatorRelease(handle) 함수를 호출해야 합니다. 이것은 ChartIndicatorGet() 함수 의 예제에 작성되었지만 함수 노트에는 없습니다! 개발자들은 문서를 수정하고 싶었지만 결코 하지 않았습니다. SD의 폐쇄로 인해 이것이 절대 이루어지지 않을 가능성이 있습니다.
개인적으로 "매달린" 표시기 문제가 발생했습니다. SD와의 대화에서:
그리고 그것들. 차트에서 표시기 X를 시작했을 때 모든 표시기를살펴보고 ChartIndicatorGet() 함수를 사용하여 복사본을 찾았 습니다. 카운터가 증가했습니다. 또한 첫 번째 표시기 X - 카운터 감소를 제거했지만 실제로 두 번째 표시기를 잊어 버렸습니다. "매달린"표시기가 있기 때문에 그의 손잡이가 깨끗하지 않은 채로 남아 있었습니까?
따라서 이미 KB에 솔루션이 있었던 것 같습니다.
그러나 대본에는 그렇지 않습니다. 예, 고문에게는 매우 어렵습니다. 왜냐하면. 불확실한 상황에서 OnTick 밖으로 날아가는 것이 좋습니다. 그리고 이러한 상황은 고문의 곱창 깊숙한 곳에서 발생할 수 있습니다. 결과적으로 OnTick을 종료하려면 그곳을 빠져나와야 할 뿐만 아니라, 예를 들어 한 번에 두 개의 포지션(라 바스켓)을 열어야 할 수도 있습니다. 그러나 동시에 첫 번째 항목이 성공적으로 열린 경우에만 두 번째 항목을 여십시오. 이 상황에서 첫 번째 OrderSend 후 OnTick에서 날아가는 것은 가볍게 말해서 나쁜 것입니다.
그러나 대본에는 그렇지 않습니다. 예, 고문에게는 매우 어렵습니다. 왜냐하면. 불확실한 상황에서 OnTick 밖으로 날아가는 것이 좋습니다. 그리고 이러한 상황은 고문의 곱창 깊숙한 곳에서 발생할 수 있습니다. 결과적으로 OnTick을 종료하려면 그곳을 빠져나와야 할 뿐만 아니라, 예를 들어 한 번에 두 개의 포지션(라 바스켓)을 열어야 할 수도 있습니다. 그러나 동시에 첫 번째 것이 성공적으로 완료된 경우에만 두 번째 것을 여십시오. 이 상황에서 첫 번째 OrderSend 후에 OnTick을 떠나는 것은 가볍게 말해서 나쁜 것입니다.
위치 수가 명시적으로 수신될 때까지 스크립트 속도가 느려질 수 있습니다.
Expert Advisor... Expert Advisor에서는 포지션 개설 기능의 논리에서 이것을 고려해야 합니다. 이들은 작업 결과를 반환하면서 Expert Advisor에서 호출됩니다. 시장 주문이 있을 때의 결과는 false를 반환합니다. 그런 다음 고문은 그 안에 포함된 논리에 따라 작동합니다. 예, 동의합니다. 그러한 가능성을 즉시 고려하는 것보다 기성품에 구현하는 것이 더 어렵습니다. 그러나 다른 사람들이 지식을 알고 사용할 수 있도록 분기가 여기에 있습니다.
위치 수가 명시적으로 수신될 때까지 스크립트 속도가 느려질 수 있습니다.
당신은 속도를 늦추고 조언할 수 있습니다.
Expert Advisor... Expert Advisor에서는 포지션 개설 기능의 논리에서 이것을 고려해야 합니다. 이들은 작업 결과를 반환하면서 Expert Advisor에서 호출됩니다. 시장 주문이 있을 때의 결과는 false를 반환합니다. 그런 다음 고문은 그 안에 포함된 논리에 따라 작동합니다. 예, 동의합니다. 그러한 가능성을 즉시 고려하는 것보다 기성품에 구현하는 것이 더 어렵습니다. 그러나 다른 사람들이 지식을 알고 사용할 수 있도록 분기가 여기에 있습니다.
거래가 완료되는 순간까지 조금만 기다리면 됩니다. 다음 틱 전에 TC를 떠나는 것은 끔찍한 결정입니다.
당신은 속도를 늦추고 조언할 수 있습니다.
거래가 완료되는 순간까지 조금만 기다리면 됩니다. 다음 틱 전에 TC를 떠나는 것은 끔찍한 결정입니다.
글쎄, 그 코드에서는 지정된 시간에 대한 기대가 충족됩니다. 그러나 몇 시간 동안 기다릴 수는 없습니다. 유효한 환경을 얻으려는 주어진 횟수의 시도는 얼마 동안 기다린 다음 결과와 함께 종료됩니다. 그렇지 않고 오래 기다리다 보면 거래 환경이 많이 바뀔 수도 있고, 보르조미를 마시기에는 너무 늦을 것입니다 :)
글쎄, 그 코드에서는 지정된 시간에 대한 기대가 충족됩니다. 그러나 몇 시간 동안 기다릴 수는 없습니다. 유효한 환경을 얻으려는 주어진 횟수의 시도는 얼마 동안 기다린 다음 결과와 함께 종료됩니다. 그렇지 않고 오래 기다리다 보면 거래 환경이 많이 바뀔 수도 있고, 보르조미를 마시기에는 너무 늦을 것입니다 :)
예, 대기를 눈치채지 못했습니다. 좋은. 그땐 더 조심 했는데 ...
어쨌든 PositionsTotal() 에 초점을 맞춘 IMHO는 잘못된 결정입니다. 귀하의 요청을 처리하는 과정에서, 예를 들어 여러 전문가 고문이 작업하는 경우 계정의 다른 위치가 열리거나 닫힐 수 있습니다. 개발자가 의도한 대로 서버의 응답을 확인하지 못하는 이유는 무엇입니까?
사실 저는 PositionsTotal에서 일반적인 제어를 제외하고는 별 의미가 없습니다. EA는 직위의 티켓을 명확하게 제어하고 이에 대해서만 작업해야 합니다.
ChartIndicatorGet()을 사용한 후에는 IndicatorRelease(handle) 함수를 호출해야 합니다. 이것은 ChartIndicatorGet() 함수 의 예제에 작성되었지만 함수 노트에는 없습니다! 개발자들은 문서를 수정하고 싶었지만 결코 하지 않았습니다. SD의 폐쇄로 인해 이것이 절대 이루어지지 않을 가능성이 있습니다.
개인적으로 "매달린" 표시기 문제가 발생했습니다. SD와의 대화에서:
그리고 그것들. 차트에서 표시기 X를 시작했을 때 모든 표시기를 살펴보고 ChartIndicatorGet() 함수를 사용하여 복사본을 찾았 습니다. 카운터가 증가했습니다. 또한 첫 번째 표시기 X - 카운터 감소를 제거했지만 실제로 두 번째 표시기를 잊어 버렸습니다. "매달린"표시기가 있기 때문에 그의 손잡이가 깨끗하지 않은 채로 남아 있었습니까?
네. 바로 그 일이 일어납니다. 따라서 OnDeinit는 충족되지 않습니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
CustomRatesUpdate를 사용하여 사용자 지정 기호로 기록 데이터를 csv로 가져오는 방법은 무엇입니까?
fxsaber , 2018.08.19 12:01
포럼의 영어 부분에 표시
의미는 어떻습니까? 몇 바이트의 메모리를 절약하시겠습니까? 특히 두 배의 다른 숫자는 얻어지고(==는 거짓이 됨) 정수는 오버플로가 있을 수 있습니다.