예델킨 : 글쎄요, 저는 이 결론에 동의하지 않습니다. OCO == "하나가 다른 하나를 취소합니다". 글쎄요, MT5에는 한 주문이 실제로 다른 주문을 취소하는 것과 같은 것은 없습니다 . 지금 1년 동안 후회하고 있는 것. ... SL 및 TP와 같은 기회는 실제로 열린 위치를 닫지만 보류 중인 주문 의 "상호 취소" 문제와 관련이 없습니다 .
그들은 단지, 그러나 이것은 서버에서 구현된 명령입니다. 그리고 지금까지 OCO 방식에 실제로 새겨져 있는 유일한 것(그리고 아직 터미널과 서버에서 직접 구현되는 "If Done"은 꿈도 꿀 수 없습니다).
포지션을 열고 TP와 SL을 MT5에 배치함으로써 우리는 본질적으로 이와 같은 것을 알게 됩니다(여기서만 결과는 포지션 + 2개의 상호 취소 주문입니다).
귀하의 메시지 이후에 저는 이미 SL과 TP의 호환성에 대한 참조를 고려하여 상황에 대해 약간 언급했습니다. 여기에 다음을 추가하고 싶습니다.
OCO 주문의 저자가 21세기에 그들의 발명이 SL 및 TP 수준에만 독점적으로 적용될 것이라고 들었다면, 그들은 아이디어 범위의 그러한 제한에 매우 놀랐을 것입니다 :) ... 사실 모든 것이 그렇습니다. 거꾸로 뒤집혔다. 어떤 자료를 읽든 항상 한 가지에 대해 이야기하고 있습니다. OCO 주문은 상호 교체 가능한 주문이며, 그 유형은 이제 MQL5 열거 ENUM_ORDER_TYPE에 반영됩니다. 나는 OCO 주문과 SL-TP 수준 사이의 연결에 대한 언급을 본 적이 없습니다. 저것들. 실행 메커니즘은 동일할 수 있지만 OCO 주문은 SL-TP 수준이 아니라 ENUM_ORDER_TYPE 주문을 기반으로 클라이언트에 의해 발행되었습니다(MQ 버전에 따라).
따라서 보류 중인 주문에 대해 작성할 때 SL-TP 수준에 따른 "파생"* 주문이 아니라 ENUM_ORDER_TYPE 열거형의 주문을 의미합니다.
여러분, 이해의 뿌리는 플랫폼의 단순함에 있습니다. 99%의 사용자를 위한 단순성 합병증을 의식적으로 거부하여 나머지 사용자 비율이 파악할 수 있습니다.
"X백만 명의 사용자를 금융 시장으로 끌어들이기 위해 무엇을 해야 합니까?"라는 질문을 스스로에게 하십시오. 충분한 수준의 경험이 있으면 "단순한 시스템을 만들고 복잡성을 제거하고 단일 생태계에서 거래자를 통합"에 가깝습니다.
OCO 주문 설정을 쌓는 대신(패널은 실제로 평범한 마음을 위한 것이 아닙니다) SL/TP가 통합된 매우 간단하고 이해하기 쉬운 주문 관리 체계를 제안했습니다. 대다수의 OCO 주문은 현재 위치에 대한 SL/TP입니다. 내부에 SL/TP를 도입하여 추가 주문을 최소화하고 거래 관리를 대폭 간소화했습니다.
레플리카. 수백만 명이 오고 수백만 명이 갑니다. 오랫동안 상대적으로 말하자면 동일한 1%가 남아 있습니다. 저것들. OCO와 If-Done을 특별한 정신 발달이 필요한 훌륭한 도구로 생각하지 않는 사람들. 이 1%는 수만 명의 "고급" 사용자로 구성될 것이므로 " 현재 위치 에 대한 OCO 주문만(SL-TP)"으로 충분한지 또는 이에 대해 수백 개의 질문이 있는지 확인할 것입니다. 주제. 지금도 MT5의 대중적 활용이 부족함에도 불구하고, 지금까지 관심을 가진 사람 중 소수에 불과했음에도 불구하고 화제에 대한 관심을 보여왔다.
Yedelkin : 일반적으로 대답은 핵심이 아닙니다. 질문은 구체적이었습니다. "ORDER_MAGIC 이 실제로 속한 유형(long 또는 ulong)은 무엇입니까?"
실제로 사용해 보겠습니다.
1. 변환 없이 이 두 유형을 모두 선언할 수 있습니다.
2. magick의 양수 값만 사용하는 경우 해당 값을 ulong 으로 표시하는 것이 더 유리합니다( 0 에서 18 446 744 073 709 551 615 까지 가능한 값의 범위가 있기 때문).
3. 반면에 표준 라이브러리 의 CExpert 클래스에서 long 값은 초기화 중에 사용됩니다(음수 값을 지정할 수 있지만 가능한 값의 범위를 이동함). 따라서 이 클래스를 초기화할 때 매직 값은 이미 -9 223 372 036 854 775 808 에서 9 223 372 036 854 775 808 사이일 수 있습니다.
이 주장은 검증되어야 합니다 .
4. 그러나 이미 CTrade 클래스(동일한 표준 라이브러리의)에 있는 마법은 요청 구조를 기반으로 해야 하므로 ulong 값을 갖습니다.
예비 결론을 내리자.
a) CExpert 및 CTrade 클래스 의 마술 작업은 일관되지 않습니다. 한 경우에는 long 이 지정되고 다른 경우에는 ulong 이 지정되기 때문입니다.
b) 이 클래스는 다른 사람들에 의해 개발되었거나 CExpert의 특정 기능 매개변수의 구성 및 구조가 CTrade 의 기능을 고려하지 않고 배치 되었습니다 (이것은 자연에 존재할 수도 없습니다).
c) 표준 라이브러리의 개발 및 문서화와 관련된 전문가의 작업은 완전히 조정되지 않았습니다(기본적으로 주요 문제에 대한 상당히 좋은 연구는 볼 수 있지만).
d) 내가 올바르게 이해한다면 이 두 클래스의 상호 작용은 magick 값을 0 에서 9223 372 036 854 775 808 범위로 제한합니다. 이 주장은 검증되어야 합니다 .
5. MqlTradeRequest 구조는 매직 작업을 위한 ulong 유형을 갖습니다. 여기에 있는 모든 것은 CTrade 클래스와 완전히 일치하므로 이 클래스만 사용하는 경우 0 에서 18 446 744 073 709 551 615 사이의 가능한 마법 값 범위를 나타내는 것이 논리적입니다. 이 주장은 검증되어야 합니다.
추신
일반적으로 이 모든 것이 이상합니다. 개발자가 의도적으로 마법의 가능한 값을 0 에서 9223 372 036 854 775 808 범위에서 "압착"한 인상.
모바일 터미널에서 알려주세요.
언제 그리고 mql4 또는 mql5에 대한 사용자 지정 지표 (비표준) 또는 어드바이저에 대한 지원이 제공되나요???????????????????????????????? ???
어떤 플랫폼(예: Android)에서 구현되나요???????????????????????? 그리고 얼마나 빨리?????????????????
귀하의 회신을 고대하고 있습니다. 귀하의 관심을 가져 주셔서 감사합니다.
Interesting :
글쎄요, 저는 이 결론에 동의하지 않습니다. OCO == "하나가 다른 하나를 취소합니다". 글쎄요, MT5에는 한 주문이 실제로 다른 주문을 취소하는 것과 같은 것은 없습니다 . 지금 1년 동안 후회하고 있는 것. ... SL 및 TP와 같은 기회는 실제로 열린 위치를 닫지만 보류 중인 주문 의 "상호 취소" 문제와 관련이 없습니다 .
그들은 단지, 그러나 이것은 서버에서 구현된 명령입니다. 그리고 지금까지 OCO 방식에 실제로 새겨져 있는 유일한 것(그리고 아직 터미널과 서버에서 직접 구현되는 "If Done"은 꿈도 꿀 수 없습니다).
포지션을 열고 TP와 SL을 MT5에 배치함으로써 우리는 본질적으로 이와 같은 것을 알게 됩니다(여기서만 결과는 포지션 + 2개의 상호 취소 주문입니다).
귀하의 메시지 이후에 저는 이미 SL과 TP의 호환성에 대한 참조를 고려하여 상황에 대해 약간 언급했습니다. 여기에 다음을 추가하고 싶습니다.
OCO 주문의 저자가 21세기에 그들의 발명이 SL 및 TP 수준에만 독점적으로 적용될 것이라고 들었다면, 그들은 아이디어 범위의 그러한 제한에 매우 놀랐을 것입니다 :) ... 사실 모든 것이 그렇습니다. 거꾸로 뒤집혔다. 어떤 자료를 읽든 항상 한 가지에 대해 이야기하고 있습니다. OCO 주문은 상호 교체 가능한 주문이며, 그 유형은 이제 MQL5 열거 ENUM_ORDER_TYPE에 반영됩니다. 나는 OCO 주문과 SL-TP 수준 사이의 연결에 대한 언급을 본 적이 없습니다. 저것들. 실행 메커니즘은 동일할 수 있지만 OCO 주문은 SL-TP 수준이 아니라 ENUM_ORDER_TYPE 주문을 기반으로 클라이언트에 의해 발행되었습니다(MQ 버전에 따라).
따라서 보류 중인 주문에 대해 작성할 때 SL-TP 수준에 따른 "파생"* 주문이 아니라 ENUM_ORDER_TYPE 열거형의 주문을 의미합니다.
______________
* "파생" - 각 OCO 주문이 고유한 SL-TP 수준을 가질 수 있기 때문입니다.
여러분, 이해의 뿌리는 플랫폼의 단순함에 있습니다. 99%의 사용자를 위한 단순성 합병증을 의식적으로 거부하여 나머지 사용자 비율이 파악할 수 있습니다.
"X백만 명의 사용자를 금융 시장으로 끌어들이기 위해 무엇을 해야 합니까?"라는 질문을 스스로에게 하십시오. 충분한 수준의 경험이 있으면 "단순한 시스템을 만들고 복잡성을 제거하고 단일 생태계에서 거래자를 통합"에 가깝습니다.
OCO 주문 설정을 쌓는 대신(패널은 실제로 평범한 마음을 위한 것이 아닙니다) SL/TP가 통합된 매우 간단하고 이해하기 쉬운 주문 관리 체계를 제안했습니다. 대다수의 OCO 주문은 현재 위치에 대한 SL/TP입니다. 내부에 SL/TP를 도입하여 추가 주문을 최소화하고 거래 관리를 대폭 간소화했습니다.
ps: 주문 시스템 문제가 종료되었습니다.
ps: 주문 시스템 문제가 종료되었습니다.
ps: 주문 시스템 문제가 종료되었습니다.
개별 거래(전체 포지션이 아님)에 대해 정상적인(신뢰할 수 있는) SL/TP를 만들 수 없는 것이 유감입니다.
이는 동일한 상품/계정에서 여러 전략을 (안정적으로) 거래하는 기능을 즉시 차단합니다.
Hali-thief 재개하지 말 것을 제안합니다. 개발자의 의견을 기억합니다(하나의 도구 = 하나의 위치 = 하나의 SL 및 하나의 TP) ...
ORDER_MAGIC은 실제로 어떤 유형(long 또는 ulong)입니까?
ENUM_ORDER_PROPERTY_INTEGER
ORDER_MAGIC
주문한 전문가의 식별자(각 전문가가 고유한 번호를 설정하도록 의도됨)
긴
ORDER_MAGIC은 실제로 어떤 유형(long 또는 ulong)입니까?
ENUM_ORDER_PROPERTY_INTEGER
ORDER_MAGIC
주문한 전문가의 식별자(각 전문가가 고유한 번호를 설정하도록 의도됨)
긴
내 생각에 결과는 코드에 선언된 형식으로 변환되어야 합니다(문서에 오타가 있을 수 있음).
MqlTradeRequest에서 말해서, 이 경우에는 (ulong) 가능성이 가장 높지만, 설명 없이 long이 작동할 수도 있습니다.
내 생각에 결과는 코드에 선언된 형식으로 변환되어야 합니다(문서에 오타가 있을 수 있음).
MqlTradeRequest 에서 말하면서, 이 경우에는 (ulong) 가능성이 가장 높지만, 설명 없이 long이 작동할 수도 있습니다.
일반적으로 대답은 핵심이 아닙니다. 질문은 구체적이었습니다. "ORDER_MAGIC 이 실제로 속한 유형(long 또는 ulong)은 무엇입니까?"
실제로 사용해 보겠습니다.
1. 변환 없이 이 두 유형을 모두 선언할 수 있습니다.
2. magick의 양수 값만 사용하는 경우 해당 값을 ulong 으로 표시하는 것이 더 유리합니다( 0 에서 18 446 744 073 709 551 615 까지 가능한 값의 범위가 있기 때문).
3. 반면에 표준 라이브러리 의 CExpert 클래스에서 long 값은 초기화 중에 사용됩니다(음수 값을 지정할 수 있지만 가능한 값의 범위를 이동함). 따라서 이 클래스를 초기화할 때 매직 값은 이미 -9 223 372 036 854 775 808 에서 9 223 372 036 854 775 808 사이일 수 있습니다.
이 주장은 검증되어야 합니다 .
4. 그러나 이미 CTrade 클래스(동일한 표준 라이브러리의)에 있는 마법은 요청 구조를 기반으로 해야 하므로 ulong 값을 갖습니다.
예비 결론을 내리자.
a) CExpert 및 CTrade 클래스 의 마술 작업은 일관되지 않습니다. 한 경우에는 long 이 지정되고 다른 경우에는 ulong 이 지정되기 때문입니다.
b) 이 클래스는 다른 사람들에 의해 개발되었거나 CExpert의 특정 기능 매개변수의 구성 및 구조가 CTrade 의 기능을 고려하지 않고 배치 되었습니다 (이것은 자연에 존재할 수도 없습니다).
c) 표준 라이브러리의 개발 및 문서화와 관련된 전문가의 작업은 완전히 조정되지 않았습니다(기본적으로 주요 문제에 대한 상당히 좋은 연구는 볼 수 있지만).
d) 내가 올바르게 이해한다면 이 두 클래스의 상호 작용은 magick 값을 0 에서 9 223 372 036 854 775 808 범위로 제한합니다. 이 주장은 검증되어야 합니다 .
5. MqlTradeRequest 구조는 매직 작업을 위한 ulong 유형을 갖습니다. 여기에 있는 모든 것은 CTrade 클래스와 완전히 일치하므로 이 클래스만 사용하는 경우 0 에서 18 446 744 073 709 551 615 사이의 가능한 마법 값 범위를 나타내는 것이 논리적입니다. 이 주장은 검증되어야 합니다 .
추신
일반적으로 이 모든 것이 이상합니다. 개발자가 의도적으로 마법의 가능한 값을 0 에서 9 223 372 036 854 775 808 범위에서 "압착"한 인상.
일반적으로 이 모든 것이 이상합니다. 개발자가 의도적으로 마법의 가능한 값을 0 에서 9 223 372 036 854 775 808 범위에서 "압착"한 인상.
실제로 매직용으로 8바이트 정도의 정보가 주어지는데, 마음대로 해석할 수 있다. 최소 datetime, 최소 double, 최소 4 short, 최소 8 char, 최소 64비트 비트.
4바이트에서는 4바이트의 마법으로 무엇이든 인코딩할 수 있었고 이제는 8바이트로 늘어났습니다. 욕망이 있을 것입니다.