성공하지 못한 경우 start() 함수 가 반복될 때 orderclose() 전에 if()를 다시 테스트하고 계속 진행하려면 조건이 여전히 참이므로 다시 닫으려고 시도합니다. 닫으려고 시도할 수 없습니다. start()의 동일한 루프에서 2번, 또 다른 틱을 기다려야 합니까?
Proximus : 성공하지 못한 경우 start() 함수가 반복될 때 orderclose() 전에 if()를 다시 테스트하고 계속 진행하려면 조건이 여전히 참이므로 다시 닫으려고 시도합니다. 닫으려고 시도할 수 없습니다. start()의 동일한 루프에서 2번, 또 다른 틱을 기다려야 합니까?
그것이 실패했다는 것을 알고 싶지 않습니까? 그리고 실패한 경우 실패한 이유는 무엇입니까? 그리고 그것을 실패하게 만들 수 있었던 당시 관련 변수의 값은 무엇이었습니까? 이 모든 것을 안다면 다음 번에 실패하지 않도록 고칠 수 있습니다. . .
Proximus : 성공하지 못한 경우 start() 함수가 반복될 때 orderclose() 전에 if()를 다시 테스트하고 계속 진행하려면 조건이 여전히 참이므로 다시 닫으려고 시도합니다. 닫으려고 시도할 수 없습니다. start()의 동일한 루프에서 2번, 또 다른 틱을 기다려야 합니까?
당신은 그것이 막대의 마지막 틱을 닫아야한다는 것을 시작했습니다.
마지막 눈금 표시줄이 언제 올지 알 수 없음을 이해하려고 했습니다.
이제 닫기가 실패해도 문제가 되지 않습니다. 다음 틱에서 다시, 다시, 다시 시도합니다.
내가 제안한 다른 변경 사항도 놓쳤습니까?
orderclose 후 새로 고침을 만드는 것은 어떤 의미입니까 ??
TAKEPROFITPIPS 대신 미끄러지는 이유를 알고 있습니까?
그것은 errorreturn에 따라 다릅니다. 동일한 루프에서 2번 닫을 수 있습니다.
tradecontext가 너무 바쁘고 루프 내부에 더 많은 거래가 있는 경우 n개의 큰 가능성을 닫을 수도 있습니다.
RaptorUK : 아니오, 이것은 틱이 다음 바의 틱인지 여부에 관계없이 항상 닫힐 것입니다. 거래가 열렸을 때 바 다음에 오는 모든 바에 대해 해당 바 시간[0]은 항상 OrderOpenTime()보다 클 것입니다.
막대의 닫기에 가깝게 닫기를 원하면 현재 눈금이 새 막대의 첫 번째 눈금인지 확인해야 합니다. . . . 그런 다음 한 번의 기회 파 바만 얻을 수 있기 때문에 작업을 종료해야 합니다.
각 틱 후에 start()가 반복되지 않습니까? 내가 잘못?
어쨌든 다음과 같이 상상해보십시오.
OrderOpenTime() = 12:12:01(12시간 12분 1초)
주문이 열리면 Orderclose() 함수 패킷은 기본 코드에서 내 OrderSend() 하나 뒤에 있으므로 주문을 연 직후 내 OrderClose() 패킷은 조건이 주문을 마감하기 위해 충족되었는지 여부를 테스트합니다. 이제 주문을 마감할 시간이 되었습니다.
시간[0]은 이 바의 시가입니다. 따라서 일반적인 논리에 따르면 동일한 바가 열리기 전에는 주문을 열 수 없기 때문에 주문이 열린 시간보다 작아야 합니다. 현재: 12:12:00
그래서 꼭 :
if (Time[ 0 ]>OrderOpenTime())
true 값을 반환하므로 orderclose가 트리거됩니다. 닫을 수 없는 경우 미끄러짐과 같은 어떤 이유로든 문제 없습니다. start() 자체가 반복됩니다.
그리고 다음 반복까지 Time[0]은 논리적이기 때문에 주문의 열기 시간보다 100% 커집니다. 따라서 첫 번째 닫기가 실패하면 이후에 start()가 반복될 때마다 다른 OrderClose()가 발생할 것입니다. 그 자체, 그리고 start() 가 모든 틱마다 반복된다고 생각하기 때문에 주문을 더 빨리 마감하는 더 좋은 방법이 있다고 생각하지 않습니다. 명확하게 설명했으면 좋겠습니다. :)
tradecontext가 너무 바쁘고 루프 내부에 더 많은 거래가 있는 경우 n개의 큰 가능성을 닫을 수도 있습니다.
TAKEPROFITPIPS를 사용하는 이유는 이것이 TAKEPROFIT에 대한 변수이기 때문이며, OrderClose()를 사용하여 주문을 마감할 경우 TP보다 더 많은 미끄러짐이 없어야 한다는 논리가 있기 때문에 TP 수준만큼 최대 미끄러짐을 허용합니다. 그러면 TAKEPROFIT가 OrderClose()보다 더 효율적으로 사용자 대신 닫습니다.
주문이 열리면 Orderclose() 함수 패킷은 기본 코드에서 내 OrderSend() 하나 뒤에 있으므로 주문을 연 직후 내 OrderClose() 패킷은 조건이 주문을 마감하기 위해 충족되었는지 여부를 테스트합니다. 이제 주문을 마감할 시간이 되었습니다.
시간[0]은 이 바의 시가입니다. 따라서 일반적인 논리에 따르면 동일한 바가 열리기 전에는 주문을 열 수 없기 때문에 주문이 열린 시간보다 작아야 합니다. 현재: 12:12:00
그래서 꼭 :
true 값을 반환하므로 orderclose가 트리거됩니다. 닫을 수 없는 경우 미끄러짐과 같은 어떤 이유로든 문제 없습니다. start() 자체가 반복됩니다.
그리고 다음 반복까지 Time[0]은 논리적이기 때문에 주문의 열기 시간보다 100% 커집니다. 따라서 첫 번째 닫기가 실패하면 이후에 start()가 반복될 때마다 다른 OrderClose()가 발생할 것입니다. 그리고 start()가 매 틱마다 반복된다고 생각하기 때문에 주문을 더 빨리 마감하는 더 좋은 방법이 없다고 생각합니다. 명확하게 설명했으면 좋겠습니다. :)
예, 하지만 이것은 이 스레드의 첫 번째 게시물에서 요청한 것이 아닙니다. . . 이제 당신은 마감이 마침표에 의해 지연된 다음 다른 마침표 등으로 지연되는 것이 괜찮다고 말하고 있습니다. 막대 마감에 가깝게 마감하려면 다음 막대의 첫 번째 눈금에서 마감해야 하며 반드시 닫기가 실패했는지 확인 하고 올바른 방법으로 다시 시도하여 닫기에 성공하십시오.
흠 이정도면 좋겠죠?
사실 저는 Time[1]이 1개의 막대를 더 건너뛰었기 때문에 Time[1]을 Time[0]으로 변경했습니다. 그래서 Time[0]은 실제로 Open[0]을 나타냅니다. 누구든지 이것보다 더 나은/매끄러운 것을 알고 있다면 알려주세요!
흠 이정도면 좋겠죠?
사실 저는 Time[1]이 1개의 막대를 더 건너뛰었기 때문에 Time[1]을 Time[0]으로 변경했습니다. 그래서 Time[0]은 실제로 Open[0]을 나타냅니다. 누구든지 이것보다 더 나은/매끄러운 것을 알고 있다면 알려주세요!
RefreshRates(); OrderClose( OrderTicket(), OrderLots(),OrderClosePrice() ,Slippage, CLR_NONE );orderclose가 성공했는지도 확인하십시오 .
orderclose가 성공했는지도 확인하십시오.
성공하지 못한 경우 start() 함수가 반복될 때 orderclose() 전에 if()를 다시 테스트하고 계속 진행하려면 조건이 여전히 참이므로 다시 닫으려고 시도합니다. 닫으려고 시도할 수 없습니다. start()의 동일한 루프에서 2번, 또 다른 틱을 기다려야 합니까?
흠 이정도면 좋겠죠?
사실 저는 Time[1]이 1개의 막대를 더 건너뛰었기 때문에 Time[1]을 Time[0]으로 변경했습니다. 그래서 Time[0]은 실제로 Open[0]을 나타냅니다. 누구든지 이것보다 더 나은/매끄러운 것을 알고 있다면 알려주세요!
막대의 닫기에 가깝게 닫기를 원하면 현재 눈금이 새 막대의 첫 번째 눈금인지 확인해야 합니다. . . . 그런 다음 한 번의 기회 파 바만 얻을 수 있기 때문에 작업을 종료해야 합니다.
성공하지 못한 경우 start() 함수가 반복될 때 orderclose() 전에 if()를 다시 테스트하고 계속 진행하려면 조건이 여전히 참이므로 다시 닫으려고 시도합니다. 닫으려고 시도할 수 없습니다. start()의 동일한 루프에서 2번, 또 다른 틱을 기다려야 합니까?
당신은 그것이 막대의 마지막 틱을 닫아야한다는 것을 시작했습니다.
마지막 눈금 표시줄이 언제 올지 알 수 없음을 이해하려고 했습니다.
이제 닫기가 실패해도 문제가 되지 않습니다. 다음 틱에서 다시, 다시, 다시 시도합니다.
내가 제안한 다른 변경 사항도 놓쳤습니까?
orderclose 후 새로 고침을 만드는 것은 어떤 의미입니까 ??
TAKEPROFITPIPS 대신 미끄러지는 이유를 알고 있습니까?
그것은 errorreturn에 따라 다릅니다. 동일한 루프에서 2번 닫을 수 있습니다.
tradecontext가 너무 바쁘고 루프 내부에 더 많은 거래가 있는 경우 n개의 큰 가능성을 닫을 수도 있습니다.
아니오, 이것은 틱이 다음 바의 틱인지 여부에 관계없이 항상 닫힐 것입니다. 거래가 열렸을 때 바 다음에 오는 모든 바에 대해 해당 바 시간[0]은 항상 OrderOpenTime()보다 클 것입니다.
막대의 닫기에 가깝게 닫기를 원하면 현재 눈금이 새 막대의 첫 번째 눈금인지 확인해야 합니다. . . . 그런 다음 한 번의 기회 파 바만 얻을 수 있기 때문에 작업을 종료해야 합니다.
각 틱 후에 start()가 반복되지 않습니까? 내가 잘못?
어쨌든 다음과 같이 상상해보십시오.
OrderOpenTime() = 12:12:01(12시간 12분 1초)
주문이 열리면 Orderclose() 함수 패킷은 기본 코드에서 내 OrderSend() 하나 뒤에 있으므로 주문을 연 직후 내 OrderClose() 패킷은 조건이 주문을 마감하기 위해 충족되었는지 여부를 테스트합니다. 이제 주문을 마감할 시간이 되었습니다.
시간[0]은 이 바의 시가입니다. 따라서 일반적인 논리에 따르면 동일한 바가 열리기 전에는 주문을 열 수 없기 때문에 주문이 열린 시간보다 작아야 합니다. 현재: 12:12:00
그래서 꼭 :
true 값을 반환하므로 orderclose가 트리거됩니다. 닫을 수 없는 경우 미끄러짐과 같은 어떤 이유로든 문제 없습니다. start() 자체가 반복됩니다.
그리고 다음 반복까지 Time[0]은 논리적이기 때문에 주문의 열기 시간보다 100% 커집니다. 따라서 첫 번째 닫기가 실패하면 이후에 start()가 반복될 때마다 다른 OrderClose()가 발생할 것입니다. 그 자체, 그리고 start() 가 모든 틱마다 반복된다고 생각하기 때문에 주문을 더 빨리 마감하는 더 좋은 방법이 있다고 생각하지 않습니다. 명확하게 설명했으면 좋겠습니다. :)
당신은 그것이 막대의 마지막 틱을 닫아야한다는 것을 시작했습니다.
마지막 눈금 표시줄이 언제 올지 알 수 없음을 이해하려고 했습니다.
이제 닫기가 실패해도 문제가 되지 않습니다. 다음 틱에서 다시, 다시, 다시 시도합니다.
내가 제안한 다른 변경 사항도 놓쳤습니까?
orderclose 후 새로 고침을 만드는 것은 어떤 의미입니까 ??
TAKEPROFITPIPS 대신 미끄러지는 이유를 알고 있습니까?
그것은 errorreturn에 따라 다릅니다. 동일한 루프에서 2번 닫을 수 있습니다.
tradecontext가 너무 바쁘고 루프 내부에 더 많은 거래가 있는 경우 n개의 큰 가능성을 닫을 수도 있습니다.
각 틱 후에 start()가 반복되지 않습니까? 내가 잘못?
예, 여전히 실행 중이 아닌 한 각 틱에 대해 start()가 호출됩니다. . .
어쨌든 다음과 같이 상상해보십시오.
OrderOpenTime() = 12:12:01(12시간 12분 1초)
주문이 열리면 Orderclose() 함수 패킷은 기본 코드에서 내 OrderSend() 하나 뒤에 있으므로 주문을 연 직후 내 OrderClose() 패킷은 조건이 주문을 마감하기 위해 충족되었는지 여부를 테스트합니다. 이제 주문을 마감할 시간이 되었습니다.
시간[0]은 이 바의 시가입니다. 따라서 일반적인 논리에 따르면 동일한 바가 열리기 전에는 주문을 열 수 없기 때문에 주문이 열린 시간보다 작아야 합니다. 현재: 12:12:00
그래서 꼭 :
true 값을 반환하므로 orderclose가 트리거됩니다. 닫을 수 없는 경우 미끄러짐과 같은 어떤 이유로든 문제 없습니다. start() 자체가 반복됩니다.
그리고 다음 반복까지 Time[0]은 논리적이기 때문에 주문의 열기 시간보다 100% 커집니다. 따라서 첫 번째 닫기가 실패하면 이후에 start()가 반복될 때마다 다른 OrderClose()가 발생할 것입니다. 그리고 start()가 매 틱마다 반복된다고 생각하기 때문에 주문을 더 빨리 마감하는 더 좋은 방법이 없다고 생각합니다. 명확하게 설명했으면 좋겠습니다. :)
바의 종가 가 후속 바에서 반복되지 않는 경우는 매우 드뭅니다. 반드시 시가가 아닌...