어떤 식 으로든 직접 전화로 보답합니다. 매개변수를 사용하여 OnExternal 유형의 메서드를 추가할 수 있지만 전송 채널에 대해 생각해야 합니다.
그것은 수:
- 매개변수가 있는 콜백, dll에 등록됨
- 뮤텍스를 트리거로 명명
- PostMessage용 Windows 메시지
나는 그것이 완벽할 것이라고 확신한다! 여기서 우리는 무엇인가를 MT로 옮기는 것에 대해 이야기하는 것이 아닙니다. 데이터 전송 자체는 다른 방법으로 수행할 수 있습니다. 어떤 작업을 수행해야 함을 MT에 알리는 것이 중요합니다. 모든 것이 여러분이 개발한 GUI 라이브러리와 완전히 동일합니다. 모든 콜백은 이벤트를 통해 실행됩니다.
그건 그렇고, 이 라이브러리에 대해: 당신은 그것을 확장하고 그것을 캔버스로 완전히 번역할 계획입니까? 즉, 최종 "제품"은 차트 개체 집합이 아니라 하나의 전체 그림이어야 합니다.
물론 dll을 살펴보는 맥락에서 저는 dll을 MT에 리소스로 포함할 수 있기를 원합니다. 따라서 전문가나 지표와 함께 "끌어다 놓을" 필요가 없습니다.
간단한 형식은 C++ 및 기타 언어에서 쉽게 수행할 수 있습니다. 페어링 문제와 리소스 손실이 없습니다.
예, MQL5에서는 기본 인터페이스를 만드는 것이 절대적으로 쉽습니다.
글쎄, 질문은 실제로 GUI에서 그렇게 많지 않습니다. MT의 인터페이스 수단을 간단하게 만들 수 있다는 것. 물론 이것은 약간 혼란스럽고 기능을 확장하기 위해 고유한 처리 클래스를 만드는 데 필요한 것이지만 모든 것을 해결할 수 있습니다. 인터넷 작업을 위한 일부 알고리즘을 구현할 수 없기 때문에 net에 연락했습니다. C++에서는 MT는 물론이고 모국어에서도 매우 어렵고 불안정합니다. 글쎄, 나는 net과 연락을 취했기 때문에 MT와 달리 모든 것이 준비되어 있기 때문에 GUI도 사용했습니다. 모든 언어, 모든 언어로 응용 프로그램을 개발하는 공개 문제 중 이러한 문제는 특히 net과 관련이 없기 때문에: 1. 피드백, 2. GUI를 차트에 바인딩(https://www.mql5.com/ru/forum /103764 ) 주제 중 하나입니다.
우리는 모두 개발 환경의 장점에 대해 논쟁할 수 있습니다. 무엇을 위해? 우리는 어떤 개발 시스템도 특정 작업을 해결하기 때문에 자급자족할 수 없다는 것을 잘 알고 있습니다. 그리고 기능을 확장하기 위해 다른 언어나 환경에서 개발된 다른 플러그인이 사용됩니다. 편리한 상호 작용을 제공하기만 하면 됩니다. 우리는 멀리 가지 않을 것입니다. 가져오기를 통해 사용하는 동일한 Windows 라이브러리 ... 도움을 받아 누락된 기능을 구현합니다. 그리고 결국 이것이 순수하게 mql을 통해 구현되었다고 말할 수는 없습니다. ))) 원하는 목표를 달성하고 권한을 부여하기 위해 사용하는 외부 애플리케이션의 차이점은 무엇입니까? 자체 작성 dll이 Windows dll보다 나쁜 이유는 무엇입니까?
예를 들어 다음 기사가 있습니다. https://www.mql5.com/ru/articles/364
그러나 결국 우리는 dll을 완전히 제거하는 것에 대해 이야기하는 것이 아닙니다. MT에는 엄격하게 자체 작업이 있기 때문에 결코 일어나지 않을 것입니다. 이 기사에서는 무엇을 말하든 시스템 라이브러리가 존재합니다. 네, 자체 제작한 라이브러리와 달리 이 라이브러리는 전문가나 지표를 가지고 다닐 필요가 없습니다...
글쎄, 당신이 도구의 리소스에 dll을 컴파일 하는 기능을 추가하는 것을 방해하는 것은 무엇입니까?
예, 시장에서 dll을 사용할 수 없기 때문에 이것을 시장에 내놓을 수는 없지만 자체 개발을 위해서는 훨씬 더 편리할 것입니다.
우리는 모두 개발 환경의 장점에 대해 논쟁할 수 있습니다. 무엇을 위해? 우리는 어떤 개발 시스템도 특정 작업을 해결하기 때문에 자급자족할 수 없다는 것을 잘 알고 있습니다. 그리고 기능을 확장하기 위해 다른 언어나 환경에서 개발된 다른 플러그인이 사용됩니다. 편리한 상호 작용을 제공하기만 하면 됩니다. 우리는 멀리 가지 않을 것입니다. 가져오기를 통해 사용하는 동일한 Windows 라이브러리 ... 도움을 받아 누락된 기능을 구현합니다. 그리고 결국 이것이 순수하게 mql을 통해 구현되었다고 말할 수는 없습니다. ))) 원하는 목표를 달성하고 권한을 부여하기 위해 사용하는 외부 애플리케이션의 차이점은 무엇입니까? 자체 작성 dll이 Windows dll보다 나쁜 이유는 무엇입니까?
예를 들어 다음 기사가 있습니다. https://www.mql5.com/ru/articles/364
그러나 결국 우리는 dll을 완전히 제거하는 것에 대해 이야기하는 것이 아닙니다. MT에는 엄격하게 자체 작업이 있기 때문에 결코 일어나지 않을 것입니다. 이 기사에서는 무엇을 말하든 시스템 라이브러리가 존재합니다. 네, 자체 제작한 라이브러리와 달리 이 라이브러리는 전문가나 지표를 가지고 다닐 필요가 없습니다...
글쎄, 당신이 도구의 리소스에 dll을 컴파일 하는 기능을 추가하는 것을 방해하는 것은 무엇입니까?
예, 시장에서 dll을 사용할 수 없기 때문에 이것을 시장에 내놓을 수는 없지만 자체 개발을 위해서는 훨씬 더 편리할 것입니다.
Yuriy Asaulenko : 그런 생각과 글이 벌써 10년이 되었네요.. 그리고 아직도 진행중인 일들...
Renat는 일반적으로 생태계에 대해 이야기하고 우리는 허용하지 않습니다 ...
생태계에 대해 이야기하고 있다면 MT에서 수입품 사용을 중단하면 됩니다. 하지만 그들은 그렇게 하지 않습니다. 결국, 그들이 라이브러리 가져오기를 사용하기로 결정한 것은 아닙니다. 한동안 MT는 웹 요청을 처리할 수 없었고 파일 작업에 제한이 있었습니다. 이 모든 것이 라이브러리를 가져와서 확장되었습니다. 모든 시스템이 이런 식으로 작동하는 것은 당연하지만 지금도 MQL 도구를 사용하면 샌드박스에 있는 파일로만 작업할 수 있습니다. 아무도 이 접근 방식에 이의를 제기하지 않는 것 같습니다. 이것은 개발자의 정책이며 모두가 이를 이해하고 지원합니다. 그리고 샌드박스를 벗어나거나 레지스트리에 액세스하여 데이터를 저장하거나 데이터베이스 또는 매핑을 사용해야 하는 경우 .. 라이브러리 플러그인을 사용하십시오. 그래서 그렇지? 모든 것이 매우 논리적입니다. 이 도구에 대한 데이터베이스도 필요 없고 다른 것도 필요하지 않습니다.이 모든 것은 개발자에게만 필요하므로 MQL 언어를 사용할 수 있으므로 모든 기능의 도구를 구현할 수 있습니다. 그리고 개발 환경이 있기 때문에 MT는 더 이상 그 자체가 아닙니다. )) 당신은 단지 ... 개발해야합니다))))
µl, 파이프, 파일 또는 웹 요청에서 단방향 폴링.
나는 그것이 완벽할 것이라고 확신한다! 여기서 우리는 무엇인가를 MT로 옮기는 것에 대해 이야기하는 것이 아닙니다. 데이터 전송 자체는 다른 방법으로 수행할 수 있습니다. 어떤 작업을 수행해야 함을 MT에 알리는 것이 중요합니다. 모든 것이 여러분이 개발한 GUI 라이브러리와 완전히 동일합니다. 모든 콜백은 이벤트를 통해 실행됩니다.
그건 그렇고, 이 라이브러리에 대해: 당신은 그것을 확장하고 그것을 캔버스로 완전히 번역할 계획입니까? 즉, 최종 "제품"은 차트 개체 집합이 아니라 하나의 전체 그림이어야 합니다.
물론 dll을 살펴보는 맥락에서 저는 dll을 MT에 리소스로 포함할 수 있기를 원합니다. 따라서 전문가나 지표와 함께 "끌어다 놓을" 필요가 없습니다.
그리고 왜 gui를 위해 dotnet에서 멈췄습니까?
글쎄, 질문은 실제로 GUI에서 그렇게 많지 않습니다. MT의 인터페이스 수단을 간단하게 만들 수 있다는 것. 물론 이것은 약간 혼란스럽고 기능을 확장하기 위해 고유한 처리 클래스를 만드는 데 필요한 것이지만 모든 것을 해결할 수 있습니다. 인터넷 작업을 위한 일부 알고리즘을 구현할 수 없기 때문에 net에 연락했습니다. C++에서는 MT는 물론이고 모국어에서도 매우 어렵고 불안정합니다. 글쎄, 나는 net과 연락을 취했기 때문에 MT와 달리 모든 것이 준비되어 있기 때문에 GUI도 사용했습니다. 모든 언어, 모든 언어로 응용 프로그램을 개발하는 공개 문제 중 이러한 문제는 특히 net과 관련이 없기 때문에: 1. 피드백, 2. GUI를 차트에 바인딩(https://www.mql5.com/ru/forum /103764 ) 주제 중 하나입니다.
µl, 파이프, 파일 또는 웹 요청에서 단방향 폴링.
그것은 당신의 선택입니다 ;-)
응용 프로그램의 관점에서 볼 때 - DLL을 호출한 후 MT에 "그것이 당신이 원했던 것입니다. 그런 다음 얻으십시오."라고 말하는 규칙적인 방법이 있어야 합니다.
긴 계산에 대한 일반적인 시나리오, DLL이라고 하는 네트워크 IO-MT, DLL이 스레드를 생성하고 그 안에서 무언가가 수행되고 있습니다. 우리는 "모든 것, 잘못 계산된 것"이라고 말하는 규칙적인 방법이 필요합니다. 이것이 없으면 고문에게 끊임없이 질문해야 합니다.
그것은 당신의 선택입니다 ;-)
응용 프로그램의 관점에서 볼 때 - DLL을 호출한 후 MT에 "그것이 당신이 원했던 것입니다. 그런 다음 얻으십시오."라고 말하는 규칙적인 방법이 있어야 합니다.
긴 계산에 대한 일반적인 시나리오, DLL이라고 하는 네트워크 IO-MT, DLL이 스레드를 생성하고 그 안에서 무언가가 수행되고 있습니다. 우리는 "모든 것, 잘못 계산된 것"이라고 말하는 규칙적인 방법이 필요합니다. 이것이 없으면 고문에게 끊임없이 질문해야 합니다.
나는 지원한다!
잘
우리는 모두 개발 환경의 장점에 대해 논쟁할 수 있습니다. 무엇을 위해? 우리는 어떤 개발 시스템도 특정 작업을 해결하기 때문에 자급자족할 수 없다는 것을 잘 알고 있습니다. 그리고 기능을 확장하기 위해 다른 언어나 환경에서 개발된 다른 플러그인이 사용됩니다. 편리한 상호 작용을 제공하기만 하면 됩니다. 우리는 멀리 가지 않을 것입니다. 가져오기를 통해 사용하는 동일한 Windows 라이브러리 ... 도움을 받아 누락된 기능을 구현합니다. 그리고 결국 이것이 순수하게 mql을 통해 구현되었다고 말할 수는 없습니다. ))) 원하는 목표를 달성하고 권한을 부여하기 위해 사용하는 외부 애플리케이션의 차이점은 무엇입니까? 자체 작성 dll이 Windows dll보다 나쁜 이유는 무엇입니까?
예를 들어 다음 기사가 있습니다. https://www.mql5.com/ru/articles/364
그러나 결국 우리는 dll을 완전히 제거하는 것에 대해 이야기하는 것이 아닙니다. MT에는 엄격하게 자체 작업이 있기 때문에 결코 일어나지 않을 것입니다. 이 기사에서는 무엇을 말하든 시스템 라이브러리가 존재합니다. 네, 자체 제작한 라이브러리와 달리 이 라이브러리는 전문가나 지표를 가지고 다닐 필요가 없습니다...
글쎄, 당신이 도구의 리소스에 dll을 컴파일 하는 기능을 추가하는 것을 방해하는 것은 무엇입니까?
예, 시장에서 dll을 사용할 수 없기 때문에 이것을 시장에 내놓을 수는 없지만 자체 개발을 위해서는 훨씬 더 편리할 것입니다.
우리는 모두 개발 환경의 장점에 대해 논쟁할 수 있습니다. 무엇을 위해? 우리는 어떤 개발 시스템도 특정 작업을 해결하기 때문에 자급자족할 수 없다는 것을 잘 알고 있습니다. 그리고 기능을 확장하기 위해 다른 언어나 환경에서 개발된 다른 플러그인이 사용됩니다. 편리한 상호 작용을 제공하기만 하면 됩니다. 우리는 멀리 가지 않을 것입니다. 가져오기를 통해 사용하는 동일한 Windows 라이브러리 ... 도움을 받아 누락된 기능을 구현합니다. 그리고 결국 이것이 순수하게 mql을 통해 구현되었다고 말할 수는 없습니다. ))) 원하는 목표를 달성하고 권한을 부여하기 위해 사용하는 외부 애플리케이션의 차이점은 무엇입니까? 자체 작성 dll이 Windows dll보다 나쁜 이유는 무엇입니까?
예를 들어 다음 기사가 있습니다. https://www.mql5.com/ru/articles/364
그러나 결국 우리는 dll을 완전히 제거하는 것에 대해 이야기하는 것이 아닙니다. MT에는 엄격하게 자체 작업이 있기 때문에 결코 일어나지 않을 것입니다. 이 기사에서는 무엇을 말하든 시스템 라이브러리가 존재합니다. 네, 자체 제작한 라이브러리와 달리 이 라이브러리는 전문가나 지표를 가지고 다닐 필요가 없습니다...
글쎄, 당신이 도구의 리소스에 dll을 컴파일 하는 기능을 추가하는 것을 방해하는 것은 무엇입니까?
예, 시장에서 dll을 사용할 수 없기 때문에 이것을 시장에 내놓을 수는 없지만 자체 개발을 위해서는 훨씬 더 편리할 것입니다.
그런 생각과 글이 벌써 10년이 되었네요.. 그리고 아직도 진행중인 일들...
생태계에 대해 이야기하고 있다면 MT에서 수입품 사용을 중단하면 됩니다. 하지만 그들은 그렇게 하지 않습니다. 결국, 그들이 라이브러리 가져오기를 사용하기로 결정한 것은 아닙니다. 한동안 MT는 웹 요청을 처리할 수 없었고 파일 작업에 제한이 있었습니다. 이 모든 것이 라이브러리를 가져와서 확장되었습니다. 모든 시스템이 이런 식으로 작동하는 것은 당연하지만 지금도 MQL 도구를 사용하면 샌드박스에 있는 파일로만 작업할 수 있습니다. 아무도 이 접근 방식에 이의를 제기하지 않는 것 같습니다. 이것은 개발자의 정책이며 모두가 이를 이해하고 지원합니다. 그리고 샌드박스를 벗어나거나 레지스트리에 액세스하여 데이터를 저장하거나 데이터베이스 또는 매핑을 사용해야 하는 경우 .. 라이브러리 플러그인을 사용하십시오. 그래서 그렇지? 모든 것이 매우 논리적입니다. 이 도구에 대한 데이터베이스도 필요 없고 다른 것도 필요하지 않습니다.이 모든 것은 개발자에게만 필요하므로 MQL 언어를 사용할 수 있으므로 모든 기능의 도구를 구현할 수 있습니다. 그리고 개발 환경이 있기 때문에 MT는 더 이상 그 자체가 아닙니다. )) 당신은 단지 ... 개발해야합니다))))
그런 생각과 글이 벌써 10년이 되었네요.. 그리고 아직도 진행중인 일들...
어떻게 아직 거기에 있습니까?
상호작용을 위한 모든 기회는 오래전부터 있었고 지금도 그래왔습니다. DLL 지원은 일반적으로 2004년에 나타났습니다.
우리의 언어는 끊임없이 진화하고 있으며 더욱 강력하고 기능적으로 발전하고 있습니다. 그리고 생태계는 누구보다 강력합니다.