DLL에 공유 메모리를 생성합니다. MT5에서 접근할 때 버튼과 체크박스의 상태를 변경하기 위한 플래그가 설정되도록 합니다. 그런 다음 Windows 응용 프로그램은 공유 메모리에 액세스하고 플래그를 읽고 하나 또는 다른 양식 요소의 상태를 변경해야 한다는 것을 배웠습니다.
MT5의 타이머에서 DLL에 대한 순환 호출을 작성하여 함수 호출 플래그를 읽거나 필드에 텍스트를 입력합니다.
수백 개의 요소가 있다면 어떻게 될까요?
공유 메모리를 올바르게 구성하는 방법은 무엇입니까?
양식에 있는 요소의 눌림/눌림 상태뿐만 아니라 색상(예: 버튼)도 변경해야 하는 경우 어떻게 해야 합니까?
MT5에서 양식의 입력 필드에 있는 텍스트를 프로그래밍 방식으로 변경해야 하는 경우 어떻게 해야 합니까?
1. 무엇이 문제인가? 생성 시 프로젝트 유형 선택입니다.
2. Igor의 예시에서 볼 수 있듯이, import 도 설명할 필요가 없을 정도로 한 줄로 연결됩니다.
3. 메소드는 한 번 작성하여 파일로 저장한 후 변경 없이 모든 프로젝트에서 사용합니다.
4. 아마도 필요하지만 간단합니다. 대부분의 경우 모든 것이 필요한 것은 아니지만 c #의 컨트롤 간에 상호 작용이 있을 것이며 외부에 하나의 이벤트를 표시해야 하고 양식에 100개의 버튼이 있을 수 있습니다.
5. 이는 3항에 적용됩니다.
6. 또한 단락 3의 올바른 접근 방식이 포함된 한 줄.
7 - 당신의 손에 있는 C #의 모든 힘, 당신이 전혀 모르는 것 같은 규모, 하나는 거대합니다.
다음과 같이 할 수 있습니다. dll에서 하나의 배열 또는 두 개의 배열, 하나는 개체 이름용이고 다른 하나 는 이벤트 유형용 입니다.
여기!
아직 확인하지 않았지만 개발자가 C # .Net에 대한 고급 지원을 가지고 있다면 MT5와 .dll 간의 복잡한 데이터 유형 교환이 작동할 수 있습니다. 구조
구조 교환이 작동하면 일반적으로 작업이 단순화되고 원시주의로 축소됩니다. 예를 들어 "Trade" 탭 형식으로 터미널 정보를 반복하려고 합니다.
틱에서 OrderProfit,OrderTicket,OrderStoploss....로 구조를 채우고 이 구조를 .dll로 보내고 사용자가 클릭한 응답 구조를 얻으면 그게 다입니다. 그러면 양식이 시각적 정보를 회전합니다. 터미널 자체
그런 다음 DLL 내부에 COMMON 메모리를 만듭니다.
양식 요소의 수가 증가하고 MT5에서 프로그램의 기능이 복잡해짐에 따라 이 상호 작용은 엄청나게 로드되고 복잡해집니다.
흠 뭐가 그렇게 어렵나요? 시각화 = .dll 따로 분리, MT 작업 분리
설명하기 어려운데 메모리를 통한 데이터 교환 속도가 얼마나 되는지 아십니까? - 우리는 초당 십만 바이트에 대해 이야기하지 않고 초당 수백만, 수십억 바이트에 대해 이야기하지 않으며 교환의 복잡성에 대해 이야기하고 있습니다)))))
확인.
따라서 다음이 필요합니다.
수백 개의 요소가 있다면 어떻게 될까요?
공유 메모리를 올바르게 구성하는 방법은 무엇입니까?
양식에 있는 요소의 눌림/눌림 상태뿐만 아니라 색상(예: 버튼)도 변경해야 하는 경우 어떻게 해야 합니까?
MT5에서 양식의 입력 필드에 있는 텍스트를 프로그래밍 방식으로 변경해야 하는 경우 어떻게 해야 합니까?
1. 무엇이 문제인가? 생성 시 프로젝트 유형 선택입니다.
2. Igor의 예시에서 볼 수 있듯이, import 도 설명할 필요가 없을 정도로 한 줄로 연결됩니다.
3. 메소드는 한 번 작성하여 파일로 저장한 후 변경 없이 모든 프로젝트에서 사용합니다.
4. 아마도 필요하지만 간단합니다. 대부분의 경우 모든 것이 필요한 것은 아니지만 c #의 컨트롤 간에 상호 작용이 있을 것이며 외부에 하나의 이벤트를 표시해야 하고 양식에 100개의 버튼이 있을 수 있습니다.
5. 이는 3항에 적용됩니다.
6. 또한 단락 3의 올바른 접근 방식이 포함된 한 줄.
7 - 당신의 손에 있는 C #의 모든 힘, 당신이 전혀 모르는 것 같은 규모, 하나는 거대합니다.
실례는 아니지만 그렇지 않은 것이 유감입니다.
복잡성이 증가하지 않을 것이라고 믿고 가장 단순한 예를 들어 외삽합니다. 이것은 실수입니다.
당신이 준 가장 간단한 예도 틀렸습니다. 생성된 양식 외에 DLL도 생성해야 하기 때문입니다. 그런 다음 DLL 내부에 COMMON 메모리를 만듭니다.
양식 요소의 수가 증가하고 MT5에서 프로그램의 기능이 복잡해짐에 따라 이 상호 작용은 엄청나게 로드되고 복잡해집니다.
나는 이것을 실제로 테스트했다.
결론은 완전히 틀렸다.
문제는 내가 말하는 것을 정말로 했다는 것입니다. 그리고 복잡한 MT 프로그램과 복잡한 타사 프로그램 간의 상호 작용을 구성하는 것이 얼마나 어려운지 압니다.
그리고 아마추어적인 접근 방식은 일반적으로 "예, 그것은 단지 ... 문제가 무엇입니까? 그렇군요, 그렇군요 ..."라는 말로 구성됩니다.
복잡한 MT 프로그램을 복잡한 Windows 양식에 연결하는 예를 제공합니다. 여기서 프로그램은 다음을 수행할 수 있습니다.
문제는 내가 말하는 것을 정말로 했다는 것입니다. 그리고 복잡한 MT 프로그램과 복잡한 타사 프로그램 간의 상호 작용을 구성하는 것이 얼마나 어려운지 압니다.
그리고 아마추어적인 접근 방식은 일반적으로 "예, 그것은 단지 ... 문제가 무엇입니까? 그렇군요, 그렇군요 ..."라는 말로 구성됩니다.
복잡한 MT 프로그램을 복잡한 Windows 양식에 연결하는 예를 제공합니다. 여기서 프로그램은 다음을 수행할 수 있습니다.
그들이 그랬다면 오늘날과 같은 질문을 하지 않았을 것입니다. C#을 배우고 스스로 해보세요. 어제 Igor가 보여준 dll 및 호출 방법을 연결하는 방법.
1. 무엇이 문제인가? 생성 시 프로젝트 유형 선택입니다.
2. Igor의 예시에서 볼 수 있듯이, import도 설명할 필요가 없을 정도로 한 줄로 연결됩니다.
3. 메소드는 한 번 작성하여 파일로 저장한 후 변경 없이 모든 프로젝트에서 사용합니다.
4. 아마도 필요하지만 간단합니다. 대부분의 경우 모든 것이 필요한 것은 아니지만 c #의 컨트롤 간에 상호 작용이 있을 것이며 외부에 하나의 이벤트를 표시해야 하고 양식에 100개의 버튼이 있을 수 있습니다.
5. 이는 3번 항목에 적용됩니다.
6. 또한 단락 3의 올바른 접근 방식으로 한 줄.
7 - 당신의 손에 있는 C #의 모든 힘, 당신이 전혀 모르는 것 같은 규모, 하나는 거대합니다.
Dmitry, C#의 강력한 기능을 사용하고 MT 애플리케이션과 상호 작용하고 다음 작업을 수행하는 형식으로 그다지 복잡하지 않은 애플리케이션을 만드십시오.
Dmitry, C#의 강력한 기능을 사용하고 MT 애플리케이션과 상호 작용하고 다음 작업을 수행하는 형식으로 그다지 복잡하지 않은 애플리케이션을 만드십시오.
할 일이 있어요. 그러나 계속해서 망상에 빠져 있을 수 있습니다.
그리고 오 예, 프로그래밍에서 전례가 없는 기적입니다. 무언가를 하려면 이를 위한 함수를 작성해야 합니다.
할 일이 있어요. ...
좋아, 아마도 Igor가 그렇게 할 것입니다 ...
좋아, 아마도 Igor가 그렇게 할 것입니다 ...
이고르는 이미 너무 많은 것을 보여주었다. 그리고 너무 많이 말했어요.