전적으로. MQL로 나만의 GUI 프레임워크를 만드는 데 몇 달이 걸렸습니다. 과거에 이와 같은 라이브러리를 만든 경험을 계산하지 않은 것입니다. 가장 어려운 부분은 이벤트가 아니라 모든 중첩 및 재귀로 인해 아키텍처가 더 많고 코드를 디버그하는 것이 거의 불가능할 뿐만 아니라 디버깅이 시작될 때 이미 유효하지 않은 마우스 상태 때문입니다.
그건 그렇고, 나는 몇 달 전에 이 라이브러리를 사용하여 MQ에 협력을 제안했지만 불행히도 답변을 얻지 못했습니다. 그러나 사실, 표준 제어 라이브러리는 실제로 가능한 것에 비해 훌륭하지만 나쁜 시도입니다. 하나는 훨씬 더 잘할 수 있습니다. 여기 시장에서 도서관을 제공해야 할 수도 있지만 전체 문서를 작성하는 데 많은 노력이 필요합니다.
Doerk Hilger : 이것은 전혀 질문이 아닙니다. OOP는 자연의 원리를 기반으로 합니다. 지구는 당신을 먹여 살리는 것이 아니라, 당신이 필요로 하는 것이라면, 언제 어디서 무엇을 필요로 하는지 당신에게 달려 있습니다.
그게 무슨 말인지 말할 수 있습니까? 나는 당신이 말하는 것에 대한 일반적인 느낌을 받지만 명확하지 않습니다. 프레임워크를 만들 때 리소스 제공에만 신경을 쓴다는 뜻인가요? 이해는 하지만 성향이 너무 강해서 어떻게든 연습하기가 어렵다.
예를 들어 프레임워크를 만들고 버튼과 일종의 버튼 컨테이너인 라디오 버튼을 만드는 경우 - 라디오 버튼을 만들 때 내 경향은 종속 개체, 이 경우 버튼에 대해 생각하는 것입니다. , 그리고 내가 그것과 어떻게 소통하는지. 이것은 절차적 프로그래밍 습관입니다. 과거에 절차적 프로그래밍에서 OO로 전환한 적이 있는지 궁금합니다. 이 경우에 중점을 두어야 할 사항에 대한 명확한 견해를 알려줄 수 있습니다. 라디오 버튼보다 버튼(종속 객체)에 더 집중하는 경향이 있기 때문입니다.
명확히 했는지는 모르겠지만 프레임워크에서 레벨을 생성할 때 집중해야 할 중요한 사항을 지적하는 것에 대한 질문일 뿐입니다.
Amir Yacoby : 그게 무슨 말인지 말할 수 있습니까? 나는 당신이 말하는 것에 대한 일반적인 느낌을 갖지만 명확하지 않습니다. 프레임워크를 만들 때 리소스 제공에만 신경을 쓴다는 뜻인가요? 이해는 하지만 성향이 너무 강해서 어떻게든 연습하기가 어렵다.
예를 들어 프레임워크를 만들고 버튼과 일종의 버튼 컨테이너인 라디오 버튼을 만드는 경우 - 라디오 버튼을 만들 때 내 경향은 종속 개체, 이 경우 버튼에 대해 생각하는 것입니다. , 그리고 내가 그것과 어떻게 소통하는지. 이것은 절차적 프로그래밍 습관입니다. 과거에 절차적 프로그래밍에서 OO로 전환한 적이 있는지 궁금합니다. 이 경우에 중점을 두어야 할 사항에 대한 명확한 견해를 알려줄 수 있습니다. 라디오 버튼보다 버튼(종속 객체)에 더 집중하는 경향이 있기 때문입니다.
명확히 했는지는 모르겠지만 프레임워크에서 레벨을 생성할 때 집중해야 할 중요한 사항을 지적하는 것에 대한 질문일 뿐입니다.
제가 요점을 놓쳤을 수도 있지만 제 의견을 말씀드리고 싶습니다.
나는 당신이 "이론"에 너무 집착하고 다른 사람의 빛을 기다리고 있다고 생각합니다. 완벽한 솔루션은 없으며 솔루션이 있으며 경험과 구체적인 요구 사항에서 찾아야 합니다.
이 주제는 실제 사례에서 시작되었으며 OOP에 대한 모호한 토론이 된 것으로 알고 있습니다. GUI에 대한 흥미로운 기사 시리즈 가 있습니다. 한 번 살펴보고 표준 라이브러리를 사용하여 인터페이스를 구축하고 이 기사의 라이브러리를 사용하고 코드를 연구해야 합니다.
나는 당신이 훨씬 더 나은 도움을받을 수있는 방법을 정말로 알지 못하기 때문에 단지 제안입니다.
This article is the beginning of another series concerning development of graphical interfaces. Currently, there is not a single code library that would allow quick and easy creation of high quality graphical interfaces within MQL applications. By that, I mean the graphical interfaces that we are used to in familiar operating systems.
나는 당신이 "이론"에 너무 집착하고 다른 사람의 빛을 기다리고 있다고 생각합니다. 완벽한 솔루션은 없으며 솔루션이 있으며 경험과 구체적인 요구 사항에서 찾아야 합니다.
이 주제는 실제 사례에서 시작되었으며 OOP에 대한 모호한 토론이 된 것으로 알고 있습니다. GUI에 대한 흥미로운 기사 시리즈 가 있습니다. 한 번 살펴보고 표준 라이브러리를 사용하여 인터페이스를 구축하고 이 기사의 라이브러리를 사용하고 코드를 연구해야 합니다.
나는 당신이 훨씬 더 나은 도움을받을 수있는 방법을 정말로 알지 못하기 때문에 단지 제안입니다.
Alain, 인터페이스를 구축하고 기사를 읽었습니다. 어쩌면 OO에 대해 이야기하는 곳이 아닐 수도 있습니다. 당신이 옳을 수도 있습니다. Doerk가 토픽 초보자에 대한 응답으로 토픽을 제시하고 올바른 OO 접근 방식에 대해 이야기했기 때문에 토론을 시작했습니다. 토픽 초심자 본인도 Doerk의 OO 프레젠테이션에 관심이 있었고, 여기서 논의하는 것이 당연하다고 생각합니다. 너무 이론적일 수도 있다는 당신의 생각이 옳을 수도 있지만, 여전히 올바른 OO는 어떤 이론을 포함하지 않고는 불가능하고 결국에는 실용적이 될 수 있다는 것이 제 생각입니다.
내 어려움은 OO 올바른 생각입니다. 우연히 Doerk가 자신의 경험을 통해 내가 제시한 정신적 어려움을 알 수 있을지 궁금했습니다.
GUI에 대한 흥미로운 기사 시리즈 가 있습니다. 한 번 살펴보고 표준 라이브러리를 사용하여 인터페이스를 구축하고 이 기사의 라이브러리를 사용하고 코드를 연구해야 합니다.
나는 그것이 무엇을하는지보기 위해 그것을 다운로드했습니다. 그리고 첫인상은 그들이 표준 제어 라이브러리에서 했던 것과 같은 나쁜 실수를 저질렀다는 것입니다. 하나의 대화 상자 창이 있는 첫 번째 예는 이미 CPU 사용량을 10%(미포함)에서 50-65%(로드됨)로 높입니다. 이것은 이미 저자가 그러한 라이브러리를 개발하는 데 필요한 경험이 없고 이것이 올바른 방법이 될 수 없다는 가장 좋은 증거입니다.
나는 MQ가 어떻게 수행되었는지 설명하는 대신 전문 GUI 프레임워크를 제공하지 않는 이유를 어쨌든 이해하지 못합니다. 대부분의 MQL 프로그래머는 확실히 EA와 지표를 개발하기를 원하지만 그런 것들을 귀찮게 하고 싶지는 않습니다.
게다가, 그들의 예제 패널은 전략 테스터에서 죽었고, 여기에서 그러한 모든 GUI 항목이 어쨌든 터무니없게 됩니다. 이것은 당신이나 당신이 쓴 것에 대한 비판이 아닙니다. 여기에 MQL에 대해 더 나은 공개 자료가 없다는 것을 스스로 알고 있습니다.
Alain, 인터페이스를 구축하고 기사를 읽었습니다. 어쩌면 OO에 대해 이야기하는 곳이 아닐 수도 있습니다. 당신이 옳을 수도 있습니다. Doerk가 토픽 초보자에 대한 응답으로 토픽을 제시하고 올바른 OO 접근 방식에 대해 이야기했기 때문에 토론을 시작했습니다. 토픽 초심자 본인도 Doerk의 OO 프레젠테이션에 관심이 있었고, 여기서 논의하는 것이 당연하다고 생각합니다. 너무 이론적일 수도 있다는 당신의 생각이 옳을 수도 있지만, 여전히 올바른 OO는 어떤 이론을 포함하지 않고는 불가능하고 결국에는 실용적이 될 수 있다는 것이 제 생각입니다.
내 어려움은 OO 올바른 생각입니다. 우연히 Doerk가 자신의 경험을 통해 내가 제시한 정신적 어려움을 알 수 있을지 궁금했습니다.
여기서 OOP를 논의하는 데 문제가 없습니다.
나는 당신의 "OO는 어떤 이론을 포함하지 않고는 할 수 없다"는 것에 동의하지 않지만 그것은 중요하지 않습니다.
나는 그것이 무엇을하는지보기 위해 그것을 다운로드했습니다. 그리고 첫인상은 그들이 표준 제어 라이브러리에서 했던 것과 같은 나쁜 실수를 저질렀다는 것입니다. 하나의 대화 상자 창이 있는 첫 번째 예는 이미 CPU 사용량을 10%(미포함)에서 50-65%(로드됨)로 높입니다. 이것은 이미 저자가 그러한 라이브러리를 개발하는 데 필요한 경험이 없고 이것이 올바른 방법이 될 수 없다는 가장 좋은 증거입니다.
나는 MQ가 어떻게 수행되었는지 설명하는 대신 전문 GUI 프레임워크를 제공하지 않는 이유를 어쨌든 이해하지 못합니다. 대부분의 MQL 프로그래머는 확실히 EA와 지표를 개발하기를 원하지만 그런 것들을 귀찮게 하고 싶지는 않습니다.
게다가, 그들의 예제 패널은 전략 테스터에서 죽었고, 여기에서 그러한 모든 GUI 항목이 어쨌든 터무니없게 됩니다. 이것은 당신이나 당신이 쓴 것에 대한 비판이 아닙니다. 여기에 MQL에 대해 더 나은 공개 자료가 없다는 것을 스스로 알고 있습니다.
Doerk, 당신이 가장 옳을 것입니다. 그러나 그것은 제 요점이 아닙니다.
이 CPU 문제가 발생하는 구체적인 예를 작성하고 문제가 무엇인지 Anatoli(기사 작성자)에게 설명해야 합니다. 유감스럽게도 지금까지 당신이 말한 모든 것은 당신이 100% 옳다 할지라도 거의 쓸모가 없습니다. 너무 일반적이고 이론적입니다. 범죄가 없습니다.
문제는 이 문제가 너무 복잡해서 정확한 지시를 내릴 수 없다는 것입니다. 그리고 그것이 내가 관심 있는 사람들에게 몇 가지 아이디어와 가능한 방법을 제공하려고 노력하는 이유입니다. 불행히도 나는 기사를 작성하거나 완전히 문서화된 라이브러리를 출판할 시간이 없습니다. 죄송합니다.
Doerk Hilger : 문제는 이 문제가 너무 복잡해서 정확한 지시를 내릴 수 없다는 것입니다. 그리고 그것이 내가 관심 있는 사람들에게 몇 가지 아이디어와 가능한 방법을 제공하려고 노력하는 이유입니다. 불행히도 나는 기사를 작성하거나 완전히 문서화된 라이브러리를 출판할 시간이 없습니다. 죄송합니다.
전적으로. MQL로 나만의 GUI 프레임워크를 만드는 데 몇 달이 걸렸습니다. 과거에 이와 같은 라이브러리를 만든 경험을 계산하지 않은 것입니다. 가장 어려운 부분은 이벤트가 아니라 모든 중첩 및 재귀로 인해 아키텍처가 더 많고 코드를 디버그하는 것이 거의 불가능할 뿐만 아니라 디버깅이 시작될 때 이미 유효하지 않은 마우스 상태 때문입니다.
그건 그렇고, 나는 몇 달 전에 이 라이브러리를 사용하여 MQ에 협력을 제안했지만 불행히도 답변을 얻지 못했습니다. 그러나 사실, 표준 제어 라이브러리는 실제로 가능한 것에 비해 훌륭하지만 나쁜 시도입니다. 하나는 훨씬 더 잘할 수 있습니다. 여기 시장에서 도서관을 제공해야 할 수도 있지만 전체 문서를 작성하는 데 많은 노력이 필요합니다.
이것은 전혀 질문이 아닙니다. OOP는 자연의 원리를 기반으로 합니다. 지구는 당신을 먹여 살리는 것이 아니라, 당신이 필요로 하는 것이라면, 언제 어디서 무엇을 필요로 하는지 당신에게 달려 있습니다.
프레임워크를 만들 때 리소스 제공에만 신경을 쓴다는 뜻인가요? 이해는 하지만 성향이 너무 강해서 어떻게든 연습하기가 어렵다.
예를 들어 프레임워크를 만들고 버튼과 일종의 버튼 컨테이너인 라디오 버튼을 만드는 경우 - 라디오 버튼을 만들 때 내 경향은 종속 개체, 이 경우 버튼에 대해 생각하는 것입니다. , 그리고 내가 그것과 어떻게 소통하는지. 이것은 절차적 프로그래밍 습관입니다. 과거에 절차적 프로그래밍에서 OO로 전환한 적이 있는지 궁금합니다. 이 경우에 중점을 두어야 할 사항에 대한 명확한 견해를 알려줄 수 있습니다. 라디오 버튼보다 버튼(종속 객체)에 더 집중하는 경향이 있기 때문입니다.
명확히 했는지는 모르겠지만 프레임워크에서 레벨을 생성할 때 집중해야 할 중요한 사항을 지적하는 것에 대한 질문일 뿐입니다.
그게 무슨 말인지 말할 수 있습니까? 나는 당신이 말하는 것에 대한 일반적인 느낌을 갖지만 명확하지 않습니다.
프레임워크를 만들 때 리소스 제공에만 신경을 쓴다는 뜻인가요? 이해는 하지만 성향이 너무 강해서 어떻게든 연습하기가 어렵다.
예를 들어 프레임워크를 만들고 버튼과 일종의 버튼 컨테이너인 라디오 버튼을 만드는 경우 - 라디오 버튼을 만들 때 내 경향은 종속 개체, 이 경우 버튼에 대해 생각하는 것입니다. , 그리고 내가 그것과 어떻게 소통하는지. 이것은 절차적 프로그래밍 습관입니다. 과거에 절차적 프로그래밍에서 OO로 전환한 적이 있는지 궁금합니다. 이 경우에 중점을 두어야 할 사항에 대한 명확한 견해를 알려줄 수 있습니다. 라디오 버튼보다 버튼(종속 객체)에 더 집중하는 경향이 있기 때문입니다.
명확히 했는지는 모르겠지만 프레임워크에서 레벨을 생성할 때 집중해야 할 중요한 사항을 지적하는 것에 대한 질문일 뿐입니다.
제가 요점을 놓쳤을 수도 있지만 제 의견을 말씀드리고 싶습니다.
나는 당신이 "이론"에 너무 집착하고 다른 사람의 빛을 기다리고 있다고 생각합니다. 완벽한 솔루션은 없으며 솔루션이 있으며 경험과 구체적인 요구 사항에서 찾아야 합니다.
이 주제는 실제 사례에서 시작되었으며 OOP에 대한 모호한 토론이 된 것으로 알고 있습니다. GUI에 대한 흥미로운 기사 시리즈 가 있습니다. 한 번 살펴보고 표준 라이브러리를 사용하여 인터페이스를 구축하고 이 기사의 라이브러리를 사용하고 코드를 연구해야 합니다.
나는 당신이 훨씬 더 나은 도움을받을 수있는 방법을 정말로 알지 못하기 때문에 단지 제안입니다.
제가 요점을 놓쳤을 수도 있지만 제 의견을 말씀드리고 싶습니다.
나는 당신이 "이론"에 너무 집착하고 다른 사람의 빛을 기다리고 있다고 생각합니다. 완벽한 솔루션은 없으며 솔루션이 있으며 경험과 구체적인 요구 사항에서 찾아야 합니다.
이 주제는 실제 사례에서 시작되었으며 OOP에 대한 모호한 토론이 된 것으로 알고 있습니다. GUI에 대한 흥미로운 기사 시리즈 가 있습니다. 한 번 살펴보고 표준 라이브러리를 사용하여 인터페이스를 구축하고 이 기사의 라이브러리를 사용하고 코드를 연구해야 합니다.
나는 당신이 훨씬 더 나은 도움을받을 수있는 방법을 정말로 알지 못하기 때문에 단지 제안입니다.
Alain, 인터페이스를 구축하고 기사를 읽었습니다.
어쩌면 OO에 대해 이야기하는 곳이 아닐 수도 있습니다. 당신이 옳을 수도 있습니다.
Doerk가 토픽 초보자에 대한 응답으로 토픽을 제시하고 올바른 OO 접근 방식에 대해 이야기했기 때문에 토론을 시작했습니다.
토픽 초심자 본인도 Doerk의 OO 프레젠테이션에 관심이 있었고, 여기서 논의하는 것이 당연하다고 생각합니다.
너무 이론적일 수도 있다는 당신의 생각이 옳을 수도 있지만, 여전히 올바른 OO는 어떤 이론을 포함하지 않고는 불가능하고 결국에는 실용적이 될 수 있다는 것이 제 생각입니다.
내 어려움은 OO 올바른 생각입니다. 우연히 Doerk가 자신의 경험을 통해 내가 제시한 정신적 어려움을 알 수 있을지 궁금했습니다.
GUI에 대한 흥미로운 기사 시리즈 가 있습니다. 한 번 살펴보고 표준 라이브러리를 사용하여 인터페이스를 구축하고 이 기사의 라이브러리를 사용하고 코드를 연구해야 합니다.
나는 그것이 무엇을하는지보기 위해 그것을 다운로드했습니다. 그리고 첫인상은 그들이 표준 제어 라이브러리에서 했던 것과 같은 나쁜 실수를 저질렀다는 것입니다. 하나의 대화 상자 창이 있는 첫 번째 예는 이미 CPU 사용량을 10%(미포함)에서 50-65%(로드됨)로 높입니다. 이것은 이미 저자가 그러한 라이브러리를 개발하는 데 필요한 경험이 없고 이것이 올바른 방법이 될 수 없다는 가장 좋은 증거입니다.
나는 MQ가 어떻게 수행되었는지 설명하는 대신 전문 GUI 프레임워크를 제공하지 않는 이유를 어쨌든 이해하지 못합니다. 대부분의 MQL 프로그래머는 확실히 EA와 지표를 개발하기를 원하지만 그런 것들을 귀찮게 하고 싶지는 않습니다.
게다가, 그들의 예제 패널은 전략 테스터에서 죽었고, 여기에서 그러한 모든 GUI 항목이 어쨌든 터무니없게 됩니다. 이것은 당신이나 당신이 쓴 것에 대한 비판이 아닙니다. 여기에 MQL에 대해 더 나은 공개 자료가 없다는 것을 스스로 알고 있습니다.
Alain, 인터페이스를 구축하고 기사를 읽었습니다.
어쩌면 OO에 대해 이야기하는 곳이 아닐 수도 있습니다. 당신이 옳을 수도 있습니다.
Doerk가 토픽 초보자에 대한 응답으로 토픽을 제시하고 올바른 OO 접근 방식에 대해 이야기했기 때문에 토론을 시작했습니다.
토픽 초심자 본인도 Doerk의 OO 프레젠테이션에 관심이 있었고, 여기서 논의하는 것이 당연하다고 생각합니다.
너무 이론적일 수도 있다는 당신의 생각이 옳을 수도 있지만, 여전히 올바른 OO는 어떤 이론을 포함하지 않고는 불가능하고 결국에는 실용적이 될 수 있다는 것이 제 생각입니다.
내 어려움은 OO 올바른 생각입니다. 우연히 Doerk가 자신의 경험을 통해 내가 제시한 정신적 어려움을 알 수 있을지 궁금했습니다.
여기서 OOP를 논의하는 데 문제가 없습니다.
나는 당신의 "OO는 어떤 이론을 포함하지 않고는 할 수 없다"는 것에 동의하지 않지만 그것은 중요하지 않습니다.
여기서 OOP를 논의하는 데 문제가 없습니다.
나는 당신의 "OO는 어떤 이론을 포함하지 않고는 할 수 없다"는 것에 동의하지 않지만 그것은 중요하지 않습니다.
나는 그것이 무엇을하는지보기 위해 그것을 다운로드했습니다. 그리고 첫인상은 그들이 표준 제어 라이브러리에서 했던 것과 같은 나쁜 실수를 저질렀다는 것입니다. 하나의 대화 상자 창이 있는 첫 번째 예는 이미 CPU 사용량을 10%(미포함)에서 50-65%(로드됨)로 높입니다. 이것은 이미 저자가 그러한 라이브러리를 개발하는 데 필요한 경험이 없고 이것이 올바른 방법이 될 수 없다는 가장 좋은 증거입니다.
나는 MQ가 어떻게 수행되었는지 설명하는 대신 전문 GUI 프레임워크를 제공하지 않는 이유를 어쨌든 이해하지 못합니다. 대부분의 MQL 프로그래머는 확실히 EA와 지표를 개발하기를 원하지만 그런 것들을 귀찮게 하고 싶지는 않습니다.
게다가, 그들의 예제 패널은 전략 테스터에서 죽었고, 여기에서 그러한 모든 GUI 항목이 어쨌든 터무니없게 됩니다. 이것은 당신이나 당신이 쓴 것에 대한 비판이 아닙니다. 여기에 MQL에 대해 더 나은 공개 자료가 없다는 것을 스스로 알고 있습니다.
Doerk, 당신이 가장 옳을 것입니다. 그러나 그것은 제 요점이 아닙니다.
이 CPU 문제가 발생하는 구체적인 예를 작성하고 문제가 무엇인지 Anatoli(기사 작성자)에게 설명해야 합니다. 유감스럽게도 지금까지 당신이 말한 모든 것은 당신이 100% 옳다 할지라도 거의 쓸모가 없습니다. 너무 일반적이고 이론적입니다. 범죄가 없습니다.
문제는 이 문제가 너무 복잡해서 정확한 지시를 내릴 수 없다는 것입니다. 그리고 그것이 내가 관심 있는 사람들에게 몇 가지 아이디어와 가능한 방법을 제공하려고 노력하는 이유입니다. 불행히도 나는 기사를 작성하거나 완전히 문서화된 라이브러리를 출판할 시간이 없습니다. 죄송합니다.