이제 MT NET-dll에 맞춰 제시간에 도착했습니다. MT용 C-sharp에서 GUI를 만드는 것은 더 이상 어렵지 않으며 기능이 향상되었습니다. 이후 에 따르면 모든 이벤트는 MT-틱으로 이동한 다음 버튼도 사용합니다. 글쎄, IMHO 분석을 고정하기 위해 Peter보다 DLL이 더 쉽습니다.
일반적으로 Peter의 엔진은 누구에게나 유용하다면 DLL이 없는 시장 판매자에게만 해당됩니다.
첫째, 당신은 교활하게 "어려움이 없다"고 말합니다. C#에서 GUI를 만드는 것은 쉽지만 MQL 애플리케이션에 연결하려면 ???
그러한 연결의 예를 보여주십시오. 적어도 소름 끼치는 목발입니다. DLL을 통해 모든 작업을 수행해야 합니다. 이벤트 보내기, 이벤트 받기...
상호 작용 인터페이스는 직접 만들어야 합니다. MT THROUGH DLL의 응용 프로그램과 함께 Sharp에서 GUI 관계를 개발하는 데 얼마나 많은 노력과 시간이 필요합니까?
내 결정의 단순성을 고려할 때 누가 이것을 할 것입니까? 이미 연결 인터페이스가 있습니다. 연결 문제 - 30분(여러 개의 창이 있는 경우). 모든 것이 매우 간단합니다. DLL이 없습니다.
권리.
애플리케이션의 GUI를 전달하는 엔진은 단순히 컨트롤의 메커니즘(버튼, 입력 필드 등...)을 구현합니다.
버튼, 체크박스, 텍스트 입력 및 기타 사용자 작업을 클릭하면 개발자의 애플리케이션으로 직접 전송됩니다.
애플리케이션은 데이터를 필드와 테이블에 전달할 수 있습니다.
모든 것은 간단한 연결 파일을 통해 이루어집니다.
글쎄, 그것은 다른 문제입니다.
이제 MT NET-dll에 맞춰 제시간에 도착했습니다. MT용 C-sharp에서 GUI를 만드는 것은 더 이상 어렵지 않으며 기능이 향상되었습니다. 이후 에 따르면 모든 이벤트는 MT-틱으로 이동한 다음 버튼도 사용합니다. 글쎄, IMHO 분석을 고정하기 위해 Peter보다 DLL이 더 쉽습니다.
일반적으로 Peter의 엔진은 누구에게나 유용하다면 DLL이 없는 시장 판매자에게만 해당됩니다.
첫째, 당신은 교활하게 "어려움이 없다"고 말합니다. C#에서 GUI를 만드는 것은 쉽지만 MQL 애플리케이션에 연결하려면 ???
그러한 연결의 예를 보여주십시오. 적어도 소름 끼치는 목발입니다. DLL을 통해 모든 작업을 수행해야 합니다. 이벤트 보내기, 이벤트 받기...
상호 작용 인터페이스는 직접 만들어야 합니다. MT THROUGH DLL의 응용 프로그램과 함께 Sharp에서 GUI 관계를 개발하는 데 얼마나 많은 노력과 시간이 필요합니까?
내 결정의 단순성을 고려할 때 누가 이것을 할 것입니까? 이미 연결 인터페이스가 있습니다. 연결 문제 - 30분(여러 개의 창이 있는 경우). 모든 것이 매우 간단합니다. DLL이 없습니다.
그래서 이것은 "죽어가는" 아이디어입니다.
첫째, 당신은 교활하게 "어려움이 없다"고 말합니다. C#에서 GUI를 만드는 것은 쉽지만 MQL 애플리케이션에 연결하려면 ???
그러한 연결의 예를 보여주십시오. 적어도 소름 끼치는 목발입니다. DLL을 통해 모든 작업을 수행해야 합니다. 이벤트 보내기, 이벤트 받기...
상호 작용 인터페이스는 직접 만들어야 합니다. MT THROUGH DLL의 응용 프로그램과 GUI 관계를 개발하려면 얼마나 많은 노력과 시간이 필요합니까?
내 결정의 단순성을 고려할 때 누가 이것을 할 것입니까? 이미 연결 인터페이스가 있습니다. 연결 문제 - 30분(여러 개의 창이 있는 경우). 모든 것이 매우 간단합니다. DLL이 없습니다.
그래서 이것은 "죽어가는" 아이디어입니다.
모두 같은. 합병증이 없습니다. 어떤 함수를 호출하는지 - 응용 프로그램 또는 DLL은 중요하지 않습니다. 함수를 호출 하는 데 어려움이 있습니까?
모두 같은. 합병증이 없습니다. 어떤 함수를 호출하는지 - 응용 프로그램 또는 DLL은 중요하지 않습니다. 함수 호출 의 어려움이 보이십니까?
아니요. 포인트는 매개변수 값이 동기화되어야 하는 메모리에 있습니다. 메모리는 파일에 있거나 DLL(또는 다른 위치)에 있는 응용 프로그램의 공유 메모리에 있어야 합니다.
그러나 이것이 중요한 것은 아닙니다.
주요 사항:
MQL 응용 프로그램과 GUI on SHARP의 상호 작용을 위한 인터페이스 개발은 표준화되어 있지 않습니다. 각 개발자는 Sharp에서 자신의 GUI에 연결하기 위한 인터페이스를 마련해야 합니다.
그리고 모든 것이 이미 나를 위해 작동한다면 무엇이 필요할까요?
아니요. 포인트는 매개변수 값이 동기화되어야 하는 메모리에 있습니다. 메모리는 파일에 있거나 DLL(또는 다른 위치)에 있는 응용 프로그램의 공유 메모리에 있어야 합니다.
그러나 이것이 중요한 것은 아닙니다.
주요 사항:
MQL 응용 프로그램과 GUI on SHARP의 상호 작용을 위한 인터페이스 개발은 표준화되어 있지 않습니다. 각 개발자는 Sharp에서 자신의 GUI에 연결하기 위한 인터페이스를 마련해야 합니다.
그리고 모든 것이 이미 나를 위해 작동한다면 무엇이 필요할까요?
당신은 상황을 극화하고 있습니다.)
당신은 상황을 극화하고 있습니다.)
한 방울도 아닙니다. 나는 상황을 알고 있다. C++로 작성된 DLL을 통해 MT와 Sharp의 응용 프로그램 간의 관계를 수행했습니다. 끔찍한 치질. Visual Studio와 MT를 동시에 작업해야 합니다. 그런 다음 응용 프로그램을 병렬로 실행합니다.
그러나 가장 중요한 것은 응용 프로그램 부분의 상호 작용을 위한 형식이 아무나 개발한 것이 아니라는 것 입니다. 그러므로 모든 사람은 스스로 괴로움을 당할 것입니다.
한 방울도 아닙니다. 나는 상황을 알고 있다. C++로 작성된 DLL을 통해 MT와 Sharp의 응용 프로그램 간의 관계를 수행했습니다. 끔찍한 치질. Visual Studio와 MT를 동시에 작업해야 합니다. 그런 다음 응용 프로그램을 병렬로 실행합니다.
그러나 가장 중요한 것은 아무도 응용 프로그램 부분의 상호 작용을 위한 형식을 개발하지 않았다는 것입니다. 그러므로 모든 사람은 스스로 괴로움을 당할 것입니다.
DLL은 표준 Windows 도구입니다. DLL과의 상호 작용은 DOS 시절부터 오랫동안 개발되어 널리 사용되었습니다. 전혀 문제가 없습니다.
DLL은 표준 Windows 도구입니다. DLL과의 상호 작용은 DOS 시절부터 오랫동안 개발되어 널리 사용되었습니다. 전혀 문제가 없습니다.
Sharp에서 DLL과의 상호 작용을 개발했습니다. 그리고 DLL을 통한 Sharp와 MKL 응용 프로그램의 상호 작용은 프로그래머의 개인적인 번거로움입니다.
공유 메모리를 구성하고 읽기 플래그를 기반으로 해당 기능을 호출해야 합니다.
따라서 DLL이나 파일에 있는 공유 메모리에 끝없이 접근해야 합니다. 결국 Sharp에서 DLL을 통해 MT로 콜백이 없습니다.
Sharp에서 DLL과의 상호 작용을 개발했습니다. 그리고 DLL을 통한 Sharp와 MKL 응용 프로그램의 상호 작용은 프로그래머의 개인적인 번거로움입니다.
공유 메모리를 구성하고 읽기 플래그를 기반으로 해당 기능을 호출해야 합니다.
따라서 DLL이나 파일에 있는 공유 메모리에 끝없이 접근해야 합니다. 결국 Sharp에서 DLL을 통해 MT로 콜백이 없습니다.
MT에도 콜백이 없습니다. 모든 것은 MT에서 미리 결정된 이벤트에 따라 수행되며, 한 번이면 끝입니다.
여전히 터미널 이벤트 를 DLL에 전달하고 MT 또는 DLL에서 처리하는 위치는 중요하지 않습니다.
MCL 응용 프로그램에서 Sharp의 메시지를 지속적으로 확인하는 데 비용이 많이 들지 않는다고 상상하더라도 상호 작용 형식을 개발하는 것은 매우 방대한 작업입니다.
이 작업에는 다음이 포함됩니다.
1. 공유 메모리의 조직을 발명합니다.
2. 3자 상호작용의 구현.
3. 3자 동시 테스트(Sharp, DLL, MT 애플리케이션).
매우 노동 집약적입니다.
제 경우에는 사용자가 파일을 가져와서 작성합니다. 그리고 연결이 작동합니다.