Peter, 아마도 속도가 아니라 작업의 의미 측면에서 엔진을 논리적으로 완성하면 그런 아이디어가 있습니다. 세 개의 창: 1 - 엔진, 2 - 데모 또는 실생활에 있는 고문, 3 - 고문의 전략을 위한 병렬 시뮬레이터로서 테스터에서 동일한 고문의 주기적으로 열리는 창입니다. 한 전문가 창에서 다른 어드바이저 창으로 엔진 창의 모니터링 및 제어 흐름을 전환하는 엔진의 기능. 엔진 창에서만 테스터 에서 EA를 제어 하도록 구성되어 있으므로 테스터에서 EA가 제어를 수행하고 있다는 명확한 표시가 있습니다. 간판이 크고 눈에 띕니다. 제어되는 대상을 혼동하지 않도록 하기 위함입니다.
Oleg Papkov : Peter, 아마도 속도가 아니라 작업의 의미 측면에서 엔진을 논리적으로 완성하면 그런 아이디어가 있습니다. 세 개의 창: 1 - 엔진, 2 - 데모 또는 실생활에 있는 고문, 3 - 고문의 전략을 위한 병렬 시뮬레이터로서 테스터에서 동일한 고문의 주기적으로 열리는 창입니다. 한 전문가 창에서 다른 전문가 창으로 엔진 창의 모니터링 및 제어 흐름을 전환하는 엔진의 기능. 엔진 창에서만 테스터에서 EA를 제어하도록 구성되어 있으므로 테스터에서 EA가 제어를 수행하고 있다는 명확한 표시가 있습니다. 간판이 크고 눈에 띕니다. 제어되는 대상을 혼동하지 않도록 하기 위함입니다.
아이디어가 흥미롭습니다. 솔직히 말하면, 전체적인 개념이 저를 위해 형성되는 중입니다. 당신의 아이디어는 가능성이 있습니다.
이제 많은 Expert Advisors 가 만들어졌으며 이를 모니터링하고 작업을 관리하는 엔진을 중심으로 Expert Advisors를 통합할 수 있습니다.
Oleg Papkov : Peter, 아마도 속도가 아니라 작업의 의미 측면에서 엔진을 논리적으로 완성하면 그런 아이디어가 있습니다. 세 개의 창: 1 - 엔진, 2 - 데모 또는 실생활에 있는 고문, 3 - 고문의 전략을 위한 병렬 시뮬레이터로서 테스터에서 동일한 고문의 주기적으로 열리는 창입니다. 한 전문가 창에서 다른 어드바이저 창으로 엔진 창의 모니터링 및 제어 흐름을 전환하는 엔진의 기능. 엔진 창에서만 테스터에서 EA를 제어하도록 구성되어 있으므로 테스터에서 EA가 제어를 수행하고 있다는 명확한 표시가 있습니다. 간판이 크고 눈에 띕니다. 제어되는 대상을 혼동하지 않도록 하기 위함입니다.
일반적으로 어드바이저의 모니터링 전환이 필요합니다. 이렇게 하려면 모든 쌍(심지어 테스터에서도)에서 원하는 수의 Expert Advisors를 수행할 새로운 상호 작용 시스템에 대해 생각하고 테스트해야 합니다. 그러나 페어링 파일은 이러한 Expert Advisor에 연결되어야 합니다. 즉, 어드바이저는 엔진과의 상호 작용을 위해 초기에 날카롭게 해야 합니다.
일반적으로 고문의 모니터링 전환이 필요합니다. 이렇게 하려면 모든 쌍(심지어 테스터에서도)에서 원하는 수의 Expert Advisors를 수행할 새로운 상호 작용 시스템에 대해 생각하고 테스트해야 합니다. 그러나 페어링 파일은 이러한 Expert Advisor에 연결되어야 합니다. 즉, 모든 Expert Advisor는 엔진과의 이러한 상호 작용을 위해 처음에 날카롭게 해야 합니다.
내 생각에 엔진과 주고받는 각 스레드에는 일종의 스레드 태그, 일종의 매직 번호 및 테스터와 함께 작동하는 스레드 태그가 있어야 합니다(항상 고유함). 엔진은 현재 설정된 흐름과 Expert Advisors에 반응하고 표시기는 정보 흐름의 속성(Pseudomagnumber)에 반응합니다.
테스터에서 모든 것이 이제 잘 작동합니다. 다른 창에서 테스터의 어드바이저를 관리합니다. 트레이너 모드.
알다시피, 나는 또한 그 "조수"라고 생각했지만 정확히는 조수였습니다.
죄송하지만 그것도 사실이 아닙니다.
당신이 이 구식의 매우 느린 MT4에 갇힌 것이 유감입니다. 전략적 실수!
MT4에 갇힌 사람은 나뿐만이 아닙니다. 하지만 그게 아닙니다. 내 프로그램을 더 강력하게 만들려면 더 약한 플랫폼이 필요합니다. 역설.
MT4에 갇힌 사람은 나뿐만이 아닙니다. 하지만 그게 아닙니다. 내 프로그램을 더 강력하게 만들려면 더 약한 플랫폼이 필요합니다. 역설.
이해가 안되요... 뭐, 당신의 코드는 크로스 플랫폼이 아니죠???
Peter, 그렇다면 이것은 명백한 전략적 실수입니다!
이해가 안되요... 뭐, 당신의 코드는 크로스 플랫폼이 아니죠???
Peter, 그렇다면 이것은 명백한 전략적 실수입니다!
MT5 테스터가 다르게 작동하기 때문에 절대적으로 크로스 플랫폼 코드를 만드는 것은 불가능합니다.
분명히 리소스를 사용하여 엔진과 통신하는 것은 불가능합니다. 아마도 MT 개체를 통한 통신이 작동할 것입니다.
그렇지 않으면 코드가 플랫폼 간입니다.
Peter, 아마도 속도가 아니라 작업의 의미 측면에서 엔진을 논리적으로 완성하면 그런 아이디어가 있습니다. 세 개의 창: 1 - 엔진, 2 - 데모 또는 실생활에 있는 고문, 3 - 고문의 전략을 위한 병렬 시뮬레이터로서 테스터에서 동일한 고문의 주기적으로 열리는 창입니다. 한 전문가 창에서 다른 전문가 창으로 엔진 창의 모니터링 및 제어 흐름을 전환하는 엔진의 기능. 엔진 창에서만 테스터에서 EA를 제어하도록 구성되어 있으므로 테스터에서 EA가 제어를 수행하고 있다는 명확한 표시가 있습니다. 간판이 크고 눈에 띕니다. 제어되는 대상을 혼동하지 않도록 하기 위함입니다.
아이디어가 흥미롭습니다. 솔직히 말하면, 전체적인 개념이 저를 위해 형성되는 중입니다. 당신의 아이디어는 가능성이 있습니다.
이제 많은 Expert Advisors 가 만들어졌으며 이를 모니터링하고 작업을 관리하는 엔진을 중심으로 Expert Advisors를 통합할 수 있습니다.
실제로 코드가 아닌 엔진을 통해 다중 통화를 구현합니다.
각 어드바이저는 자체 페어를 거래하고 엔진이 이를 제어하고 재구성합니다...
이 같은?
Peter, 아마도 속도가 아니라 작업의 의미 측면에서 엔진을 논리적으로 완성하면 그런 아이디어가 있습니다. 세 개의 창: 1 - 엔진, 2 - 데모 또는 실생활에 있는 고문, 3 - 고문의 전략을 위한 병렬 시뮬레이터로서 테스터에서 동일한 고문의 주기적으로 열리는 창입니다. 한 전문가 창에서 다른 어드바이저 창으로 엔진 창의 모니터링 및 제어 흐름을 전환하는 엔진의 기능. 엔진 창에서만 테스터에서 EA를 제어하도록 구성되어 있으므로 테스터에서 EA가 제어를 수행하고 있다는 명확한 표시가 있습니다. 간판이 크고 눈에 띕니다. 제어되는 대상을 혼동하지 않도록 하기 위함입니다.
일반적으로 어드바이저의 모니터링 전환이 필요합니다. 이렇게 하려면 모든 쌍(심지어 테스터에서도)에서 원하는 수의 Expert Advisors를 수행할 새로운 상호 작용 시스템에 대해 생각하고 테스트해야 합니다. 그러나 페어링 파일은 이러한 Expert Advisor에 연결되어야 합니다. 즉, 어드바이저는 엔진과의 상호 작용을 위해 초기에 날카롭게 해야 합니다.
일반적으로 고문의 모니터링 전환이 필요합니다. 이렇게 하려면 모든 쌍(심지어 테스터에서도)에서 원하는 수의 Expert Advisors를 수행할 새로운 상호 작용 시스템에 대해 생각하고 테스트해야 합니다. 그러나 페어링 파일은 이러한 Expert Advisor에 연결되어야 합니다. 즉, 모든 Expert Advisor는 엔진과의 이러한 상호 작용을 위해 처음에 날카롭게 해야 합니다.
내 생각에 엔진과 주고받는 각 스레드에는 일종의 스레드 태그, 일종의 매직 번호 및 테스터와 함께 작동하는 스레드 태그가 있어야 합니다(항상 고유함). 엔진은 현재 설정된 흐름과 Expert Advisors에 반응하고 표시기는 정보 흐름의 속성(Pseudomagnumber)에 반응합니다.
테스터에서 모든 것이 이제 잘 작동합니다. 다른 창에서 테스터의 어드바이저를 관리합니다. 트레이너 모드.