내 생각에 엔진과 주고받는 각 스레드에는 일종의 스레드 태그, 일종의 매직 번호 및 테스터와 함께 작동하는 스레드 태그가 있어야 합니다(항상 고유함). 엔진은 현재 설정된 흐름과 Expert Advisors에 반응하고 표시기는 정보 흐름의 속성(Pseudomagnumber)에 반응합니다.
테스터에서 모든 것이 이제 잘 작동합니다. 다른 창에서 테스터의 어드바이저를 관리합니다. 트레이너 모드.
이제 EA와 엔진 간의 메시지는 특정 마법이나 EA 이름에 연결되지 않습니다. 즉, 엔진이 리소스에 정보를 쓰는 경우 통신용으로 구성된 모든 EA에서 해당 정보를 읽습니다. 통신 흐름을 분리하기 위해 각 Expert Advisor는 메시지 헤더에 특수 레이블을 정의해야 합니다. 또한 지침을 읽고 따르거나 무시합니다. 테스터의 Expert Advisors에 대한 별도의 레이블이 있어야 합니다.
그러나 여기서 우리는 통신을 구성하고 전환할 수 있는 엔진용 범용 GUI가 필요하게 되었습니다. 또한 고문에 대한 정보를 얻으십시오.
이는 고문의 개념이 바뀌어야 함을 의미합니다. 아니면 오히려 업그레이드하십시오.
여기에 걸림돌이 있습니다.
각 Expert Advisor에 대한 사용자 지정 GUI 또는 모든 Expert Advisor에 대한 공통 GUI가 있어야 합니다. 일반적인 경우 불변해야 합니다. 미리 사려 깊게. 모든 Expert Advisor(GUI가 없더라도)에는 엔진에 제공할 내부 레버리지가 있어야 합니다.
제어에 연결된 것처럼 표시됩니다. 그리고 그것은 일부 중 하나에 의해 특별히 통제됩니다. 그래서 어딘가에 큰 표시가있는 토글 스위치가 있습니다.
각 EA에는 매개변수 커널의 자체 사본이 있습니다. 일반 GUI에서 일시적으로 연결을 끊고 엔진의 다른 Expert Advisor에 연결할 수 있습니다. 이것이 한 전문가의 사본이라는 것이 중요합니다.
그러나 여기에는 나 자신이 아직 완전히 표현하지 못하는 어려움이 있습니다.
이론적으로 질문은 다음과 같습니다.
공통 GUI로 하나의 엔진을 만들고 이를 어드바이저의 사본에 연결할 수 있다면 왜 각 차트에 GUI가 있는 엔진을 넣습니까?
실제로는 기술적인 어려움이 있습니다.
EA의 복사본은 매개변수 코어의 복사본에 새 값을 쓸 수 있습니다. 복사본 중 하나가 엔진과 연결되어 있지 않으면 핵심 매개변수는 복사본 쪽에서만 변경됩니다. 즉, 다시 연결할 때 복사 매개변수의 전체 코어를 엔진으로 전송해야 하며 필요한 경우 모든 창의 모든 요소를 다시 그립니다. 원칙적으로는 가능합니다.
또는 매개변수 코어 자체를 다시 만들어 리소스로 만듭니다. 이 경우 엔진은 즉시 모든 변경 사항을 수신하고 요소만 다시 그립니다. 나쁜 생각은 아닙니다.
그러나 이것은 우리에게 무엇을 제공합니까?
아마도 우리는 프로세서 부하를 줄이고 스레드를 확보할 수 있습니다. 10쌍에서 실행되는 어드바이저 복사본이 10개 있고 GUI가 있는 각 엔진에 실행하는 경우 프로세서의 총 부하가 너무 클 수 있습니다. 결국 각 GUI는 요소를 다시 그려야 하며 이는 프로세서를 로드합니다. 그러나 사실, 우리는 하나의 복사본의 하나의 특정 GUI만 볼 수 있습니다. 나머지는 숨겨져 있습니다.
내 생각에 엔진과 주고받는 각 스레드에는 일종의 스레드 태그, 일종의 매직 번호 및 테스터와 함께 작동하는 스레드 태그가 있어야 합니다(항상 고유함). 엔진은 현재 설정된 흐름과 Expert Advisors에 반응하고 표시기는 정보 흐름의 속성(Pseudomagnumber)에 반응합니다.
테스터에서 모든 것이 이제 잘 작동합니다. 다른 창에서 테스터의 어드바이저를 관리합니다. 트레이너 모드.
이제 EA와 엔진 간의 메시지는 특정 마법이나 EA 이름에 연결되지 않습니다. 즉, 엔진이 리소스에 정보를 쓰는 경우 통신용으로 구성된 모든 EA에서 해당 정보를 읽습니다. 통신 흐름을 분리하기 위해 각 Expert Advisor는 메시지 헤더에 특수 레이블을 정의해야 합니다. 또한 지침을 읽고 따르거나 무시합니다. 테스터의 Expert Advisors에 대한 별도의 레이블이 있어야 합니다.
그러나 여기서 우리는 통신을 구성하고 전환할 수 있는 엔진용 범용 GUI가 필요하게 되었습니다. 또한 고문에 대한 정보를 얻으십시오.
이는 고문의 개념이 바뀌어야 함을 의미합니다. 아니면 오히려 업그레이드하십시오.
여기에 걸림돌이 있습니다.
각 Expert Advisor에 대한 사용자 지정 GUI 또는 모든 Expert Advisor에 대한 공통 GUI가 있어야 합니다. 일반적인 경우 불변해야 합니다. 미리 사려 깊게. 모든 Expert Advisor(GUI가 없더라도)에는 엔진에 제공할 내부 레버리지가 있어야 합니다.
생각해 볼 일...
그러나 여기서 우리는 통신을 구성하고 전환할 수 있는 엔진용 범용 GUI가 필요하게 되었습니다. 또한 고문에 대한 정보를 얻으십시오.
엔진은 단순히 관리를 관리하는 필요하고 충분한 영구적으로 설계되고 구성된 관리 부분과 고객의 프로젝트에 따라 구축된 가장 다양한 사용자 지정 부분 이 필요합니다 .
엔진은 관리를 관리하는 필요하고 충분한 영구적으로 설계되고 구성된 관리 부분과 고객의 프로젝트에 따라 구축된 가장 다양한 사용자 지정 부분만 있으면 됩니다.
이 관리 부분은 이해할 수 없습니다. 그녀는 무엇이어야합니까?
엔진이 한 명의 조언자와 함께 작동한다면 이것은 한 가지입니다. 그리고 여러 가지가 있으면 다릅니다.
개념 기반이 부족하지만 ...
이 관리 부분은 이해할 수 없습니다. 그녀는 무엇이어야합니까?
엔진이 한 명의 조언자와 함께 작동한다면 이것은 한 가지입니다. 그리고 여러 가지가 있으면 다릅니다.
개념 기반이 부족하지만 ...
이런 말을 해보자.
그리고 시작 설정의 어드바이저 또는 표시기에서 동일한 필드 "개체 1" 등
이런 말을 해보자.
그리고 시작 설정의 Expert Advisor 또는 표시기에서 동일한 필드 "개체 1" 등
흥미로운. 즉, 이 버튼이 연결을 전환합니까? 그러나 이 경우 모든 Expert Advisor는 서로 다른 쌍에서 시작된 동일한 Expert Advisor의 복사본이어야 합니다.
조언자가 다르다면?
이런 말을 해보자.
그리고 시작 설정의 어드바이저 또는 표시기에서 동일한 필드 "개체 1" 등
이것을 먼저 구현하겠습니다. 다른 쌍에 한 명의 고문과 함께. 그런 다음 다른 고문의 경우에 어떻게 되는지 알아낼 것입니다.
그건 그렇고, 여기에 생성자로 작업하는 좋은 데모가 있습니다. 다이내믹하고 말이 필요없고 음악에 맞춰. :)
비주얼 스튜디오 만들기
https://www.mql5.com/en/blogs/post/712102
그건 그렇고, 여기에 생성자로 작업하는 좋은 데모가 있습니다. 말이 필요 없는 다이내믹한 음악. :)
비주얼 스튜디오 만들기
원래의.
이런 말을 해보자.
그리고 시작 설정의 Expert Advisor 또는 표시기에서 동일한 필드 "개체 1" 등
제어에 연결된 것처럼 표시됩니다. 그리고 그것은 일부 중 하나에 의해 특별히 통제됩니다. 그래서 어딘가에 큰 표시가있는 토글 스위치가 있습니다.
제어에 연결된 것처럼 표시됩니다. 그리고 그것은 일부 중 하나에 의해 특별히 통제됩니다. 그래서 어딘가에 큰 표시가있는 토글 스위치가 있습니다.
각 EA에는 매개변수 커널의 자체 사본이 있습니다. 일반 GUI에서 일시적으로 연결을 끊고 엔진의 다른 Expert Advisor에 연결할 수 있습니다. 이것이 한 전문가의 사본이라는 것이 중요합니다.
그러나 여기에는 나 자신이 아직 완전히 표현하지 못하는 어려움이 있습니다.
이론적으로 질문은 다음과 같습니다.
공통 GUI로 하나의 엔진을 만들고 이를 어드바이저의 사본에 연결할 수 있다면 왜 각 차트에 GUI가 있는 엔진을 넣습니까?
실제로는 기술적인 어려움이 있습니다.
EA의 복사본은 매개변수 코어의 복사본에 새 값을 쓸 수 있습니다. 복사본 중 하나가 엔진과 연결되어 있지 않으면 핵심 매개변수는 복사본 쪽에서만 변경됩니다. 즉, 다시 연결할 때 복사 매개변수의 전체 코어를 엔진으로 전송해야 하며 필요한 경우 모든 창의 모든 요소를 다시 그립니다. 원칙적으로는 가능합니다.
또는 매개변수 코어 자체를 다시 만들어 리소스로 만듭니다. 이 경우 엔진은 즉시 모든 변경 사항을 수신하고 요소만 다시 그립니다. 나쁜 생각은 아닙니다.
그러나 이것은 우리에게 무엇을 제공합니까?
아마도 우리는 프로세서 부하를 줄이고 스레드를 확보할 수 있습니다. 10쌍에서 실행되는 어드바이저 복사본이 10개 있고 GUI가 있는 각 엔진에 실행하는 경우 프로세서의 총 부하가 너무 클 수 있습니다. 결국 각 GUI는 요소를 다시 그려야 하며 이는 프로세서를 로드합니다. 그러나 사실, 우리는 하나의 복사본의 하나의 특정 GUI만 볼 수 있습니다. 나머지는 숨겨져 있습니다.
따라서 이것이 아마도 올바른 방법일 것입니다. 공통 엔진을 만드십시오.