1. Sharp에 글을 쓴 적도 없고 관심도 없었지만 약 5년 전쯤에 .dll과 버튼, 폼을 Delphi에 연결했는데 모든 것이 전혀 문제 없이 작동했고 낮에는 전체 프로젝트를 Delphi에서 작성하고 시간을 보냈습니다. 반나절 동안 양식이 작동하지 않는 이유를 찾고 Windows 시스템 창 호출을 통해 연결했을 때 모든 것이 제대로 작동했지만 MT4는 그 당시 매우 빡빡하고 느려졌습니다. 이제 날아갑니다.
일반적으로 .dll을 연결하고 표준 뮤텍스와 편리하게 동기화하는 데 문제가 없습니다. 터미널과 통신하기 위해 스레드를 실행하면 끝입니다. 그러면 모든 것이 자체적으로 수행됩니다. .dll의 별도 형식, 별도로 MT 아무도 기다리지 않습니다 누구에게나
추신: Delphi는 .dll을 생성하는 데 다소 비실용적이지만 손에 있던 것(당시 내가 앉아 있던 것)을 사용했습니다)))
2. 주제에 관해서는 글쎄요, MT 전달에서 표준 클래스 를 사용할 수 없는 이유를 이해하지 못합니다. 기껏해야 그래픽을 만드는 프로세스를 통합하는 것이 흥미로울 것입니다. 글쎄요, 보편적인 포함 불필요한 버튼/대화 상자 등을 주석 처리할 수 있는 곳 .P.
1. 이것은 문제를 보는 매우 아마추어적인 방법입니다(공격 없음). 낮에 하는 프로젝트는 프로젝트가 아닙니다. 이것은 작은 문제입니다.
큰 데이터 테이블, 설정 창 및 대화 상자가 있는 10개의 창으로 구성된 응용 프로그램을 만들고 있다고 상상해 보십시오. 델파이에서 그립니다. 그런 다음 DLL을 만듭니다. 그런 다음 MT에서 프로젝트에 연결합니다.
MT 애플리케이션은 공유 메모리를 통해 Delphi GUI에 연결해야 합니다. 기능을 컨트롤에 연결하고 데이터를 테이블 셀에 연결합니다. 응용 프로그램의 두 부분 간의 복잡한 상호 작용을 구성하고 모든 것을 올바르게 생각해야 합니다.
GUI와 MT의 응용 프로그램 두 부분 간에 동기 작동 및 매개 변수 값 교환이 필요합니다.
다시 한 번: 응용 프로그램이 크고 심각한 경우(테이블, 설정 창, 대화 상자, 트리 목록 등...) DLL을 통해 두 부분의 통합되고 잘 조정되고 효율적인 작업을 만드는 것은 매우 심각한 작업입니다. 나는 그것을했고 내가 말하는 것을 알고 있습니다.
그리고 당신은 하루 만에 해결할 수 있는 몇 가지 작은 문제에 대해 이야기하고 있습니다. 이것은 심각하지 않습니다.
2. 표준 라이브러리를 오랫동안 사용할 수 있습니다. 그러나 문제는 필요한 노동 비용과 얻은 결과입니다. 그들은 무엇인가? Anatoly가 표준 라이브러리를 자신의 라이브러리를 만들기 위한 발판으로 사용했다는 것을 알고 있습니다. 표준 라이브러리도 작동한다면 그는 왜 그렇게 했을까요? 대답은 간단합니다. 그는 모든 것을 더 잘 구현하고 표준 라이브러리를 뛰어 넘었습니다. 그러나 대량 분포는 사용의 어려움을 줄여야만 달성할 수 있습니다. 사용하기 쉬울수록 더 많은 사용자가 있게 됩니다(물론 품질 향상을 고려하여).
1. 이것은 문제를 보는 매우 아마추어적인 방법입니다(공격 없음). 낮에 하는 프로젝트는 프로젝트가 아닙니다. 이것은 작은 문제입니다.
큰 데이터 테이블, 설정 창 및 대화 상자가 있는 10개의 창으로 구성된 응용 프로그램을 만들고 있다고 상상해 보십시오. 델파이에서 그립니다. 그런 다음 DLL을 만듭니다. 그런 다음 MT에서 프로젝트에 연결합니다.
MT 애플리케이션은 공유 메모리를 통해 Delphi GUI에 연결해야 합니다. 기능을 컨트롤에 연결하고 데이터를 테이블 셀에 연결합니다. 응용 프로그램의 두 부분 간의 복잡한 상호 작용을 구성하고 모든 것을 올바르게 생각해야 합니다.
GUI와 MT의 응용 프로그램 두 부분 간에 동기 작동 및 매개 변수 값 교환이 필요합니다.
다시 한 번: 응용 프로그램이 크고 심각한 경우(테이블, 설정 창, 대화 상자, 트리 목록 등...) DLL을 통해 두 부분의 통합되고 잘 조정되고 효율적인 작업을 만드는 것은 매우 심각한 작업입니다. 나는 그것을했고 내가 말하는 것을 알고 있습니다.
그리고 당신은 하루 만에 해결할 수 있는 몇 가지 작은 문제에 대해 이야기하고 있습니다. 이것은 심각하지 않습니다.
어떤 불만? 당신은 MT와 .dll 간의 통신이 세상만큼 오래되었다는 것을 이해하지 못합니다.
나는 .dll을 했기 때문에 이전에는 MT에 괜찮은 그래픽이 없었습니다. 버튼과 패널을 원했습니다.
테이블? - 글쎄, 테이블을 그리고 컨트롤? - 그리기 .... 작업을 나눌 수 없습니다. 동일한 델파이에는 데이터베이스 생성 및 작업을 위한 기성 구성 요소가 많이 있습니다.
저것들. MT에서 데이터 자체만 필요하고 나머지는 타사 프로그램에서 수행됩니다. 단어를 사용할 수 있지만 동일한 델파이에서 데이터베이스와 함께 작업을 작성하고 테이블, 그래프 등으로 출력합니다. 하루;)
MT의 데이터는 무엇입니까? = 이것은 단지 눈금과 막대이며 .dll을 통해 기록을 "구동"하는 것은 의미가 없습니다. 모든 것을 파일에 한 번 덤프하고 타사 프로그램에서 파일로 작업하는 것으로 충분합니다.
추신: 최근 포럼의 누군가가 현대 IT 회사에서 직원은 자신이 작업하는 코드를 완전히 이해하는 사람이 아니라 가능한 한 짧은 시간에 많은 양의 작업을 완료할 수 있는 사람, 즉 당신은 다른 사람들의 개발을 당신의 작업에 통합할 수 있어야 하며, 매번 처음부터 모든 것을 구축하지 않아야 합니다! 나는 당신의 주요 활동을 모릅니다. 나는 프로그래머로 일한 적이 없지만 관련 분야에서 끊임없이 일하고 있습니다. 나는 오랫동안 산업용 컨트롤러, 자동화 제어 시스템 및 자동 제어 시스템의 유지 보수에 종사했습니다. 소프트웨어 솔루션을 추가하고 개발자와 상호 작용하기 때문에 모든 기성품 소프트웨어 솔루션을 조사해야 했습니다. 여기에서 모든 것을 처음부터 작성할 수는 없습니다.)))) 산업용 하드웨어 제조업체는 특수 프로그래밍 시스템을 사용합니다. 여기서 C는 어디에 있습니까? SCADA, 어셈블러는 어디에 있으며 다른 사람의 코드를 읽을 수 있어야 할 때마다;)
"엔진"을 기반으로 프로그래머가 미래에 수정할 수 없는 조건부로 실행 가능한 디자인을 만들 것을 제안합니까?
다시 한 번: 응용 프로그램이 크고 심각한 경우(테이블, 설정 창, 대화 상자, 트리 목록 등...) DLL을 통해 두 부분의 통합되고 잘 조정되고 효율적인 작업을 만드는 것은 매우 심각한 작업입니다. 나는 그것을했고 내가 말하는 것을 알고 있습니다.
피터 코노우 :
MQL로 애플리케이션을 완전히 작성하고 모든 장점과 플랫폼 장점을 활용하십시오. (이 경우 GUI 생성에 문제가 있습니다.)
크고 복잡한 응용 프로그램을 만들 수 있는 사람이라면 누구나 gui 라이브러리를 사용할 것입니다. 예를 들어 애플리케이션을 개발하는 동안 개발자가 애니메이션 을 추가하기로 결정한 경우 개발자는 어떻게 해야 합니까? 당신은 찾고 구합니까, 아니면 모든 것을 부수고 다시 짓습니까?
그리고 GUI를 만드는 데 문제가 있다는 것을 어디서 얻었습니까? 시장을 보면 GUI가 있는 응용 프로그램이 많이 있습니다.
GUI 생성자는 특정 그래픽 라이브러리를 위해 만들어졌습니다. MQL용 GUI 생성자가 있다면 여기에 있을 것입니다.
어딘가에서 habré와 같은 기사를 보았습니다. "우리는 Python용 GUI 생성자를 생성합니다"와 같은 것 같아서 누군가가 코드를 추가할 수 있는 다중 플랫폼 GUI를 보았을 것이라고 생각했습니다.
따라서 생성자를 처음부터 작성하는 경우 MQL을 즉시 사용하는 것이 좋습니다.
1. Sharp에 글을 쓴 적도 없고 관심도 없었지만 약 5년 전쯤에 .dll과 버튼, 폼을 Delphi에 연결했는데 모든 것이 전혀 문제 없이 작동했고 낮에는 전체 프로젝트를 Delphi에서 작성하고 시간을 보냈습니다. 반나절 동안 양식이 작동하지 않는 이유를 찾고 Windows 시스템 창 호출을 통해 연결했을 때 모든 것이 제대로 작동했지만 MT4는 그 당시 매우 빡빡하고 느려졌습니다. 이제 날아갑니다.
일반적으로 .dll을 연결하고 표준 뮤텍스와 편리하게 동기화하는 데 문제가 없습니다. 터미널과 통신하기 위해 스레드를 실행하면 끝입니다. 그러면 모든 것이 자체적으로 수행됩니다. .dll의 별도 형식, 별도로 MT 아무도 기다리지 않습니다 누구에게나
추신: Delphi는 .dll을 생성하는 데 다소 비실용적이지만 손에 있던 것(당시 내가 앉아 있던 것)을 사용했습니다)))
2. 주제에 관해서는 글쎄요, MT 전달에서 표준 클래스 를 사용할 수 없는 이유를 이해하지 못합니다. 기껏해야 그래픽을 만드는 프로세스를 통합하는 것이 흥미로울 것입니다. 글쎄요, 보편적인 포함 불필요한 버튼/대화 상자 등을 주석 처리할 수 있는 곳 .P.
1. 이것은 문제를 보는 매우 아마추어적인 방법입니다(공격 없음). 낮에 하는 프로젝트는 프로젝트가 아닙니다. 이것은 작은 문제입니다.
큰 데이터 테이블, 설정 창 및 대화 상자가 있는 10개의 창으로 구성된 응용 프로그램을 만들고 있다고 상상해 보십시오. 델파이에서 그립니다. 그런 다음 DLL을 만듭니다. 그런 다음 MT에서 프로젝트에 연결합니다.
MT 애플리케이션은 공유 메모리를 통해 Delphi GUI에 연결해야 합니다. 기능을 컨트롤에 연결하고 데이터를 테이블 셀에 연결합니다. 응용 프로그램의 두 부분 간의 복잡한 상호 작용을 구성하고 모든 것을 올바르게 생각해야 합니다.
GUI와 MT의 응용 프로그램 두 부분 간에 동기 작동 및 매개 변수 값 교환이 필요합니다.
다시 한 번: 응용 프로그램이 크고 심각한 경우(테이블, 설정 창, 대화 상자, 트리 목록 등...) DLL을 통해 두 부분의 통합되고 잘 조정되고 효율적인 작업을 만드는 것은 매우 심각한 작업입니다. 나는 그것을했고 내가 말하는 것을 알고 있습니다.
그리고 당신은 하루 만에 해결할 수 있는 몇 가지 작은 문제에 대해 이야기하고 있습니다. 이것은 심각하지 않습니다.
2. 표준 라이브러리를 오랫동안 사용할 수 있습니다. 그러나 문제는 필요한 노동 비용과 얻은 결과입니다. 그들은 무엇인가? Anatoly가 표준 라이브러리를 자신의 라이브러리를 만들기 위한 발판으로 사용했다는 것을 알고 있습니다. 표준 라이브러리도 작동한다면 그는 왜 그렇게 했을까요? 대답은 간단합니다. 그는 모든 것을 더 잘 구현하고 표준 라이브러리를 뛰어 넘었습니다. 그러나 대량 분포는 사용의 어려움을 줄여야만 달성할 수 있습니다. 사용하기 쉬울수록 더 많은 사용자가 있게 됩니다(물론 품질 향상을 고려하여).
1. 이것은 문제를 보는 매우 아마추어적인 방법입니다(공격 없음). 낮에 하는 프로젝트는 프로젝트가 아닙니다. 이것은 작은 문제입니다.
큰 데이터 테이블, 설정 창 및 대화 상자가 있는 10개의 창으로 구성된 응용 프로그램을 만들고 있다고 상상해 보십시오. 델파이에서 그립니다. 그런 다음 DLL을 만듭니다. 그런 다음 MT에서 프로젝트에 연결합니다.
MT 애플리케이션은 공유 메모리를 통해 Delphi GUI에 연결해야 합니다. 기능을 컨트롤에 연결하고 데이터를 테이블 셀에 연결합니다. 응용 프로그램의 두 부분 간의 복잡한 상호 작용을 구성하고 모든 것을 올바르게 생각해야 합니다.
GUI와 MT의 응용 프로그램 두 부분 간에 동기 작동 및 매개 변수 값 교환이 필요합니다.
다시 한 번: 응용 프로그램이 크고 심각한 경우(테이블, 설정 창, 대화 상자, 트리 목록 등...) DLL을 통해 두 부분의 통합되고 잘 조정되고 효율적인 작업을 만드는 것은 매우 심각한 작업입니다. 나는 그것을했고 내가 말하는 것을 알고 있습니다.
그리고 당신은 하루 만에 해결할 수 있는 몇 가지 작은 문제에 대해 이야기하고 있습니다. 이것은 심각하지 않습니다.
어떤 불만? 당신은 MT와 .dll 간의 통신이 세상만큼 오래되었다는 것을 이해하지 못합니다.
나는 .dll을 했기 때문에 이전에는 MT에 괜찮은 그래픽이 없었습니다. 버튼과 패널을 원했습니다.
테이블? - 글쎄, 테이블을 그리고 컨트롤? - 그리기 .... 작업을 나눌 수 없습니다. 동일한 델파이에는 데이터베이스 생성 및 작업을 위한 기성 구성 요소가 많이 있습니다.
저것들. MT에서 데이터 자체만 필요하고 나머지는 타사 프로그램에서 수행됩니다. 단어를 사용할 수 있지만 동일한 델파이에서 데이터베이스와 함께 작업을 작성하고 테이블, 그래프 등으로 출력합니다. 하루;)
MT의 데이터는 무엇입니까? = 이것은 단지 눈금과 막대이며 .dll을 통해 기록을 "구동"하는 것은 의미가 없습니다. 모든 것을 파일에 한 번 덤프하고 타사 프로그램에서 파일로 작업하는 것으로 충분합니다.
추신: 최근 포럼의 누군가가 현대 IT 회사에서 직원은 자신이 작업하는 코드를 완전히 이해하는 사람이 아니라 가능한 한 짧은 시간에 많은 양의 작업을 완료할 수 있는 사람, 즉 당신은 다른 사람들의 개발을 당신의 작업에 통합할 수 있어야 하며, 매번 처음부터 모든 것을 구축하지 않아야 합니다! 나는 당신의 주요 활동을 모릅니다. 나는 프로그래머로 일한 적이 없지만 관련 분야에서 끊임없이 일하고 있습니다. 나는 오랫동안 산업용 컨트롤러, 자동화 제어 시스템 및 자동 제어 시스템의 유지 보수에 종사했습니다. 소프트웨어 솔루션을 추가하고 개발자와 상호 작용하기 때문에 모든 기성품 소프트웨어 솔루션을 조사해야 했습니다. 여기에서 모든 것을 처음부터 작성할 수는 없습니다.)))) 산업용 하드웨어 제조업체는 특수 프로그래밍 시스템을 사용합니다. 여기서 C는 어디에 있습니까? SCADA, 어셈블러는 어디에 있으며 다른 사람의 코드를 읽을 수 있어야 할 때마다;)
"엔진"을 기반으로 프로그래머가 미래에 수정할 수 없는 조건부로 실행 가능한 디자인을 만들 것을 제안합니까?
어떤 불만? 당신은 MT와 .dll 간의 통신이 세상만큼 오래되었다는 것을 이해하지 못합니다.
나는 .dll을 했기 때문에 이전에는 MT에 괜찮은 그래픽이 없었습니다. 버튼과 패널을 원했습니다.
테이블? - 글쎄, 테이블을 그리고 컨트롤? - 그리기 .... 작업을 나눌 수 없습니다. 동일한 델파이에는 데이터베이스 생성 및 작업을 위한 기성 구성 요소가 많이 있습니다.
저것들. MT에서 데이터 자체만 필요하고 나머지는 타사 프로그램에서 수행됩니다. 단어를 사용할 수 있지만 동일한 델파이에서 데이터베이스와 함께 작업을 작성하고 테이블, 그래프 등으로 출력합니다. 하루;)
추신: MT의 데이터는 무엇입니까? = 이것은 단지 눈금과 막대이며 .dll을 통해 기록을 "구동"하는 것은 의미가 없습니다. 모든 것을 파일에 한 번 덤프하고 타사 프로그램에서 파일로 작업하는 것으로 충분합니다.
MT에서 입력된 데이터만 가져오고 DLL을 통해 Delphi, C++ 또는 C #으로 작성된 응용 프로그램으로 전송하면 이것이 가능합니다 . 그런 다음 거래 응용 프로그램은 완전히 다른 프로그래밍 언어로 작성됩니다.
즉, timeseries , tester , 최적화 , 합성 및 훨씬 더, 다른 언어로 독립적으로 생성해야 합니다.
그렇다면 MQL이 필요한 이유는 무엇입니까? 타사 애플리케이션에 직접 데이터를 제공하고 플랫폼을 이벤트 및 주문의 전송기로 사용하는 것으로 충분합니다. 그리고 그게 다야. 그러나 거래 시스템의 언어로서의 MQL의 장점은 사라질 것입니다.
MQL이 필요한 이유는 무엇입니까?
그런 다음 해당 MQL은 거래 응용 프로그램을 작성하기 위해 예리한 응용 언어입니다. 이것이 주요 이점입니다. 그는 가볍고 단순합니다. 프로그래머를 위한 기성품 솔루션이 많이 있습니다. 그들은 그것을 가지고 사용합니다.
프로그래머는 다음을 선택할 수 있습니다.
분명히 가장 선호되는 옵션은 테스트, 최적화, 연구(합성), 지표, 편리한 기능, 시계열 ... + 포럼에서 언어의 기술 지원과 같은 이점을 제공하기 때문에 MQL 및 MT를 사용하는 것입니다.
그러나 이 이상적인 변형에는 한 가지 심각한 단점 이 있습니다. 고품질 GUI를 생성하기 어렵기 때문에 복잡한 애플리케이션을 생성할 수 있는 능력이 제한된다는 것입니다.
나는 이 마지막 문제를 대부분 해결했다.
따라서 연습과 관련하여 진지한 응용 프로그램을 작성하기 시작하면 확실히 MT를 선택할 것입니다. 많은 다른 사람들처럼.
...
"엔진"을 기반으로 프로그래머가 미래에 수정할 수 없는 조건부로 실행 가능한 디자인을 만들 것을 제안합니까?
엔진은 내 생성자에서 생성된 GUI의 "캐리어"입니다. 수정할 필요가 없습니다. 애플리케이션에 연결하기만 하면 생성된 GUI가 작동합니다.
다시 한 번: 응용 프로그램이 크고 심각한 경우(테이블, 설정 창, 대화 상자, 트리 목록 등...) DLL을 통해 두 부분의 통합되고 잘 조정되고 효율적인 작업을 만드는 것은 매우 심각한 작업입니다. 나는 그것을했고 내가 말하는 것을 알고 있습니다.
크고 복잡한 응용 프로그램을 만들 수 있는 사람이라면 누구나 gui 라이브러리를 사용할 것입니다. 예를 들어 애플리케이션을 개발하는 동안 개발자가 애니메이션 을 추가하기로 결정한 경우 개발자는 어떻게 해야 합니까? 당신은 찾고 구합니까, 아니면 모든 것을 부수고 다시 짓습니까?
그리고 GUI를 만드는 데 문제가 있다는 것을 어디서 얻었습니까? 시장을 보면 GUI가 있는 응용 프로그램이 많이 있습니다.
1. 크고 복잡한 애플리케이션을 만들 수 있는 사람이라면 누구나 gui 라이브러리를 사용할 것입니다.
2. 개발자는 애플리케이션을 개발하는 동안 예를 들어 애니메이션을 추가하기로 결정했다면 어떻게 해야 합니까? 당신은 찾고 구합니까, 아니면 모든 것을 부수고 다시 짓습니까?
3. GUI 생성에 문제가 있다는 것을 어디서 얻었습니까? 시장을 보면 GUI가 있는 응용 프로그램이 많이 있습니다.
1. 그것이 바로 요점입니다. GUI - 진지한 프로그래머를 위해 설계된 라이브러리. 사용의 어려움으로 인해 널리 배포되지 않습니다. 그리고 요점은 무엇입니까? 장치는 라이브러리를 살펴보고 복잡한 응용 프로그램을 만들지만 다른 장치는 할 수 없습니까?
2. 개발자가 자신의 응용 프로그램에서 애니메이션 을 만들도록 합니다. 내가 뭘 한거지? GUI 및 엔진과 독립적으로 이 애니메이션을 호출하거나 자체 애니메이션 호출을 일부 버튼에 바인딩할 수 있습니다.
3. GUI에 관심을 가질 만한 사람은 소수에 불과합니다. 당신, Anatoly, 그리고 아마도 다른 누군가 ... 나머지는 다소 심각한 수준에 도달하지 않습니다.
3. GUI에 관심을 가질 만한 사람은 소수에 불과합니다.
나는 그렇게 범주적이지 않을 것입니다. 그리고 저는 gui 라이브러리를 개발하는 것이 아니라 gui를 사용하는 응용 프로그램에 대해 이야기하고 있습니다. 따라서 시장에는 자체 개발을 사용하고 표준이며 Anatoly의 라이브러리인 많은 사람들이 있습니다.
1. 그것이 바로 요점입니다. GUI - 진지한 프로그래머를 위해 설계된 라이브러리. 사용의 어려움으로 인해 널리 배포되지 않습니다. 그리고 요점은 무엇입니까? 장치는 라이브러리를 살펴보고 복잡한 응용 프로그램을 만들지만 다른 장치는 할 수 없습니까?
2. 개발자가 응용 프로그램에서 애니메이션을 만들도록 합니다. 내가 뭘 한거지? GUI 및 엔진과 독립적으로 이 애니메이션을 호출하거나 자체 애니메이션 호출을 일부 버튼에 바인딩할 수 있습니다.
3. GUI에 관심을 가질 만한 사람은 소수에 불과합니다. 당신, Anatoly, 그리고 아마도 다른 누군가 ... 나머지는 다소 심각한 수준에 도달하지 않습니다.
Peter, 내 생각에 당신의 주요 문제는 프로젝트의 위치에 있습니다.
프로그래밍에 상당한 경험이 있지만 동시에 손으로 거래하는 것을 선호하는 참가자에게만 관심이 있을 수 있습니다.
많이 있다고 생각하십니까?
글쎄, 봐 - 개발에 대한 모든 비평가는 정기적으로 "수동"거래에 참여하지 않는 사람들입니다. 최대 - 때때로. 그리고 그들은 당신의 프로젝트를 수동 거래자처럼 보지 않기 때문에 프로그래머처럼 봅니다. 그리고 물론 그들은 매우 모호한 해결책을 많이 찾습니다.
제 생각에는 귀하의 질문은 이제 손으로 거래하는 것을 선호하는 프로그래머인 이 틈새 시장(제 생각에는 매우 좁음)을 찾는 것이어야 합니다.
어딘가에서 habré와 같은 기사를 보았습니다. "우리는 Python용 GUI 생성자를 생성합니다"와 같은 것 같아서 누군가가 코드를 추가할 수 있는 다중 플랫폼 GUI를 보았을 것이라고 생각했습니다.
따라서 생성자를 처음부터 작성하는 경우 MQL을 즉시 사용하는 것이 좋습니다.
최신 GUI 생성자("양식에 버튼을 흩뿌리는 것")는 상당히 기술적인 것이며 여기에 MQL 요소를 연결하는 것은 환상적으로 보이지 않습니다.
거의 모든 사람은 요소의 위치와 관계를 설명하는 XML을 포함하는 중간 형식( 프로젝트 파일 등)을 가지고 있습니다.
대상 플랫폼 코드 생성 - 사실 이것은 자신을 웹 프로그래머라고 생각하는 사람이라면 누구나 할 수 있는 XSLT 변환입니다 :-)
예를 들어 EasyAndFast(https://www.mql5.com/en/code/19703)는 객체 하나이고 필요한 모든 구성 요소를 가지고 있기 때문에 가져옵니다. (그런데 주제와 달리 공개되고 문서화 되어 있음),
번역기는 단순히 작성되었습니다.
gui-mql 생성자가 없기 때문이 아니라 단순히 수요가 없기 때문입니다.