아마도 우리는 프로세서 부하를 줄이고 스레드를 확보할 수 있습니다. 10쌍에서 실행되는 어드바이저 복사본이 10개 있고 GUI가 있는 각 엔진에 실행하는 경우 프로세서의 총 부하가 너무 클 수 있습니다. 결국 각 GUI는 요소를 다시 그려야 하며 이는 프로세서를 로드합니다. 그러나 사실, 우리는 하나의 복사본의 하나의 특정 GUI만 볼 수 있습니다. 나머지는 숨겨져 있습니다.
각 EA에는 매개변수 커널의 자체 사본이 있습니다. 일반 GUI에서 일시적으로 연결을 끊고 엔진의 다른 Expert Advisor에 연결할 수 있습니다. 이것이 한 전문가의 사본이라는 것이 중요합니다.
그러나 여기에는 나 자신이 아직 완전히 표현하지 못하는 어려움이 있습니다.
이론적으로 질문은 다음과 같습니다.
공통 GUI로 하나의 엔진을 만들고 이를 어드바이저의 사본에 연결할 수 있다면 왜 각 차트에 GUI가 있는 엔진을 넣습니까?
실제로는 기술적인 어려움이 있습니다.
EA의 복사본은 매개변수 코어의 복사본에 새 값을 쓸 수 있습니다. 복사본 중 하나가 엔진과 연결되어 있지 않으면 핵심 매개변수는 복사본 쪽에서만 변경됩니다. 즉, 다시 연결할 때 복사 매개변수의 전체 코어를 엔진으로 전송해야 하며 필요한 경우 모든 창의 모든 요소를 다시 그립니다. 원칙적으로는 가능합니다.
또는 매개변수 코어 자체를 다시 만들어 리소스로 만듭니다. 이 경우 엔진은 즉시 모든 변경 사항을 수신하고 요소만 다시 그립니다. 나쁜 생각은 아닙니다.
그러나 이것이 우리에게 무엇을 주는가?
아마도 우리는 프로세서 부하를 줄이고 스레드를 확보할 수 있습니다. 10쌍에서 실행되는 어드바이저 복사본이 10개 있고 GUI가 있는 각 엔진에 실행하는 경우 프로세서의 총 부하가 너무 클 수 있습니다. 결국 각 GUI는 요소를 다시 그려야 하며 이는 프로세서를 로드합니다. 그러나 사실, 우리는 하나의 복사본의 하나의 특정 GUI만 볼 수 있습니다. 나머지는 숨겨져 있습니다.
따라서 이것이 아마도 올바른 방법일 것입니다. 공통 엔진을 만드십시오.
고문의 사본을 통해 자주 엔진에 자신의 주소를 보고할 수 있습니다. 짧은 줄. 엔진은 현재 주소와 동일한 주소를 가진 사본에 반응하고 "대화"합니다. 그리고 표준 교환이 있을 것입니다. 엔진에서 주소가 변경되면 일치하는 주소를 노출하는 사본과 "교환"을 시작합니다. "ether"의 표준 교환에 조언자 또는 짧은 주소의 표시자가 설정을 추가했을 뿐입니다. 여러 바이트. 그리고 사용자가 엔진의 GUI에서 "Reconfigure" 버튼을 누르면 "엔진이 주소를 수신 대기"하는 기능이 시작됩니다. 아마도 이와 같을 것입니다.
고문의 사본을 통해 자주 엔진에 자신의 주소를 보고할 수 있습니다. 짧은 줄. 엔진은 현재 주소와 동일한 주소를 가진 사본에 반응하고 "대화"합니다. 그리고 표준 교환이 있을 것입니다. 엔진에서 주소가 변경되면 일치하는 주소를 노출하는 사본과 "교환"을 시작합니다. "ether"의 표준 교환에 조언자 또는 짧은 주소의 표시자가 설정을 추가했을 뿐입니다. 여러 바이트. 그리고 사용자가 엔진의 GUI에서 "Reconfigure" 버튼을 누르면 "엔진이 주소를 수신 대기"하는 기능이 시작됩니다. 아마도 이와 같을 것입니다.
요점을 올바르게 보고 있습니다. 세부 사항에 대해 확실하지 않습니다.
"통신" 자체를 전환하는 것은 문제가 되지 않습니다. 단, 전환 시 전체 GUI를 다시 초기화해야 합니다. 실제로, 다른 사본의 창과 요소에서 다른 값입니다. 즉, 거의 모든 것을 다시 그려야 합니다.
각 복사본의 매개변수 값은 Parameter Core에 저장됩니다. 이것은 배열입니다. 그리고 엔진과 복사본이 분리되어 있는 동안에는 EA의 Parameter Core 복사본에서만 값의 변경이 발생합니다. 엔진이 연결되자마자 이 코어에서 모든 것을 엔진으로 전송해야 합니다. 엔진의 Parameter Core 사본과 연결된 Expert Advisor를 동기화합니다. 이는 많은 정보(Parameter Kernel)를 전송하고 창을 다시 그려야 함을 의미합니다. 그 후 연결된 전문가를 규제하는 것이 가능하고 다른 전문가는 독립적인 작동 모드로 전환됩니다. 그러면 그들과 연결이 이루어지고 같은 일이 일어날 것입니다.
그리고 만약 그렇다면. 각각의 빈도(OnTimer)가 있는 Expert Advisors는 자체 코드 문자열을 엔진에 보냅니다. 모든 코드 문자열은 다릅니다. 엔진은 내부적으로 들어오는 라인을 분석하고 하나를 "학습"합니다. 예를 들어 Expert Advisor 3번을 예로 들 수 있습니다. 이 Expert Advisor에 대한 응답으로 메인 전송을 시작하라는 "신호"를 보냅니다. 엔진은 이 Expert Advisor와 함께 작업을 시작했습니다. 사람이 전환 버튼을 누르면 엔진이 허용된 Expert Advisors를 분석하고 숫자로 인덱싱됩니다. 현재 Expert Advisor에 주소 설정 상태로 전환하도록 지시하여 스트리밍에서 끄듯이 인덱스가 있는 코드 라인을 1 더 선택하고 동일한 코드 라인이 Expert Advisor에서 도착하기를 기다립니다. 주소가 일치하면 이 EA에 신호를 보내 주소 설정을 완료하고 교환을 시작합니다. 주소 설정 모드에 있지 않은 유일한 Expert Advisor와 일련의 사본이 교환을 받게 됩니다. 요컨대, 같은 것.
엔진이 일부 주소를 수신한 경우 주소 획득을 금지하는 시간 초과를 만듭니다. 주소가 겹치지 않도록.
그리고 그렇다면. 각각의 빈도(OnTimer)가 있는 Expert Advisors는 자체 코드 문자열을 엔진에 보냅니다. 모든 코드 문자열은 다릅니다. 엔진은 내부적으로 들어오는 라인을 분석하고 하나를 "학습"합니다. 예를 들어 Expert Advisor 3번을 예로 들 수 있습니다. 이 Expert Advisor에 대한 응답으로 메인 전송을 시작하라는 "신호"를 보냅니다. 엔진은 이 Expert Advisor와 함께 작업을 시작했습니다. 사람이 전환 버튼을 누르면 엔진이 허용된 Expert Advisors를 분석하고 숫자로 인덱싱됩니다. 현재 Expert Advisor에 주소 설정 상태로 전환하도록 지시하여 스트리밍에서 끄듯이 인덱스가 있는 코드 라인을 1 더 선택하고 동일한 코드 라인이 Expert Advisor에서 도착하기를 기다립니다. 주소가 일치하면 이 EA에 신호를 보내 주소 설정을 완료하고 교환을 시작합니다. 주소 설정 모드에 있지 않은 유일한 Expert Advisor와 일련의 사본이 교환을 받게 됩니다. 요컨대, 같은 것.
엔진이 일부 주소를 수신한 경우 주소 획득을 금지하는 시간 초과를 만듭니다. 주소가 겹치지 않도록.
이것은 올바른 접근 방식이 아닙니다. 설명하겠습니다:
어드바이저의 각 복사본은 자체 별도 리소스의 엔진에 메시지 쓰기를 중단하지 않습니다. 동시에 Expert Advisor의 각 사본은 Parameter Core 사본의 요소 값을 초기화합니다. 즉, 엔진에서 분리된 상태에서도 어드바이저의 모든 사본에서 모든 것이 정상적으로 발생해야 합니다.
엔진이 Expert Advisors 사본 간에 연결을 전환할 때 매개변수 코어를 연결된 Expert Advisor의 코어와 동기화해야 합니다. 그런 다음 실제 정보를 표시하도록 창의 요소를 다시 그립니다.
선택한 고문과의 의사 소통은 여기에서 모든 것이 간단합니다. 엔진에서 메시지를 수신하기 위한 리소스(엔진용 메시지 리소스도 포함), 각 Adviser는 고유한 리소스를 갖습니다. 즉, 엔진은 단순히 메시지를 다른 리소스에 쓰고 다른 리소스에서 메시지를 읽습니다. 연결된 어드바이저에 속한 리소스입니다.
Реter Konow :
...
나쁜 생각은 아닙니다.
그러나 이것은 우리에게 무엇을 제공합니까?
아마도 우리는 프로세서 부하를 줄이고 스레드를 확보할 수 있습니다. 10쌍에서 실행되는 어드바이저 복사본이 10개 있고 GUI가 있는 각 엔진에 실행하는 경우 프로세서의 총 부하가 너무 클 수 있습니다. 결국 각 GUI는 요소를 다시 그려야 하며 이는 프로세서를 로드합니다. 그러나 사실, 우리는 하나의 복사본의 하나의 특정 GUI만 볼 수 있습니다. 나머지는 숨겨져 있습니다.
따라서 이것이 아마도 올바른 방법일 것입니다. 공통 엔진을 만드십시오.
MT5에서는 차트를 분리할 수 있습니다. 그런 다음 새로운 개념을 제시해야 합니다.
각 EA에는 매개변수 커널의 자체 사본이 있습니다. 일반 GUI에서 일시적으로 연결을 끊고 엔진의 다른 Expert Advisor에 연결할 수 있습니다. 이것이 한 전문가의 사본이라는 것이 중요합니다.
그러나 여기에는 나 자신이 아직 완전히 표현하지 못하는 어려움이 있습니다.
이론적으로 질문은 다음과 같습니다.
공통 GUI로 하나의 엔진을 만들고 이를 어드바이저의 사본에 연결할 수 있다면 왜 각 차트에 GUI가 있는 엔진을 넣습니까?
실제로는 기술적인 어려움이 있습니다.
EA의 복사본은 매개변수 코어의 복사본에 새 값을 쓸 수 있습니다. 복사본 중 하나가 엔진과 연결되어 있지 않으면 핵심 매개변수는 복사본 쪽에서만 변경됩니다. 즉, 다시 연결할 때 복사 매개변수의 전체 코어를 엔진으로 전송해야 하며 필요한 경우 모든 창의 모든 요소를 다시 그립니다. 원칙적으로는 가능합니다.
또는 매개변수 코어 자체를 다시 만들어 리소스로 만듭니다. 이 경우 엔진은 즉시 모든 변경 사항을 수신하고 요소만 다시 그립니다. 나쁜 생각은 아닙니다.
그러나 이것이 우리에게 무엇을 주는가?
아마도 우리는 프로세서 부하를 줄이고 스레드를 확보할 수 있습니다. 10쌍에서 실행되는 어드바이저 복사본이 10개 있고 GUI가 있는 각 엔진에 실행하는 경우 프로세서의 총 부하가 너무 클 수 있습니다. 결국 각 GUI는 요소를 다시 그려야 하며 이는 프로세서를 로드합니다. 그러나 사실, 우리는 하나의 복사본의 하나의 특정 GUI만 볼 수 있습니다. 나머지는 숨겨져 있습니다.
따라서 이것이 아마도 올바른 방법일 것입니다. 공통 엔진을 만드십시오.
고문의 사본을 통해 자주 엔진에 자신의 주소를 보고할 수 있습니다. 짧은 줄. 엔진은 현재 주소와 동일한 주소를 가진 사본에 반응하고 "대화"합니다. 그리고 표준 교환이 있을 것입니다. 엔진에서 주소가 변경되면 일치하는 주소를 노출하는 사본과 "교환"을 시작합니다. "ether"의 표준 교환에 조언자 또는 짧은 주소의 표시자가 설정을 추가했을 뿐입니다. 여러 바이트. 그리고 사용자가 엔진의 GUI에서 "Reconfigure" 버튼을 누르면 "엔진이 주소를 수신 대기"하는 기능이 시작됩니다. 아마도 이와 같을 것입니다.
MT5에서는 차트를 분리할 수 있습니다. 그런 다음 새로운 개념을 제시해야 합니다.
난 그냥 몰라. 차트가 순수하게 "영토적으로" 분리되어 메인 터미널 창의 좌표에서 자유로워지는가? 그리고 단말과의 교류의 흐름에서, 어떻게 완전히 연결되었고, 어떻게 될까요?
난 그냥 몰라. 차트가 순수하게 "영토적으로" 분리되어 메인 터미널 창의 좌표에서 자유로워지는가? 그리고 단말과의 교류의 흐름에서, 어떻게 완전히 연결되었고, 어떻게 될까요?
그래프는 분리되지만 본질은 바뀌지 않습니다. 헛되이 그들은 악몽을 꾸었습니다.) 고문의 각 사본에 대해 GUI 사본을 생성하는 것은 이치에 맞지 않습니다. 어쨌든, 나는 그것을 보지 않는다. 그러나 복사 차트 간에 하나의 GUI를 이동하는 것이 좋습니다.
엔진 과 기본 GUI 가 위치 할 어드바이저 사본의 제어 센터에 대한 일정이 있으면 편리합니다.
어드바이저의 GUI는 어드바이저가 다른 도구에 많은 사본을 설치하게 될 것이라는 예상을 가지고 만들어질 필요가 있습니다.
추신. 차트는 같은 창에 남아 있으며 창 자체만 터미널에서 "제거"할 수 있습니다.
고문의 사본을 통해 자주 엔진에 자신의 주소를 보고할 수 있습니다. 짧은 줄. 엔진은 현재 주소와 동일한 주소를 가진 사본에 반응하고 "대화"합니다. 그리고 표준 교환이 있을 것입니다. 엔진에서 주소가 변경되면 일치하는 주소를 노출하는 사본과 "교환"을 시작합니다. "ether"의 표준 교환에 조언자 또는 짧은 주소의 표시자가 설정을 추가했을 뿐입니다. 여러 바이트. 그리고 사용자가 엔진의 GUI에서 "Reconfigure" 버튼을 누르면 "엔진이 주소를 수신 대기"하는 기능이 시작됩니다. 아마도 이와 같을 것입니다.
요점을 올바르게 보고 있습니다. 세부 사항에 대해 확실하지 않습니다.
"통신" 자체를 전환하는 것은 문제가 되지 않습니다. 단, 전환 시 전체 GUI를 다시 초기화해야 합니다. 실제로, 다른 사본의 창과 요소에서 다른 값입니다. 즉, 거의 모든 것을 다시 그려야 합니다.
각 복사본의 매개변수 값은 Parameter Core에 저장됩니다. 이것은 배열입니다. 그리고 엔진과 복사본이 분리되어 있는 동안에는 EA의 Parameter Core 복사본에서만 값의 변경이 발생합니다. 엔진이 연결되자마자 이 코어에서 모든 것을 엔진으로 전송해야 합니다. 엔진의 Parameter Core 사본과 연결된 Expert Advisor를 동기화합니다. 이는 많은 정보(Parameter Kernel)를 전송하고 창을 다시 그려야 함을 의미합니다. 그 후 연결된 전문가를 규제하는 것이 가능하고 다른 전문가는 독립적인 작동 모드로 전환됩니다. 그러면 그들과 연결이 이루어지고 같은 일이 일어날 것입니다.
다소 이렇습니다. 그러나 많은 기술적 뉘앙스가 있습니다.
베드로. Nms의 기간 동안 어드바이저는 엔진에서 무언가를 수신한 후 준비된 무언가를 엔진으로 전송합니다. 그 후, EA는 틱이 도착하거나 리폴 교환의 새로운 부분을 기다립니다. 바르게?
거의 맞습니다. 통신 및 틱 대기 또는 기타 이벤트는 비동기식으로 발생합니다.
그래프는 분리되지만 본질은 바뀌지 않습니다. 헛된 악몽 .)
...
추신. 차트는 같은 창에 남아 있으며 창 자체만 터미널에서 "제거"할 수 있습니다 .
그리고 당신의 개념에 따르면 한 번에 하나의 현재 차트만 볼 수 있으며 업데이트할 수만 있고 손상될 수 있습니다. 분리된 만큼 많은 차트가 표시됩니다.
물론 악몽은 아니지만 배짱도 아닙니다. 보이는 차트 중 하나만 "살아날" 것이고 나머지는?
이게 정상이라고 생각하세요? 글쎄, 그렇다면 다시 한 번 버그 해결의 경솔함을 확신합니다. 존재하는 경우 수정하지 말고 숨기십시오.
거의 맞습니다. 통신 및 틱 대기 또는 기타 이벤트는 비동기식으로 발생합니다.
그리고 만약 그렇다면. 각각의 빈도(OnTimer)가 있는 Expert Advisors는 자체 코드 문자열을 엔진에 보냅니다. 모든 코드 문자열은 다릅니다. 엔진은 내부적으로 들어오는 라인을 분석하고 하나를 "학습"합니다. 예를 들어 Expert Advisor 3번을 예로 들 수 있습니다. 이 Expert Advisor에 대한 응답으로 메인 전송을 시작하라는 "신호"를 보냅니다. 엔진은 이 Expert Advisor와 함께 작업을 시작했습니다.
사람이 전환 버튼을 누르면 엔진이 허용된 Expert Advisors를 분석하고 숫자로 인덱싱됩니다. 현재 Expert Advisor에 주소 설정 상태로 전환하도록 지시하여 스트리밍에서 끄듯이 인덱스가 있는 코드 라인을 1 더 선택하고 동일한 코드 라인이 Expert Advisor에서 도착하기를 기다립니다. 주소가 일치하면 이 EA에 신호를 보내 주소 설정을 완료하고 교환을 시작합니다. 주소 설정 모드에 있지 않은 유일한 Expert Advisor와 일련의 사본이 교환을 받게 됩니다. 요컨대, 같은 것.
엔진이 일부 주소를 수신한 경우 주소 획득을 금지하는 시간 초과를 만듭니다. 주소가 겹치지 않도록.
그리고 그렇다면. 각각의 빈도(OnTimer)가 있는 Expert Advisors는 자체 코드 문자열을 엔진에 보냅니다. 모든 코드 문자열은 다릅니다. 엔진은 내부적으로 들어오는 라인을 분석하고 하나를 "학습"합니다. 예를 들어 Expert Advisor 3번을 예로 들 수 있습니다. 이 Expert Advisor에 대한 응답으로 메인 전송을 시작하라는 "신호"를 보냅니다. 엔진은 이 Expert Advisor와 함께 작업을 시작했습니다.
사람이 전환 버튼을 누르면 엔진이 허용된 Expert Advisors를 분석하고 숫자로 인덱싱됩니다. 현재 Expert Advisor에 주소 설정 상태로 전환하도록 지시하여 스트리밍에서 끄듯이 인덱스가 있는 코드 라인을 1 더 선택하고 동일한 코드 라인이 Expert Advisor에서 도착하기를 기다립니다. 주소가 일치하면 이 EA에 신호를 보내 주소 설정을 완료하고 교환을 시작합니다. 주소 설정 모드에 있지 않은 유일한 Expert Advisor와 일련의 사본이 교환을 받게 됩니다. 요컨대, 같은 것.
엔진이 일부 주소를 수신한 경우 주소 획득을 금지하는 시간 초과를 만듭니다. 주소가 겹치지 않도록.
이것은 올바른 접근 방식이 아닙니다. 설명하겠습니다:
어드바이저의 각 복사본은 자체 별도 리소스의 엔진에 메시지 쓰기를 중단하지 않습니다. 동시에 Expert Advisor의 각 사본은 Parameter Core 사본의 요소 값을 초기화합니다. 즉, 엔진에서 분리된 상태에서도 어드바이저의 모든 사본에서 모든 것이 정상적으로 발생해야 합니다.
엔진이 Expert Advisors 사본 간에 연결을 전환할 때 매개변수 코어를 연결된 Expert Advisor의 코어와 동기화해야 합니다. 그런 다음 실제 정보를 표시하도록 창의 요소를 다시 그립니다.
선택한 고문과의 의사 소통은 여기에서 모든 것이 간단합니다. 엔진에서 메시지를 수신하기 위한 리소스(엔진용 메시지 리소스도 포함), 각 Adviser는 고유한 리소스를 갖습니다. 즉, 엔진은 단순히 메시지를 다른 리소스에 쓰고 다른 리소스에서 메시지를 읽습니다. 연결된 어드바이저에 속한 리소스입니다.