예, 이것이 주요 문제입니다! 같은 시장에서는 dll의 사용을 금지하므로 바퀴를 재발명해야 합니다. 글쎄, 누군가 GUI가 필요하지 않다고 생각하지만 어쨌든 하나의 스레드에서 복잡한 장기 계산을 수행할 수 없다면 모든 것이 중단될 것입니다! 그래서 이것은 시장에서 금지된 dll .. 에서 이루어져야 합니다 ...
등. 이러한 이유로 모든 것은 mql 메서드를 사용하여 그려지고 해결되어야 합니다.
사실, GUI와 로직을 스레드로 나누는 것은 물론, 이미 지금 할 수 있습니다. 사람들은 이미 병렬 처리 문제에 대해 논의했습니다. https://www.mql5.com/en/forum/288985/page5#comment_14722396.
결과적으로 Windows에서와 같이 양식 자체를 기본 스레드에 남겨두고 추가 계산을 "백그라운드" 실행으로 전송할 수 있습니다. 이것이 Windows, Linux 및 Android가 작동하는 방식입니다.
예, 나는이 기사를 보았습니다. 그 자체로 이해하려는 욕구조차없는 많은 코드가있는 또 다른 목발입니다. 모든 것이 dll에서 훨씬 빠르고 쉽게 수행될 때. 그건 그렇고, 나는 또한 mql Socket 및 WebRequest 를 거부했는데, mql 서버를 사용할 수 없을 때 연결이 끊어져, 그런 다음 소켓 또는 웹 요청 기능의 실행이 차단되므로 mql 소켓 및 웹 요청에서 애플리케이션을 빌드하기로 결정한 경우 이 점을 염두에 두십시오.
Windows를 업데이트하고 불법 복제된 Windows에서 제품을 정품 인증할 때 사람들이 로그인을 잃는 이유는 무엇이라고 생각합니까?
Microsoft 및 dll 서명 키는 무엇과 관련이 있습니까? 개발자만 식별합니다. dll 서명용 키는 시장에서 완전한 식별을 통과한 사람에게 MQ에서 발급할 수 있습니다. 이 키로 개발자는 dll에 서명하여 dll을 작성한 사람을 식별합니다. 즉, dll 서명 키는 제품 활성화에 영향을 미치지 않습니다.
MKL에 정상적인 GUI가 없다는 것을 이해할 수 있습니까? 그 하나는 - 이것은 95 년입니다. 부끄러운 일이어야합니다 ... 타사 GUI를 호출하여 MT에서 사용하는 방법에 대해 생각 했습니까? 연결하는 방법? 아니면 꿀을 먹이지 않는 것이 상식이라고 할까요?))
Peter, 나는 아마도 당신에게 눈을 뜨고 Maxim에 대해 말할 것입니다. Maxim은 누구보다 이 주제에 익숙하며, 1년 반 전에 그는 모든 사람이 볼 수 있도록 마크업을 기반으로 합니다. 또한 GUI는 외부 환경에서 구축되었지만 프로그램(지표, 전문가)과 완전한 상호 작용을 했습니다.
Peter, 나는 아마도 당신에게 눈을 뜨고 Maxim에 대해 말할 것입니다. Maxim은 누구보다 이 주제에 익숙하며, 1년 반 전에 그는 모든 사람이 볼 수 있도록 마크업을 기반으로 합니다. 또한 GUI는 외부 환경에서 구축되었지만 프로그램(지표, 전문가)과 완전한 상호 작용을 했습니다.
이번 버전에서는 Border가 주 요소로 차트에 캔버스 객체를 생성하고 모든 부하직원이 그 위에 그림을 그립니다. 오히려 종속에 따라 그립니다.
닫기 버튼은 캡션에 그려지고 캡션은 테두리에 그려지며 모든 그려진 요소가 캔버스에 그려집니다.
그가 무엇을 게시했고 GUI에서 무엇을 했는지는 모르지만 내 스레드에서 그는 단일 솔루션이 아니라 단일 기술 제안을 하지 않았으며 주제에 대한 토론을 주도하지 않았습니다. 제3자 솔루션을 가리키고 바퀴를 재발명하지 말라고 외치는 빈 트롤링만 있을 뿐입니다.
다시 주제로 돌아가자.
내가 표준 라이브러리에 대해 잘 아는 한(사실 거의 없음) 요소와 창은 MT 개체로 구성됩니다. 즉, 우리 컨텍스트에서는 캔버스에 그려지지 않습니다. 물론 그것들은 그려지지만 우리의 캔버스에는 그려지지 않기 때문에 픽셀 색상을 제어하고 표면 그라디언트를 만드는 등의 기능을 제공하지 않습니다.
이론적으로 라이브러리의 구조를 가져 와서 복사하고 캔버스에 아날로그를 만들 수 있습니다. 이론에 의하면...
문제는 Ccanvas 자체가 GUI를 만드는 데 편리하지 않다는 것입니다. 왜요? 캔버스 시스템이 주로 그래픽 프리미티브에 맞게 조정되었기 때문입니다. 즉, 사실 이 클래스는 프리미티브 외에는 아무것도 제공하지 않습니다. GUI 아키텍처는 스스로 구축해야 합니다. 그리고 이 경우 클래스는 선택 사항입니다. 스스로 결정을 내리는 것이 좋습니다. 결국 이 클래스 없이 직사각형 레이블을 그릴 수 있습니다. 캔버스를 생성하거나 업로드하는 방법. 아주 간단합니다. 따라서 나는 내 솔루션을 선호했습니다.
그가 무엇을 게시했고 GUI에서 무엇을 했는지는 모르지만 내 스레드에서 그는 단일 솔루션이 아니라 단일 기술 제안을 하지 않았으며 주제에 대한 토론을 주도하지 않았습니다. 제3자 솔루션을 가리키고 바퀴를 재발명하지 말라고 외치는 빈 트롤링만 있을 뿐입니다.
다시 주제로 돌아가자.
내가 표준 라이브러리에 대해 잘 아는 한(사실 거의 없음) 요소와 창은 MT 개체로 구성됩니다. 즉, 우리의 맥락에서 그것들은 캔버스에 그려지지 않습니다. 물론 그것들은 그려지지만 우리의 캔버스에는 그려지지 않기 때문에 픽셀 색상을 제어하고 표면 그라디언트를 만드는 등의 기능을 제공하지 않습니다.
이론적으로 라이브러리의 구조를 가져 와서 복사하고 캔버스에 아날로그를 만들 수 있습니다. 이론에 의하면...
문제는 Ccanvas 자체가 GUI를 만드는 데 편리하지 않다는 것입니다. 왜요? 캔버스 시스템이 주로 그래픽 프리미티브에 맞게 조정되었기 때문입니다. 즉, 사실 이 클래스는 프리미티브 외에는 아무것도 제공하지 않습니다. GUI 아키텍처는 스스로 구축해야 합니다. 그리고 이 경우 클래스는 선택 사항입니다. 스스로 결정을 내리는 것이 좋습니다. 결국 이 클래스 없이 직사각형 레이블을 그릴 수 있습니다. 캔버스를 생성하거나 업로드하는 방법. 아주 간단합니다. 따라서 나는 내 솔루션을 선호했습니다.
그러나 어떤 식으로든 CCCanvas가 없는 사람에게. 그러므로 나는 주장하지 않는다.
중지! 피터(맞나?), 서로 이해하기 위해 몇 가지 관례를 받아들이자. 규칙 1: 우리는 Canvas를 CCanvas 클래스가 아니라 단순히 화면의 일부 또는 특히 하나의 리소스를 그리기 위한 캔버스라고 부를 것입니다. CCanvas 클래스는 이 모든 것과 관련이 없으며 우리는 이에 대해 전혀 언급하지 않을 것입니다. 동일한 캔버스에 그리기 위한 기능만 제공하면 됩니다. 사실 우리는 다양한 방법으로 그림을 그릴 수 있습니다.
"그리기"라는 단어 는 리소스가 생성 되고 이후에 차트에 배치되는 기반으로 픽셀 배열의 형성을 의미합니다.
중지! 피터(맞나?), 서로 이해하기 위해 몇 가지 관례를 받아들이자. 규칙 1: 우리는 Canvas를 CCanvas 클래스가 아니라 단순히 화면의 일부 또는 특히 하나의 리소스를 그리기 위한 캔버스라고 부를 것입니다. CCanvas 클래스는 이 모든 것과 관련이 없으며 우리는 이에 대해 전혀 언급하지 않을 것입니다. 동일한 캔버스에 그리기 위한 기능만 제공하면 됩니다. 사실 우리는 다양한 방법으로 그림을 그릴 수 있습니다.
"그리기"라는 단어는 픽셀 배열의 형성을 의미하며, 이를 기반으로 리소스가 생성 되어 차트에 배치됩니다.
Peter, 나는 아마도 당신에게 눈을 뜨고 Maxim에 대해 말할 것입니다. Maxim은 누구보다 이 주제에 익숙하며, 1년 반 전에 그는 모든 사람이 볼 수 있도록 마크업을 기반으로 합니다. 또한 GUI는 외부 환경에서 구축되었지만 프로그램(지표, 전문가)과 완전한 상호 작용을 했습니다.
그건 그렇고, 사람들은 오래 전에 종사했기 때문에 :
이것은 GUI 클라이언트-서버 인터페이스인 yandex에서, 그리고 심지어 네트워크를 통해 무작위로 찍은 스크린샷입니다. 바퀴를 재발명할 필요가 없습니다...
(상업 두번째) Pi는 정말 멋지다. 정직한 울프람이 그곳에 살고 있습니다 :-)
예, 이것이 주요 문제입니다! 같은 시장에서는 dll의 사용을 금지하므로 바퀴를 재발명해야 합니다. 글쎄, 누군가 GUI가 필요하지 않다고 생각하지만 어쨌든 하나의 스레드에서 복잡한 장기 계산을 수행할 수 없다면 모든 것이 중단될 것입니다! 그래서 이것은 시장에서 금지된 dll .. 에서 이루어져야 합니다 ...
등. 이러한 이유로 모든 것은 mql 메서드를 사용하여 그려지고 해결되어야 합니다.
사실, GUI와 로직을 스레드로 나누는 것은 물론, 이미 지금 할 수 있습니다. 사람들은 이미 병렬 처리 문제에 대해 논의했습니다. https://www.mql5.com/en/forum/288985/page5#comment_14722396.
결과적으로 Windows에서와 같이 양식 자체를 기본 스레드에 남겨두고 추가 계산을 "백그라운드" 실행으로 전송할 수 있습니다. 이것이 Windows, Linux 및 Android가 작동하는 방식입니다.
예, 나는이 기사를 보았습니다. 그 자체로 이해하려는 욕구조차없는 많은 코드가있는 또 다른 목발입니다.
모든 것이 dll에서 훨씬 빠르고 쉽게 수행될 때.
그건 그렇고, 나는 또한 mql Socket 및 WebRequest 를 거부했는데, mql 서버를 사용할 수 없을 때 연결이 끊어져,
그런 다음 소켓 또는 웹 요청 기능의 실행이 차단되므로 mql 소켓 및 웹 요청에서 애플리케이션을 빌드하기로 결정한 경우 이 점을 염두에 두십시오.
그건 그렇고, 사람들은 오래 전에 종사했기 때문에 :
이것은 GUI 클라이언트-서버 인터페이스인 yandex에서, 그리고 심지어 네트워크를 통해 무작위로 찍은 스크린샷입니다. 바퀴를 재발명할 필요가 없습니다...
(상업 두번째) Pi는 정말 멋지다. 정직한 울프람이 그곳에 살고 있습니다 :-)
그건 그렇고, 스크린 샷의 스크래치는 대략 Konov가하고 싶은 것입니다. 큐브에서 알고리즘을 추가합니다.
하지만 이 개미집에서는 마이크로소프트가 메인이기 때문에 :-)
Windows를 업데이트하고 불법 복제된 Windows에서 제품을 정품 인증할 때 사람들이 로그인을 잃는 이유는 무엇이라고 생각합니까?
Microsoft 및 dll 서명 키는 무엇과 관련이 있습니까? 개발자만 식별합니다.
dll 서명용 키는 시장에서 완전한 식별을 통과한 사람에게 MQ에서 발급할 수 있습니다.
이 키로 개발자는 dll에 서명하여 dll을 작성한 사람을 식별합니다.
즉, dll 서명 키는 제품 활성화에 영향을 미치지 않습니다.
///
MKL에 일반 GUI가 없다는 것을 이해할 수 있습니까? 그 하나는 - 이것은 95 년입니다. 부끄러운 일이어야합니다 ... 타사 GUI를 호출하여 MT에서 사용하는 방법에 대해 생각 했습니까? 연결하는 방법? 아니면 꿀을 먹이지 않는 것이 상식이라고 할까요?))
MKL에 정상적인 GUI가 없다는 것을 이해할 수 있습니까? 그 하나는 - 이것은 95 년입니다. 부끄러운 일이어야합니다 ... 타사 GUI를 호출하여 MT에서 사용하는 방법에 대해 생각 했습니까? 연결하는 방법? 아니면 꿀을 먹이지 않는 것이 상식이라고 할까요?))
Peter, 나는 아마도 당신에게 눈을 뜨고 Maxim에 대해 말할 것입니다. Maxim은 누구보다 이 주제에 익숙하며, 1년 반 전에 그는 모든 사람이 볼 수 있도록 마크업을 기반으로 합니다. 또한 GUI는 외부 환경에서 구축되었지만 프로그램(지표, 전문가)과 완전한 상호 작용을 했습니다.
맥심, 답장을 드려서 죄송합니다.
주제로 돌아가고 싶습니다. 나는 표준 라이브러리의 작업에 대한 한 기사에서 그림을 꺼냈습니다.
이 화면은 대화의 구성을 단순화한 형태로 보여줍니다.
이번 버전에서는 Border가 주 요소로 차트에 캔버스 객체를 생성하고 모든 부하직원이 그 위에 그림을 그립니다. 오히려 종속에 따라 그립니다.
닫기 버튼은 캡션에 그려지고 캡션은 테두리에 그려지며 여기에서 그려진 모든 요소와 함께 캔버스에 그려집니다.
Peter, 나는 아마도 당신에게 눈을 뜨고 Maxim에 대해 말할 것입니다. Maxim은 누구보다 이 주제에 익숙하며, 1년 반 전에 그는 모든 사람이 볼 수 있도록 마크업을 기반으로 합니다. 또한 GUI는 외부 환경에서 구축되었지만 프로그램(지표, 전문가)과 완전한 상호 작용을 했습니다.
맥심, 답장을 드려서 죄송합니다.
주제로 돌아가고 싶습니다. 나는 표준 라이브러리의 작업에 대한 한 기사에서 그림을 꺼냈습니다.
이 화면은 대화의 구성을 단순화한 형태로 보여줍니다.
이번 버전에서는 Border가 주 요소로 차트에 캔버스 객체를 생성하고 모든 부하직원이 그 위에 그림을 그립니다. 오히려 종속에 따라 그립니다.
닫기 버튼은 캡션에 그려지고 캡션은 테두리에 그려지며 모든 그려진 요소가 캔버스에 그려집니다.
그가 무엇을 게시했고 GUI에서 무엇을 했는지는 모르지만 내 스레드에서 그는 단일 솔루션이 아니라 단일 기술 제안을 하지 않았으며 주제에 대한 토론을 주도하지 않았습니다. 제3자 솔루션을 가리키고 바퀴를 재발명하지 말라고 외치는 빈 트롤링만 있을 뿐입니다.
다시 주제로 돌아가자.
내가 표준 라이브러리에 대해 잘 아는 한(사실 거의 없음) 요소와 창은 MT 개체로 구성됩니다. 즉, 우리 컨텍스트에서는 캔버스에 그려지지 않습니다. 물론 그것들은 그려지지만 우리의 캔버스에는 그려지지 않기 때문에 픽셀 색상을 제어하고 표면 그라디언트를 만드는 등의 기능을 제공하지 않습니다.
이론적으로 라이브러리의 구조를 가져 와서 복사하고 캔버스에 아날로그를 만들 수 있습니다. 이론에 의하면...
문제는 Ccanvas 자체가 GUI를 만드는 데 편리하지 않다는 것입니다. 왜요? 캔버스 시스템이 주로 그래픽 프리미티브에 맞게 조정되었기 때문입니다. 즉, 사실 이 클래스는 프리미티브 외에는 아무것도 제공하지 않습니다. GUI 아키텍처는 스스로 구축해야 합니다. 그리고 이 경우 클래스는 선택 사항입니다. 스스로 결정을 내리는 것이 좋습니다. 결국 이 클래스 없이 직사각형 레이블을 그릴 수 있습니다. 캔버스를 생성하거나 업로드하는 방법. 아주 간단합니다. 따라서 나는 내 솔루션을 선호했습니다.
그러나 어떤 식으로든 CCCanvas가 없는 사람에게. 그러므로 나는 주장하지 않는다.
그가 무엇을 게시했고 GUI에서 무엇을 했는지는 모르지만 내 스레드에서 그는 단일 솔루션이 아니라 단일 기술 제안을 하지 않았으며 주제에 대한 토론을 주도하지 않았습니다. 제3자 솔루션을 가리키고 바퀴를 재발명하지 말라고 외치는 빈 트롤링만 있을 뿐입니다.
다시 주제로 돌아가자.
내가 표준 라이브러리에 대해 잘 아는 한(사실 거의 없음) 요소와 창은 MT 개체로 구성됩니다. 즉, 우리의 맥락에서 그것들은 캔버스에 그려지지 않습니다. 물론 그것들은 그려지지만 우리의 캔버스에는 그려지지 않기 때문에 픽셀 색상을 제어하고 표면 그라디언트를 만드는 등의 기능을 제공하지 않습니다.
이론적으로 라이브러리의 구조를 가져 와서 복사하고 캔버스에 아날로그를 만들 수 있습니다. 이론에 의하면...
문제는 Ccanvas 자체가 GUI를 만드는 데 편리하지 않다는 것입니다. 왜요? 캔버스 시스템이 주로 그래픽 프리미티브에 맞게 조정되었기 때문입니다. 즉, 사실 이 클래스는 프리미티브 외에는 아무것도 제공하지 않습니다. GUI 아키텍처는 스스로 구축해야 합니다. 그리고 이 경우 클래스는 선택 사항입니다. 스스로 결정을 내리는 것이 좋습니다. 결국 이 클래스 없이 직사각형 레이블을 그릴 수 있습니다. 캔버스를 생성하거나 업로드하는 방법. 아주 간단합니다. 따라서 나는 내 솔루션을 선호했습니다.
그러나 어떤 식으로든 CCCanvas가 없는 사람에게. 그러므로 나는 주장하지 않는다.
중지! 피터(맞나?), 서로 이해하기 위해 몇 가지 관례를 받아들이자. 규칙 1: 우리는 Canvas를 CCanvas 클래스가 아니라 단순히 화면의 일부 또는 특히 하나의 리소스를 그리기 위한 캔버스라고 부를 것입니다. CCanvas 클래스는 이 모든 것과 관련이 없으며 우리는 이에 대해 전혀 언급하지 않을 것입니다. 동일한 캔버스에 그리기 위한 기능만 제공하면 됩니다. 사실 우리는 다양한 방법으로 그림을 그릴 수 있습니다.
"그리기"라는 단어 는 리소스가 생성 되고 이후에 차트에 배치되는 기반으로 픽셀 배열의 형성을 의미합니다.
중지! 피터(맞나?), 서로 이해하기 위해 몇 가지 관례를 받아들이자. 규칙 1: 우리는 Canvas를 CCanvas 클래스가 아니라 단순히 화면의 일부 또는 특히 하나의 리소스를 그리기 위한 캔버스라고 부를 것입니다. CCanvas 클래스는 이 모든 것과 관련이 없으며 우리는 이에 대해 전혀 언급하지 않을 것입니다. 동일한 캔버스에 그리기 위한 기능만 제공하면 됩니다. 사실 우리는 다양한 방법으로 그림을 그릴 수 있습니다.
"그리기"라는 단어는 픽셀 배열의 형성을 의미하며, 이를 기반으로 리소스가 생성 되어 차트에 배치됩니다.
괜찮은.
Peter, 나는 아마도 당신에게 눈을 뜨고 Maxim에 대해 말할 것입니다. Maxim은 누구보다 이 주제에 익숙하며, 1년 반 전에 그는 모든 사람이 볼 수 있도록 마크업을 기반으로 합니다. 또한 GUI는 외부 환경에서 구축되었지만 프로그램(지표, 전문가)과 완전한 상호 작용을 했습니다.
맥심, 답장을 드려서 죄송합니다.
주제로 돌아가고 싶습니다. 나는 표준 라이브러리의 작업에 대한 한 기사에서 그림을 꺼냈습니다.
이 화면은 대화의 구성을 단순화한 형태로 보여줍니다.
이번 버전에서는 Border가 주 요소로 차트에 캔버스 객체를 생성하고 모든 부하직원이 그 위에 그림을 그립니다. 오히려 종속에 따라 그립니다.
닫기 버튼은 캡션에 그려지고 캡션은 테두리에 그려지며 여기에서 그려진 모든 요소와 함께 캔버스에 그려집니다.
물론 조금 다르지만 :-)
Python/Ruby/etc에서 GUI로 공유되는 Tk 그래픽이 있는 Tcl DLL(Tool Common Language)에 대한 인터페이스를 게시했습니다.
GUI를 얻는 것이 목표가 아니었습니다. 일종의 좋은 부작용입니다 :-)
tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ;
내 의견으로는 편리하고 가장 중요하게는 짧습니다 :-)
나는 아무도 동요하지 않습니다 - 나는 tcl / tk를 알고 사용합니다. 모범 사례를 공유했습니다(sourceforge atcl 참조)