TP 및 SL 주문 창에서 절대 값뿐만 아니라 상대 값에서도 필요하며 마지막 값의 자동 대체가 필요합니다. 예를 들어, TP=2 및 SL=10에 한 번 베팅한 다음 매수 또는 매도만 합니다. 즉, 건강에 도움이 됩니다. 매우 편리할 것입니다. 그렇지 않으면 이러한 불편함 때문에 제가 최근에 어드바이저를 일부러 벙어리로 만들어서 제가 매수 또는 매도를 클릭한 후 그가 TP와 SL을 주어진 값으로 설정하도록 했습니다.
크로넥스 : 이미 활성 주문에서 Magic을 재할당하는 것에 관한 것이었습니까? 아이디어는 간단합니다. 다중 기간 거래를 사용하면 긴 추세 로 더 높은 기간으로 주문을 이전 할 수 있습니다.
조금 더 자세하게 가능할까요? 무슨 뜻인가요?
간단히 말해서: 저는 4개 기간 동안 단일 거래 전략을 사용합니다. 하나의 알고리즘(지표 집합 및 신호 유형)에 따른 진입/퇴장/후행의 원칙이지만 각 기간에 대한 지표의 매개 변수는 자연스럽게 다릅니다(실제로 이들은 하나의 차트에 4명의 Expert Advisors임), 마법 . 결과적으로, 낮은 기간에는 시장 상황보다 훨씬 더 일찍 포지션을 마감 한다는 모든 징후가 있음이 밝혀졌습니다(즉, 잘못된 방향으로 재채기를 하면 이익이 부족함). 매우 안정적입니다. 변동성의 상대성은 지표에 영향을 미칩니다. 더 높은 시간 프레임의 안정적인 상황에서 더 낮은 시간 프레임의 열린 위치가 닫히지 않아야 하지만 Magic을 변경하여 더 높은 시간 프레임의 논리로 이전해야 합니다. 예, 실제로 응용 프로그램은 시간 프레임뿐만 아니라 다른 처리 논리로 전송하기 위한 것입니다. DC에 특별한 문제는 없을 것 같습니다. 티켓은 남아 있지만 혜택은 누적 될 수 있습니다.
Cronex : 간단히 말해서: 저는 4개 기간 동안 단일 거래 전략을 사용합니다. 하나의 알고리즘(지표 집합 및 신호 유형)에 따른 진입/퇴장/후행의 원칙이지만 각 기간에 대한 지표의 매개 변수는 자연스럽게 다릅니다(실제로 이들은 하나의 차트에 4명의 Expert Advisors임), 마법 . 결과적으로, 낮은 기간에는 시장 상황보다 훨씬 더 일찍 포지션을 마감한다는 모든 징후가 있음이 밝혀졌습니다(즉, 잘못된 방향으로 재채기를 하면 이익이 부족함). 매우 안정적입니다. 변동성의 상대성은 지표에 영향을 미칩니다. 더 높은 시간 프레임의 안정적인 상황에서 더 낮은 시간 프레임의 열린 위치는 닫히지 않아야 하지만 Magic을 변경하여 더 높은 시간 프레임의 논리로 이전해야 합니다. 예, 실제로 응용 프로그램은 시간 프레임뿐만 아니라 다른 처리 논리로 전송하기 위한 것입니다. DC에 특별한 문제는 없을 것 같습니다. 티켓은 남아 있지만 혜택은 누적 될 수 있습니다.
의미는 분명합니다.
하지만 그런 생각을 하기 위해서는 단말과 서버 사이의 통신 언어나 기술에 변화를 줄 필요는 없다고 생각합니다. 결국 터미널 측면의 프로그램에서 필요한 모든 것을 고려할 수 있습니다. 또한, 마법을 변경한다는 바로 그 아이디어는 전략과 그 기준의 단점을 웅변적으로 증언합니다. 마법(귀하의 예에서 분명히 알 수 있듯이)은 원칙적으로 질서를 닫아야 하는 흔들리지 않는 기준을 가지고 있지 않으며 수행할 수도 없습니다. 또는 열다 전략이 마법에 기반할 수 없고 해서는 안 된다는 것을 이해하는 것은 쉽습니다(주문에 연결됨). 마술은 시장과 아무 관련이 없기 때문입니다.
제 생각에는 이것이 거래의 중요한 순간 중 하나입니다. 그냥 그 언어로 마술사가 나타나서 겨드랑이에 빠졌고, 우리-붙어보자.. 사실 선사시대 시장가 주문 시가가 없기 때문에 상황은 새로운 틱마다 새로운 틱으로 간주해야합니다. ).
그리고 마술은 다소 유용하지만 제 생각에는 회계에 매우 편리한 메커니즘이 아닙니다. 누가 무엇을 압니까? 제 생각에는 주문이 고유하게 식별될 수 있다면(재개 및 부분적으로 닫힐 때) 마법의 의미가 완전히 사라질 것입니다.
제 생각에는 객체에 대한 주문을 받으면 프로그래밍의 관점에서 현재 마술은 SL 또는 TP 수준과 같은이 객체의 본격적인 가변 속성입니다. 어쩌면 내가 틀릴 수도 있지만 MQL에서는 현재 가능한 모든 단계(다시 열고 부분적으로 닫을 때)에서 터미널에서 실행된 코드와 관련하여 순서를 고유하게 식별할 수 없으며 마법은 이 상황을 다음과 같이 보상합니다. 더 큰 범위. 마술은 시장에 얽매여서는 안 됩니다. 단지 범위가 다르고 의미 이외의 의미론적 부하가 없을 뿐입니다.
시장 상황을 비역사적이라고 생각하는 입장에서 님의 의견에 동의하지 않겠습니다만... 이건 제 개인적인 생각입니다. 수익성 있는 주문의 경우 결정을 내리기 위해 더 높은 시간 프레임을 살펴보거나 약간의 롤백을 두고 더 높은 시간 프레임에 주문 작업을 계속하거나 단순히 잠재 고객이 없기 때문에 종료하는 것이 합리적입니다.
나는 전략의 일관성과 결함에 대해 논의하지 않을 것입니다 - 전적으로 동의합니다 ...하지만 나는 이것에 대해 일하고 있습니다 :-)
서버와 단말 사이의 교환 언어와 프로토콜을 어떻게 변경해야 하는지 모르겠습니다... 현재로서는 매직 값의 할당이 이미 존재하며 주문할 때 서버에서 수락합니다. 교환 프로토콜 형식에 대한 정보는 없지만 전송을 통해 특정 데이터 구조의 패킷 전송에 이어 일관성 검증이 뒤따르는 것이라는 의혹이 있다. OrderModify 에 전달된 데이터 구조에 선택적 매개변수를 하나 더 추가하는 것은 어렵지 않다고 생각합니다. 나는 개발자들이 원자 교환 프로토콜의 길을 택하여 버저닝 지원이라는 어려운 과정에 스스로를 몰아넣었다는 것을 깊이 의심합니다.
아마도 이미 말한 것입니다 ...
1) 암호화를 사용할 때 컴파일하는 기능을 추가하고 컴퓨터 ID를 참조하여 일련 번호를 생성하는 기능(아르만딜로 패커의 아날로그)을 추가합니다.
이 모든 것은 소스가 아닌 번역가의 내부 능력 수준에서 수행되어야 합니다.
2) 외부 프로그램과 대화식으로 작업하는 기능을 추가하여 다른 프로그램에서 터미널 작동을 제어하고, 서버에 연결/연결 해제하고, 서버와의 연결을 확인하고, 견적 아카이브를 요청하고, 주문을 ... 등.
3) 들어오는 틱에 관계없이 주문을 할 수 있는 기능
4) 여러 DC/계정 동시 작업 지원
5) 디버그 DLL 가져오기
6) 최소한 구조에 대한 지원을 추가하지만 일반적으로 가능성을 확장하여 C++에 더 가깝도록 하는 것이 바람직합니다.
도움말 cat에 실행 가능한 전환 가능성을 추가해야 합니다. 프로그램을 웹 페이지로 가져옵니다(예: 원하는 텍스트가 있는 창 열기).
사용자가 이해할 수 없는 일을 했습니다. 프로그램이 알려줍니다. 상황에 대한 상담이 있습니다. 올바르게 읽고 더 어리석은 행동을 하지 마십시오.
스크,
TP 및 SL 주문 창에서 절대 값뿐만 아니라 상대 값에서도 필요하며 마지막 값의 자동 대체가 필요합니다. 예를 들어, TP=2 및 SL=10에 한 번 베팅한 다음 매수 또는 매도만 합니다. 즉, 건강에 도움이 됩니다. 매우 편리할 것입니다. 그렇지 않으면 이러한 불편함 때문에 제가 최근에 어드바이저를 일부러 벙어리로 만들어서 제가 매수 또는 매도를 클릭한 후 그가 TP와 SL을 주어진 값으로 설정하도록 했습니다.
너무 많은 소원! 벌써 28페이지!
나는 개발자들로부터 어떤 소망이 이미 개발 중이고 결코 구현되지 않을 것이며 어떤 것이 될 수 있는지 듣고 싶습니다.
그리고 다른 것을 원할 가치가 있는지 여부가 명확하지 않으며 피드백을 볼 수 없습니다.
물론 나도 타이밍을 알고 싶었다. 소프트웨어 출시 시기를 예측하는 것이 환율 의 움직임을 예측하는 것보다 쉽지 않다는 것을 이해합니다.
글쎄, 적어도 이런 형태로: "MT5의 베타 버전은 .............보다 빨리 출시될 것입니다.". 그런 문장을 쓸 수 있을까?
그리고 다른 것을 원할 가치가 있는지 또는 피드백이 가시적인지 명확하지 않습니다.
이미 활성 주문에서 Magic을 재할당하는 것에 관한 것이었습니까? 아이디어는 간단합니다. 다중 기간 거래를 사용하면 긴 추세 로 더 높은 기간으로 주문을 이전 할 수 있습니다.
이미 활성 주문에서 Magic을 재할당하는 것에 관한 것이었습니까? 아이디어는 간단합니다. 다중 기간 거래를 사용하면 긴 추세 로 더 높은 기간으로 주문을 이전 할 수 있습니다.
간단히 말해서: 저는 4개 기간 동안 단일 거래 전략을 사용합니다. 하나의 알고리즘(지표 집합 및 신호 유형)에 따른 진입/퇴장/후행의 원칙이지만 각 기간에 대한 지표의 매개 변수는 자연스럽게 다릅니다(실제로 이들은 하나의 차트에 4명의 Expert Advisors임), 마법 . 결과적으로, 낮은 기간에는 시장 상황보다 훨씬 더 일찍 포지션을 마감 한다는 모든 징후가 있음이 밝혀졌습니다(즉, 잘못된 방향으로 재채기를 하면 이익이 부족함). 매우 안정적입니다. 변동성의 상대성은 지표에 영향을 미칩니다. 더 높은 시간 프레임의 안정적인 상황에서 더 낮은 시간 프레임의 열린 위치가 닫히지 않아야 하지만 Magic을 변경하여 더 높은 시간 프레임의 논리로 이전해야 합니다. 예, 실제로 응용 프로그램은 시간 프레임뿐만 아니라 다른 처리 논리로 전송하기 위한 것입니다. DC에 특별한 문제는 없을 것 같습니다. 티켓은 남아 있지만 혜택은 누적 될 수 있습니다.
간단히 말해서: 저는 4개 기간 동안 단일 거래 전략을 사용합니다. 하나의 알고리즘(지표 집합 및 신호 유형)에 따른 진입/퇴장/후행의 원칙이지만 각 기간에 대한 지표의 매개 변수는 자연스럽게 다릅니다(실제로 이들은 하나의 차트에 4명의 Expert Advisors임), 마법 . 결과적으로, 낮은 기간에는 시장 상황보다 훨씬 더 일찍 포지션을 마감한다는 모든 징후가 있음이 밝혀졌습니다(즉, 잘못된 방향으로 재채기를 하면 이익이 부족함). 매우 안정적입니다. 변동성의 상대성은 지표에 영향을 미칩니다. 더 높은 시간 프레임의 안정적인 상황에서 더 낮은 시간 프레임의 열린 위치는 닫히지 않아야 하지만 Magic을 변경하여 더 높은 시간 프레임의 논리로 이전해야 합니다. 예, 실제로 응용 프로그램은 시간 프레임뿐만 아니라 다른 처리 논리로 전송하기 위한 것입니다. DC에 특별한 문제는 없을 것 같습니다. 티켓은 남아 있지만 혜택은 누적 될 수 있습니다.
의미는 분명합니다.
하지만 그런 생각을 하기 위해서는 단말과 서버 사이의 통신 언어나 기술에 변화를 줄 필요는 없다고 생각합니다. 결국 터미널 측면의 프로그램에서 필요한 모든 것을 고려할 수 있습니다. 또한, 마법을 변경한다는 바로 그 아이디어는 전략과 그 기준의 단점을 웅변적으로 증언합니다. 마법(귀하의 예에서 분명히 알 수 있듯이)은 원칙적으로 질서를 닫아야 하는 흔들리지 않는 기준을 가지고 있지 않으며 수행할 수도 없습니다. 또는 열다 전략이 마법에 기반할 수 없고 해서는 안 된다는 것을 이해하는 것은 쉽습니다(주문에 연결됨). 마술은 시장과 아무 관련이 없기 때문입니다.
제 생각에는 이것이 거래의 중요한 순간 중 하나입니다. 그냥 그 언어로 마술사가 나타나서 겨드랑이에 빠졌고, 우리-붙어보자.. 사실 선사시대 시장가 주문 시가가 없기 때문에 상황은 새로운 틱마다 새로운 틱으로 간주해야합니다. ).
그리고 마술은 다소 유용하지만 제 생각에는 회계에 매우 편리한 메커니즘이 아닙니다. 누가 무엇을 압니까? 제 생각에는 주문이 고유하게 식별될 수 있다면(재개 및 부분적으로 닫힐 때) 마법의 의미가 완전히 사라질 것입니다.
의미는 분명하다.....
나는 몇 가지 주장을하려고 노력할 것입니다. 나는 끝에서 시작할 것입니다 ...
제 생각에는 객체에 대한 주문을 받으면 프로그래밍의 관점에서 현재 마술은 SL 또는 TP 수준과 같은이 객체의 본격적인 가변 속성입니다. 어쩌면 내가 틀릴 수도 있지만 MQL에서는 현재 가능한 모든 단계(다시 열고 부분적으로 닫을 때)에서 터미널에서 실행된 코드와 관련하여 순서를 고유하게 식별할 수 없으며 마법은 이 상황을 다음과 같이 보상합니다. 더 큰 범위. 마술은 시장에 얽매여서는 안 됩니다. 단지 범위가 다르고 의미 이외의 의미론적 부하가 없을 뿐입니다.
시장 상황을 비역사적이라고 생각하는 입장에서 님의 의견에 동의하지 않겠습니다만... 이건 제 개인적인 생각입니다. 수익성 있는 주문의 경우 결정을 내리기 위해 더 높은 시간 프레임을 살펴보거나 약간의 롤백을 두고 더 높은 시간 프레임에 주문 작업을 계속하거나 단순히 잠재 고객이 없기 때문에 종료하는 것이 합리적입니다.
나는 전략의 일관성과 결함에 대해 논의하지 않을 것입니다 - 전적으로 동의합니다 ...하지만 나는 이것에 대해 일하고 있습니다 :-)
서버와 단말 사이의 교환 언어와 프로토콜을 어떻게 변경해야 하는지 모르겠습니다... 현재로서는 매직 값의 할당이 이미 존재하며 주문할 때 서버에서 수락합니다. 교환 프로토콜 형식에 대한 정보는 없지만 전송을 통해 특정 데이터 구조의 패킷 전송에 이어 일관성 검증이 뒤따르는 것이라는 의혹이 있다. OrderModify 에 전달된 데이터 구조에 선택적 매개변수를 하나 더 추가하는 것은 어렵지 않다고 생각합니다. 나는 개발자들이 원자 교환 프로토콜의 길을 택하여 버저닝 지원이라는 어려운 과정에 스스로를 몰아넣었다는 것을 깊이 의심합니다.
글쎄, 일반적으로 나는 계획에 대해 물었습니다 :-) 아니요, 아니요.