나는 " 가짜 " 인용문을 가지고 있었다. 그 이유는 진입 조건이 통했고 그에 따라 가격이 ..로 옮겨졌기 때문입니다. 그러나 실제로는 실질 가격이 에 선언된 것보다 낮거나 높았습니다. 그리고 OrderSend 가 주문을 열려고 할 때마다 자연스럽게 오류 138이 발생했습니다.
해결책은 OrderSend 전에 실제 가격이 신호에서 전송된 가격과 같은지 여부를 확인하는 것이었습니다)
RefreshRates();if(Bid==( цена переданная сигналом на продажу ))OrderSend(....);//продажа
OrderModify 주문에 대한 오류를 확인하는 것이 남아 있습니다. 이것은 나쁜 결과를 초래할 수 있습니다. 중지를 설정하지 마십시오!
OrderSend의 경우 신호가주는 가격에 펄스가 사라질 때까지 확인 할 필요가 없다고 생각합니다.) requot가 오면 중요하지 않습니다. .. 매수 또는 매도 시간이 있습니다. 가장 중요한 것은 모든 것이 계획에 따라 작동한다는 것입니다)
나는 " 가짜 " 인용문을 가지고 있었다. 그 이유는 입력 조건이 제대로 작동하여 가격이 OrderSend로 옮겨졌기 때문인데, 실제로 실제 가격은 OrderSend에서 선언한 가격보다 낮거나 높았습니다. 그리고 OrderSend가 주문을 열려고 할 때마다 자연스럽게 오류 138이 발생했습니다.
해결책은 OrderSend 전에 실제 가격이 신호에서 전송된 가격과 같은지 여부를 확인하는 것이었습니다)
오류를 확인하는 .for OrderModify 주문 .. 때문에 남아 있습니다. 이것은 나쁜 결과를 초래할 수 있습니다. 중지를 설정하지 마십시오!
OrderSend의 경우 신호가주는 가격에 펄스가 사라질 때까지 확인 할 필요가 없다고 생각합니다.) requot가 오면 중요하지 않습니다. .. 매수 또는 매도 시간이 있습니다. 가장 중요한 것은 모든 것이 계획에 따라 작동한다는 것입니다)
재생률(); Ask Bid에 문의하기 전에 하는 것이 좋습니다.
스톱 테이크 및 진입 가격을 계산하는 블록 이전 - 현재 가격에서 계산이 이루어지지 않으면 먼 지연에 적용되지 않을 수 있습니다.
모든 경유지를 계산한 후 Bid Ask로 전환하면 즉시 항목이 있어야 합니다! 지체 없이 시장에
한자리에.. 잘 이해가 안가서.. 문제의 논리로) 지표를 오랜만에 만들어서 사이클을 완성하지 못함)))
이것은 나를 위해 보이는 것입니다 :
- 진입 가격은 신호를 확인하는 UpTrend() 및 DownTrend() 함수에 의해 제공됩니다.
- 신호의 가격과 가격이 동일한지 확인(if)
- OrderSend에서 엔트리 가격 등을 처리
- 정지 가격은 OrderSend 다음에 오는 ModifyPos() 함수에서 처리됩니다.
1- 신호 수신 - 실행 플래그 설정 // 신호 확인 기능이 주문 설정 기능을 통과함 테이크 스톱의 2-refresh() 계산 // 가격이 신호의 가격과 일치하는지 확인(여전히 유효한 경우) 3-input // 테이크 계산은 OrderSend에서 정적이며 정류장은 OrderModify 함수에서 계산됩니다. 4-서버 거부됨 //주문이 설정되지 않고 신호가 유효한 경우 신호 가격으로 다시 입력합니다(여전히 유효한 경우). 5-디코드 오류 // 스스로에게 필요, 갑자기 새로운 문제.. 6-신호는 여전히 활성 상태입니다 - 실행 플래그가 설정되었습니까? //가격 일치 조건 - 신호의 가격(여전히 유효한 경우) 7- n 1 // n 3으로 이동
그리고 유능하게이 사이클을 깨는 것이 필요합니다 상당히 길어질 수 있기 때문에 // price == signal price인 동안은 길지 않다고 생각하지만 빈번할 수 있음) 하지만 당신은 필요
1-오류 결정 // 오늘 이 문제를 해결하기 위해 포럼에서 예제를 찾을 것입니다. 2 주기가 //price==signal price를 의미하는 한 딜러를 망치려고 시도합니다. 2.1 예를 들어, 당신은 망치로 몇 번이나 카운터를 만들 수 있습니다 // 당신은 그것에 대해 생각할 필요가 있습니다, 테스터의 기록을보십시오 2.2 당신은 시간 양자를 망치질 수 있습니다 // 나는 가격을 건너뛸 수 있습니다 == 신호의 가격(아직 유효한 경우) 2.3 각 시리즈 전, 실행 명령을 내리기 전에 신호가 있는지 모니터링하는 것은 필수입니다! 그렇지 않으면 취소할 시간이 될 수 있습니다. // 신호 확인 기능이 주문 설정 기능을 통과합니다.
RefreshRates() 함수를 사용하는 올바른 방법은 무엇입니까?
나는 또한 포럼에서 " ERROR: code = 138 - requote"를 읽었습니다.
테스터에서 초당 여러 번 "OrderSend error 138"이 생성되었습니다. 이것은 재인용입니까? 그렇다면 어떻게 대처해야 할까요?)
인용에 대한 20개의 스레드를 읽은 후 ... 마침내 내 실수가 무엇인지 알아 냈습니다)
나는 " 가짜 " 인용문을 가지고 있었다. 그 이유는 진입 조건이 통했고 그에 따라 가격이 ..로 옮겨졌기 때문입니다. 그러나 실제로는 실질 가격이 에 선언된 것보다 낮거나 높았습니다. 그리고 OrderSend 가 주문을 열려고 할 때마다 자연스럽게 오류 138이 발생했습니다.
해결책은 OrderSend 전에 실제 가격이 신호에서 전송된 가격과 같은지 여부를 확인하는 것이었습니다)
OrderModify 주문에 대한 오류를 확인하는 것이 남아 있습니다. 이것은 나쁜 결과를 초래할 수 있습니다. 중지를 설정하지 마십시오!
OrderSend의 경우 신호가주는 가격에 펄스가 사라질 때까지 확인 할 필요가 없다고 생각합니다.) requot가 오면 중요하지 않습니다. .. 매수 또는 매도 시간이 있습니다. 가장 중요한 것은 모든 것이 계획에 따라 작동한다는 것입니다)
인용에 대한 20개의 스레드를 읽은 후 ... 마침내 내 실수가 무엇인지 알아 냈습니다)
나는 " 가짜 " 인용문을 가지고 있었다. 그 이유는 입력 조건이 제대로 작동하여 가격이 OrderSend로 옮겨졌기 때문인데, 실제로 실제 가격은 OrderSend에서 선언한 가격보다 낮거나 높았습니다. 그리고 OrderSend가 주문을 열려고 할 때마다 자연스럽게 오류 138이 발생했습니다.
해결책은 OrderSend 전에 실제 가격이 신호에서 전송된 가격과 같은지 여부를 확인하는 것이었습니다)
오류를 확인하는 .for OrderModify 주문 .. 때문에 남아 있습니다. 이것은 나쁜 결과를 초래할 수 있습니다. 중지를 설정하지 마십시오!
OrderSend의 경우 신호가주는 가격에 펄스가 사라질 때까지 확인 할 필요가 없다고 생각합니다.) requot가 오면 중요하지 않습니다. .. 매수 또는 매도 시간이 있습니다. 가장 중요한 것은 모든 것이 계획에 따라 작동한다는 것입니다)
재생률 ( ) ;
Ask Bid에 문의하기 전에 하는 것이 좋습니다.
스톱 테이크 및 진입 가격을 계산하는 블록 이전 - 현재 가격에서 계산이 이루어지지 않으면 먼 지연에 적용되지 않을 수 있습니다.
재생률 ( ) ;
Ask Bid에 문의하기 전에 하는 것이 좋습니다.
내가 하지 않았나?.. 비드 부르기 전에
스톱 테이크 및 진입 가격을 계산하는 블록 이전 - 현재 가격에서 계산이 이루어지지 않으면 먼 지연에 적용되지 않을 수 있습니다.
내가 하지 않았나?.. Bid에 연락하기 전에
설명해주세요.. 그렇군요. 내 경우에는 여기에 필요하지 않습니까? 왜냐하면 계산하지 않고 비교합니까? 제가 제대로 이해한건가요?
당신은 모든 것을 올바르게했습니다 :-)
그는 방해하지 않을 것입니다!
가격으로 전환하는 블록이 있으면 바람직하게는 한 곳에 있어야 합니다.
이 명령을 사용하기 위해 호출하기 전에 가지고 있는 것이 좋습니다.
모든 정류소를 계산한 후 Bid Ask로 전환하면 즉시 항목이 있어야 합니다! 지체 없이 시장에
---
당신은 이것을 당신의 코드에 추가합니다
간단하게 주다
1 신호 수신 - 실행을 위해 플래그를 올렸습니다.
2-refresh() 중단 계산
3입력
4-서버 거부됨
5-오류 디코딩
6-신호는 여전히 활성 상태입니다 - 실행 플래그가 설정되었습니까?
7- n 1로 이동
그리고 유능하게이 사이클을 깨는 것이 필요합니다
꽤 길어질 수 있기 때문에
하지만 당신은 필요
1-오류 결정
2 사이클이 암시하는 한 딜러를 두드려보십시오.
2.1 예를 들어 망치로 몇 번이나 카운터를 만들 수 있습니다
2.2 당신은 시간의 양에 대해 망치질 수 있습니다
2.3 각 시리즈 전, 실행 명령을 내리기 전에 신호가 있는지 모니터링하는 것은 필수입니다!
아마 취소할 시간이야
...가격으로 전환하는 블록이 있는 것이 바람직합니다.
이 명령을 사용하기 위해 호출하기 전에 가지고 있는 것이 좋습니다.
모든 경유지를 계산한 후 Bid Ask로 전환하면 즉시 항목이 있어야 합니다! 지체 없이 시장에
한자리에.. 잘 이해가 안가서.. 문제의 논리로) 지표를 오랜만에 만들어서 사이클을 완성하지 못함)))
이것은 나를 위해 보이는 것입니다 :
- 진입 가격은 신호를 확인하는 UpTrend() 및 DownTrend() 함수에 의해 제공됩니다.
- 신호의 가격과 가격이 동일한지 확인(if)
- OrderSend에서 엔트리 가격 등을 처리
- 정지 가격은 OrderSend 다음에 오는 ModifyPos() 함수에서 처리됩니다.
1- 신호 수신 - 실행 플래그 설정 // 신호 확인 기능이 주문 설정 기능을 통과함
테이크 스톱의 2-refresh() 계산 // 가격이 신호의 가격과 일치하는지 확인(여전히 유효한 경우)
3-input // 테이크 계산은 OrderSend에서 정적이며 정류장은 OrderModify 함수에서 계산됩니다.
4-서버 거부됨 //주문이 설정되지 않고 신호가 유효한 경우 신호 가격으로 다시 입력합니다(여전히 유효한 경우).
5-디코드 오류 // 스스로에게 필요, 갑자기 새로운 문제..
6-신호는 여전히 활성 상태입니다 - 실행 플래그가 설정되었습니까? //가격 일치 조건 - 신호의 가격(여전히 유효한 경우)
7- n 1 // n 3으로 이동
그리고 유능하게이 사이클을 깨는 것이 필요합니다
상당히 길어질 수 있기 때문에 // price == signal price인 동안은 길지 않다고 생각하지만 빈번할 수 있음)
하지만 당신은 필요
1-오류 결정 // 오늘 이 문제를 해결하기 위해 포럼에서 예제를 찾을 것입니다.
2 주기가 //price==signal price를 의미하는 한 딜러를 망치려고 시도합니다.
2.1 예를 들어, 당신은 망치로 몇 번이나 카운터를 만들 수 있습니다 // 당신은 그것에 대해 생각할 필요가 있습니다, 테스터의 기록을보십시오
2.2 당신은 시간 양자를 망치질 수 있습니다 // 나는 가격을 건너뛸 수 있습니다 == 신호의 가격(아직 유효한 경우)
2.3 각 시리즈 전, 실행 명령을 내리기 전에 신호가 있는지 모니터링하는 것은 필수입니다!
그렇지 않으면 취소할 시간이 될 수 있습니다. // 신호 확인 기능이 주문 설정 기능을 통과합니다.
이제 OrderModify를 올바르게 구현하는 방법을 이해할 수 없습니까? 그거 없으면 멈춤.. 개통시 DC 제한..
- 개봉 후 가격이 변하고 가까울 경우 오류 130이 발생할 수 있습니다.
- 오류 138 requotes를 얻을 수 있으며 가격이 더 올라가고 중지가 전혀 설정되지 않습니다.
- 138개의 재인용 오류가 발생할 수 있으며 가격은 더 낮아질 것입니다. 이는 중요하지 않습니다. 나중에 설치 중지
그래서...
이 옵션의 단점
- 시가가 시가 이하로 내려 가면 스톱이 되지 않습니다.
- 조건이 충족되는 동안 지속적으로 주문을 수정하려고 합니다. 아니면 안 될까요?
그 쯤...
이 옵션의 단점
- 가격이 반대라면 130 오류가 많이 발생합니다.
나는 그런 옵션을 중지에서 고려하면서 설정 될 때까지 내기)
그러나 ModifyB 가 있는 줄에는 오류가 있습니다 . 수정B ;
- ';' - 이미 정의된 변수
- ';' - 이미 정의된 변수
또 다른 옵션이지만 오류(
또 다른 옵션이지만 오류(