명령문 1. 보류 중인 주문이 실행된 후 이 주문의 개시 날짜에 액세스할 때 모든 코드(실행된 시점에 시장 주문이 됨)는 보류 중인 설정 날짜와 동일한 개시 날짜를 수신합니다. OrderOpenTime() 함수가 작동합니다.
진술 2. 전문가 고문이 계정의 주문 상태를 지속적으로 모니터링하지 않으면 보류 중인 트리거의 정확한 시간을 기억할 수 없습니다.
가능한 해결책 1. 보류 날짜부터 현재 날짜까지 bar-by-bar로 실행하고 보류 트리거 수준과 시가가 처음 교차하는 시간을 기록합니다.
어느 정도 정확한 시간이 되겠지만, 스프레드라는 큰 단점이 있습니다. 왜냐하면 스프레드는 역사에 기록되지 않았습니다(예를 들어 Dukas의 스프레드가 있는 진드기 역사 버전은 여기에서 다루지 않습니다. 지금은 Dukas와 그녀를 거래하지 않기 때문에 스프레드가 있는 이러한 역사는 다음을 수행해야 합니다. 쓰기 및 누적), 아마도 가격이 시작 수준에 거의 도달했지만 교차하지 않은 훨씬 더 일찍 주문이 작동했을 수 있으며 확장 된 스프레드로 인해 주문이 이미 열렸고 나중에는 실제를 볼 때 열리지 않았습니다. 가격에 의한 보류 라인의 교차.
가장 가능성 있는 솔루션은 Expert Advisor를 만들어 차트에 매달고 계정의 주문을 모니터링하는 것입니다. 나는 이것을하고 싶지 않습니다. 여러 가지 이유로 Expert Advisor의 작업에서 휴식 시간 동안 가능한 문제와 관련된 단점이 있지만 다른 생각은 아직 일어나지 않아야한다는 것을 알 수 있습니다.
기능, 고양이에 관한 것. OrderOpenTime() 함수를 호출할 수 있는 링크를 제공했습니다. 작동한 지연자의 경우 트리거된 날짜가 아니라 설정된 날짜가 됩니다. 따라서 사용 가능한 기능이 적합하지 않습니다. 그리고 그것들을 정리할 방법도 없습니다. 왜냐하면. 어쨌든 주문 시작 날짜에 대해 OrderOpenTime()에 적용됩니다.
당신의 진술에 대해 나를 괴롭히는 것이 있습니다. 예를 들어, 티켓 12로 보류 주문 을 변환한 후, 티켓 12에 대한 보류 주문은 기록에 없을 것입니다. 티켓 12가 있는 열린 위치가 있을 것이며 유형은 OP_BUY 또는 OP_SELL이 됩니다. 개장 시간은 보류 중인 주문이 시장 주문으로 전환되는 시간입니다.
틀리면 고쳐주세요...
저것들. 어떤 경우에도 주문 기록을 보관할 고문이 필요합니다. 각 틱에서 보류 중인 주문이 있는지 확인하고 해당 티켓을 기억한 다음(주문이 있는 경우) 열린 위치의 티켓을 보류 중인 것과 비교합니다. 일치하는 항목을 찾으면 열린 시간을 기억하십시오. 그것은 당신이 찾고있는 것입니다 ...
당신의 진술에 대해 나를 괴롭히는 것이 있습니다. 예를 들어, 티켓 12로 보류 주문을 변환한 후, 티켓 12에 대한 보류 주문은 기록에 없을 것입니다. 티켓 12가 있는 열린 위치가 있을 것이며 유형은 OP_BUY 또는 OP_SELL이 됩니다. 개장 시간은 보류 중인 주문이 시장 주문으로 전환되는 시간입니다.
틀리면 고쳐주세요...
저것들. 어떤 경우에도 주문 기록을 보관할 고문이 필요합니다. 각 틱에서 보류 중인 주문이 있는지 확인하고 해당 티켓을 기억한 다음(주문이 있는 경우) 열린 위치의 티켓을 보류 중인 것과 비교합니다. 일치하는 항목을 찾으면 열린 시간을 기억하십시오. 그것은 당신이 찾고있는 것입니다 ...
예, 보류 중인 주문이 실행된 후 시장 주문 티켓이 변경되지 않았습니다(적어도 내 브로커의 경우).
시장 위치 를 여는 시간은 연기자의 변화의 시간이 될 것입니다 - kr. 주문 중 하나의 예를 사용하여 지금 로그를 비교했습니다.
이에 근거한 진술 1은 분명히 사실이 아닙니다. 내일, 새로운 마음으로 모든 것을 다시 한 번 확인하겠습니다. 그렇지 않으면 이틀 밤 동안 깊이 생각했습니다(정확히는 아님). 뇌는 이미 흐려져 있습니다.
보류 중이던 시장의 OrderOpenTime()이 여전히 개장 시간을 제공한다면 전혀 문제가 없으며 주문을 추적하기 위해 Expert Advisor가 필요하지 않습니다. 필요한 것은 오픈 시간과 마감 플래그별로 기록에서 주문을 올바르게 정렬하기 위해 보류 중인 트리거 시간뿐이었습니다. 그리고 역사에 단지 시장 하나만 있을 것이고, 연기된 것에 따라 깃발이 없을 것이고, 그것이 연기였다는 것은 중요하지 않습니다. 이것은 필수 사항이 아닙니다. 사실 자체가 중요합니다. 마지막으로 마감된 것이 가장 최근에 오픈한 날짜가 우리의 고객입니다. 여기 있습니다.
단지 내 스크립트가 가장 최근에 열린 시간과 함께 마지막으로 마감된 주문을 발행할 수 없었고, 정확히 대기 중인 주문이 실행되었을 뿐입니다. 일반적으로 모든 것을 확인할 것입니다. 팁 감사합니다, 매우 도움이 됩니다!
결과적으로 컴파일러는 이러한 오류를 보여 주었고 내가 이해한대로 변수의 잘못된 정의를 나타냅니다.PapaYozh 님 , 피드백 감사합니다. 하지만 이 함수를 int start()에도 삽입했는데 컴파일러 결과가 전혀 바뀌지 않습니다.
다시:
선적 서류 비치:
int OrderSend (문자열 기호, int cmd, 이중 볼륨, 이중 가격, int 미끄러짐, 이중 손절매, 이중 이익실현, string comment=NULL, int magic=0, datetime 만료=0 , color arrow_color=CLR_NONE)
"최신" 행에 10번째 매개변수가 있습니다. 이는 숫자가 아닙니다. 그렇기 때문에 오류가
그럼 제거만 하면 되는건가요?
호출된 함수에 매개변수를 올바르게 전달해야 합니다.
얘들아 제발 도와줘
Voldemar, 사람들은 모든 독, 교과서 및 예제에 반영된 내용을 전달하려고 합니다. 사용자 함수의 본문은 예를 들어 Start 함수의 마지막 줄 뒤에 다른 함수의 외부에 있어야 합니다.
소중한 시간을 내어주신 granit77님 과 모든 분들께 감사드립니다.처음으로 목표를 달성한 모습에 다들 기뻐하셨을 거라 생각해서 성공했습니다.
감사해요!!!!
...가까운 장래에 이곳에서 누군가를 도울 수 있기를 바랍니다.
얘들아 제발 도와줘
잡고 싶습니까? :)))))
"최신"을 숫자로 바꿉니다.
문제의 본질을 잘 전달하지 못한 것 같습니다.
명령문 1. 보류 중인 주문이 실행된 후 이 주문의 개시 날짜에 액세스할 때 모든 코드(실행된 시점에 시장 주문이 됨)는 보류 중인 설정 날짜와 동일한 개시 날짜를 수신합니다. OrderOpenTime() 함수가 작동합니다.
진술 2. 전문가 고문이 계정의 주문 상태를 지속적으로 모니터링하지 않으면 보류 중인 트리거의 정확한 시간을 기억할 수 없습니다.
가능한 해결책 1. 보류 날짜부터 현재 날짜까지 bar-by-bar로 실행하고 보류 트리거 수준과 시가가 처음 교차하는 시간을 기록합니다.
어느 정도 정확한 시간이 되겠지만, 스프레드라는 큰 단점이 있습니다. 왜냐하면 스프레드는 역사에 기록되지 않았습니다(예를 들어 Dukas의 스프레드가 있는 진드기 역사 버전은 여기에서 다루지 않습니다. 지금은 Dukas와 그녀를 거래하지 않기 때문에 스프레드가 있는 이러한 역사는 다음을 수행해야 합니다. 쓰기 및 누적), 아마도 가격이 시작 수준에 거의 도달했지만 교차하지 않은 훨씬 더 일찍 주문이 작동했을 수 있으며 확장 된 스프레드로 인해 주문이 이미 열렸고 나중에는 실제를 볼 때 열리지 않았습니다. 가격에 의한 보류 라인의 교차.
가장 가능성 있는 솔루션은 Expert Advisor를 만들어 차트에 매달고 계정의 주문을 모니터링하는 것입니다. 나는 이것을하고 싶지 않습니다. 여러 가지 이유로 Expert Advisor의 작업에서 휴식 시간 동안 가능한 문제와 관련된 단점이 있지만 다른 생각은 아직 일어나지 않아야한다는 것을 알 수 있습니다.
기능, 고양이에 관한 것. OrderOpenTime() 함수를 호출할 수 있는 링크를 제공했습니다. 작동한 지연자의 경우 트리거된 날짜가 아니라 설정된 날짜가 됩니다. 따라서 사용 가능한 기능이 적합하지 않습니다. 그리고 그것들을 정리할 방법도 없습니다. 왜냐하면. 어쨌든 주문 시작 날짜에 대해 OrderOpenTime()에 적용됩니다.
당신의 진술에 대해 나를 괴롭히는 것이 있습니다. 예를 들어, 티켓 12로 보류 주문 을 변환한 후, 티켓 12에 대한 보류 주문은 기록에 없을 것입니다. 티켓 12가 있는 열린 위치가 있을 것이며 유형은 OP_BUY 또는 OP_SELL이 됩니다. 개장 시간은 보류 중인 주문이 시장 주문으로 전환되는 시간입니다.
틀리면 고쳐주세요...
저것들. 어떤 경우에도 주문 기록을 보관할 고문이 필요합니다. 각 틱에서 보류 중인 주문이 있는지 확인하고 해당 티켓을 기억한 다음(주문이 있는 경우) 열린 위치의 티켓을 보류 중인 것과 비교합니다. 일치하는 항목을 찾으면 열린 시간을 기억하십시오. 그것은 당신이 찾고있는 것입니다 ...
그러한 질문 - 테스터를 통해 실행하는 올빼미에 스크립트 및 타사 고문("자신을 거래하지 않음" 시리즈)을 사용할 수 있습니까?
잡고 싶습니까? :)))))
"최신"을 숫자로 바꿉니다.
당신의 진술에 대해 나를 괴롭히는 것이 있습니다. 예를 들어, 티켓 12로 보류 주문을 변환한 후, 티켓 12에 대한 보류 주문은 기록에 없을 것입니다. 티켓 12가 있는 열린 위치가 있을 것이며 유형은 OP_BUY 또는 OP_SELL이 됩니다. 개장 시간은 보류 중인 주문이 시장 주문으로 전환되는 시간입니다.
틀리면 고쳐주세요...
저것들. 어떤 경우에도 주문 기록을 보관할 고문이 필요합니다. 각 틱에서 보류 중인 주문이 있는지 확인하고 해당 티켓을 기억한 다음(주문이 있는 경우) 열린 위치의 티켓을 보류 중인 것과 비교합니다. 일치하는 항목을 찾으면 열린 시간을 기억하십시오. 그것은 당신이 찾고있는 것입니다 ...
예, 보류 중인 주문이 실행된 후 시장 주문 티켓이 변경되지 않았습니다(적어도 내 브로커의 경우).
시장 위치 를 여는 시간은 연기자의 변화의 시간이 될 것입니다 - kr. 주문 중 하나의 예를 사용하여 지금 로그를 비교했습니다.
이에 근거한 진술 1은 분명히 사실이 아닙니다. 내일, 새로운 마음으로 모든 것을 다시 한 번 확인하겠습니다. 그렇지 않으면 이틀 밤 동안 깊이 생각했습니다(정확히는 아님). 뇌는 이미 흐려져 있습니다.
보류 중이던 시장의 OrderOpenTime()이 여전히 개장 시간을 제공한다면 전혀 문제가 없으며 주문을 추적하기 위해 Expert Advisor가 필요하지 않습니다. 필요한 것은 오픈 시간과 마감 플래그별로 기록에서 주문을 올바르게 정렬하기 위해 보류 중인 트리거 시간뿐이었습니다. 그리고 역사에 단지 시장 하나만 있을 것이고, 연기된 것에 따라 깃발이 없을 것이고, 그것이 연기였다는 것은 중요하지 않습니다. 이것은 필수 사항이 아닙니다. 사실 자체가 중요합니다. 마지막으로 마감된 것이 가장 최근에 오픈한 날짜가 우리의 고객입니다. 여기 있습니다.
단지 내 스크립트가 가장 최근에 열린 시간과 함께 마지막으로 마감된 주문을 발행할 수 없었고, 정확히 대기 중인 주문이 실행되었을 뿐입니다. 일반적으로 모든 것을 확인할 것입니다. 팁 감사합니다, 매우 도움이 됩니다!