글쎄, 당신이 볼랜드를 기억한다면 그래픽 인터페이스는 비주얼 편집기에서 조립되고 패널에 컨트롤 레이아웃을 넣은 다음 핸들러를 작성합니다. ME에 비주얼 모드에서 레이아웃을 조합할 수 있는 그래픽 기능이 있다면 그래픽 애플리케이션의 구성을 크게 단순화할 것입니다. GUI 구축을 연구한 대부분의 현대 프로그래머는 시각적 그래픽 편집기에 익숙해져 있기 때문에 순수한 C 스타일 코드로 그래픽 응용 프로그램을 레이아웃하는 것은 누구에게도 관심이 없습니다. 이것은 이미 하드코어 C 스타일이기 때문입니다. 그래픽 응용 프로그램을 빌드하려면 시각적 편집기가 필요하며, 그러면 사람들이 그것을 연구하기 위해 끌릴 것이고 VS 또는 RadStudio에서 작업한 사람들은 일반적으로 시각적 편집기를 빠르게 마스터할 것입니다.
여기에 이미 MQL에 이러한 비주얼 편집기의 프로토타입이 있었습니다. 그러나 백성들은 산을 향하여 일어섰습니다. 그들은 말했다 - 당신은 무역에서 필요하지 않습니다.
일반적으로 그들은 최선을 다해 사기를 꺾었습니다. 그래서 사회에 정말 필요한 것이 무엇인지 모릅니다.
지금은 제가 틀렸을 수도 있지만, 저는 항상 ME가 사용자가 거래에 필요한 기능을 구현하기 위해 특별히 제공되었다고 생각했습니다. 무역이다!
그러나 이제 ME의 프로그래밍 깊이는 큐브를 "수집"하고 프로그래밍을 매우 진지하게 이해할 수 있어야 하는 영역으로 이동했습니다....
그리고 그것은 결국 무엇으로 이어지는가? 또한 고급 거래 도구는 숙련된 프로그래머만 사용할 수 있습니다!
즉, 프로그래머가 아니라면 거래에서 할 일이 없습니다 ... 그러나 그것은 터무니없는 것입니다 ...
ME는 부족한 기능을 채워주는 조수일 뿐입니다. 터미널 자체(다양한 마스터)에 구축하는 것이 더 정확합니다.
그리고 사실 ME는 이제 점점 더 많은 사용자의 지식을 요구하는 새로운 개발 환경으로 발전하고 있습니다.
이러한 결론을 바탕으로 시각화 도구가 필요하지만 프로그래밍에 대한 깊은 지식이 없는 사용자도 사용할 수 있어야 합니다.
이 접근 방식을 통해서만 수요가 있을 것입니다.
이것은 제 생각일 뿐 누구에게도 강요하지 않습니다.
CCanvas 클래스를 고려하면 그래픽 프리미티브를 그리기 위한 함수가 약 20개 있습니다. 사용자가 그것들을 모두 알고 있고 OOP 규칙과 구문을 알고 있다고 가정해 봅시다. 그러나 데이터를 가장 단순하게 시각화하기 전에는 이것이 너무 적습니다. 가장 단순한 컨트롤의 생성은 말할 것도 없고 버튼입니다. 즉, 캔버스에 프리미티브를 그리는 것은 비교적 쉽지만 시각화 또는 GUI를 생성할 때 이러한 프리미티브를 사용하는 것은 훨씬 더 어렵습니다. 그리고 여기서 지식 없이는 할 수 없지만 개발자의 재능 없이는 할 수 없습니다. 많은 사람들이 가지고 있습니까? 이것이 핵심 문제입니다.
Canvas 클래스의 잠재력을 사용하려면 그래픽 프리미티브를 더 복잡한 개체(컨트롤)로 결합하고, 해당 작업을 이벤트 모델에 연결하고, 함수와 연결을 작성하거나... 또는 디지털 데이터를 다양한 그래픽 곡선으로 변환할 수 있어야 합니다. ... 이것은 재능 있고 매우 열심히 일하는 사용자를 위한 작업입니다. 사실 - 사용자가 아니라 개발자입니다.
여기에 이미 MQL에 이러한 비주얼 편집기의 프로토타입이 있었습니다. 그러나 백성들은 산을 향하여 일어섰습니다. 그들은 말했다 - 당신은 무역에서 필요하지 않습니다.
일반적으로 그들은 최선을 다해 사기를 꺾었습니다. 그래서 사회에 정말 필요한 것이 무엇인지 모릅니다.
와, 프로토타입이 있습니다. 그렇다면 개발자는 커뮤니티에 대한 편협한 견해를 재고할 수 있습니까? 그리고 비주얼 모드 개발 계획을 재개합니다. 물론 실제로 매우 인기 있는 기회의 사기를 꺾는 것은 어쩐지 이상합니다. 결국, 지금은 C 스타일 로 그래픽 인터페이스를 조립하는 방법을 가르치는 곳이 거의 없습니다. 이제 모든 사람이 비주얼 모드가 있는 IDE에서 작업하는 방법을 배우게 되었으며 MT5는 오랫동안 단순한 거래 플랫폼을 넘어섰습니다. 그러면 그래픽 응용 프로그램을 구축하는 시각적 모드에 대한 수요가 매우 높을 것입니다. 솔직히 반대하시는 분들의 편협한 시각을 개발자들이 경청해서 놀랐습니다.
CCanvas 클래스를 고려하면 그래픽 프리미티브를 그리기 위한 함수가 약 20개 있습니다. 사용자가 그것들을 모두 알고 있고 OOP 규칙과 구문을 알고 있다고 가정해 보겠습니다. 그러나 데이터를 가장 단순하게 시각화하기 전에는 이것이 너무 적습니다. 가장 단순한 컨트롤의 생성은 말할 것도 없고 버튼입니다. 즉, 캔버스에 프리미티브를 그리는 것은 비교적 쉽지만 시각화 또는 GUI를 생성할 때 이러한 프리미티브를 사용하는 것은 훨씬 더 어렵습니다. 그리고 여기서 지식 없이는 할 수 없지만 개발자의 재능 없이는 할 수 없습니다. 많은 사람들이 가지고 있습니까? 이것이 핵심 문제입니다.
Canvas 클래스의 잠재력을 사용하려면 그래픽 프리미티브를 더 복잡한 개체(컨트롤)로 결합하고, 해당 작업을 이벤트 모델에 연결하고, 함수와 연결을 작성하거나... 또는 디지털 데이터를 다양한 그래픽 곡선으로 변환할 수 있어야 합니다. ... 이것은 재능 있고 매우 열심히 일하는 사용자를 위한 작업입니다. 사실 - 사용자가 아니라 개발자입니다.
피터, 당신은 올바른 말을합니다!
그래서 저는 OOP에 익숙하지 않은 프로그래머에게 직관적인 라이브러리를 만드는 데 찬성합니다.
이것은 GUI에만 적용되는 것이 아닙니다.
표준 라이브러리 와 Anatoly 라이브러리에서 간단한 형식을 조립하려면 머리를 부숴야 합니다! 정말로! 예제의 오른쪽이나 왼쪽으로 이동하면 아무 것도 작동하지 않습니다. 복잡한 내용을 이해해야 합니다.
물론 모든 언어에서 GUI는 라이브러리를 기반으로 하지만 필수적인 것이 하나 있습니다. 라이브러리의 핵심 수준에서 서로 완전히 "연결된" 초기 컨트롤 세트가 있으며 모든 기본 이벤트 핸들러는 "던져" 있으며 동작이나 보기를 변경하려는 경우에만 구독하는 것으로 남아 있습니다. .
사실, 표준 라이브러리의 아키텍처는 매우 사려깊고 보다 발전된 라이브러리의 기초로 사용될 수 있습니다.
와, 프로토타입이 있습니다. 그렇다면 개발자는 커뮤니티에 대한 편협한 견해를 재고할 수 있습니까? 그리고 비주얼 모드 개발 계획을 재개합니다. 물론 실제로 매우 인기 있는 기회의 사기를 꺾는 것은 어쩐지 이상합니다. 결국, 지금은 C 스타일로 그래픽 인터페이스를 조립하는 방법을 가르치는 곳이 거의 없습니다. 이제 모든 사람이 비주얼 모드가 있는 IDE에서 작업하는 방법을 배우게 되었으며 MT5는 오랫동안 단순한 거래 플랫폼을 넘어섰습니다. 그러면 그래픽 응용 프로그램을 구축하는 시각적 모드에 대한 수요가 매우 높을 것입니다. 솔직히 반대하시는 분들의 편협한 시각을 개발자들이 경청해서 놀랐습니다.
100%의 지표에는 가시성이 있고 80%의 고문은 가시성이 있고 20%의 스크립트는 놀라운 다른 요소가 있습니다. 좋든 싫든 모든 것에는 가시성이 있고 이에 대한 이해는 표면에 있다. 그러나 다른 개발 환경과의 통합으로 개발이 진행되고 있으며, 표면적으로는....
분명히 모든 두 번째 터미널 사용자는 python과 sql에 대해 묻습니다.
Roman, Peter, Nikolai... 터미널 개발자는 자신의 비전을 가지고 있으며 소프트웨어 제품의 저자이자 소유자입니다. ME와 단말기의 기능 개발은 전체적으로 마케팅 리서치를 기반으로 한다고 생각합니다. 그러나 아무도 우리가 이야기하는 것을 방해하지 않습니다. :)
100%의 지표에는 가시성이 있고 80%의 고문은 가시성이 있고 20%의 스크립트는 놀라운 다른 요소가 있습니다. 좋든 싫든 모든 것에는 가시성이 있고 이에 대한 이해는 표면에 있다. 그러나 다른 개발 환경과의 통합으로 개발이 진행되고 있으며, 표면적으로는....
분명히 모든 두 번째 터미널 사용자는 python과 sql에 대해 묻습니다.
Roman, Peter, Nikolai... 터미널 개발자는 자신의 비전을 가지고 있으며 소프트웨어 제품의 저자이자 소유자입니다. ME와 단말기의 기능 개발은 전체적으로 마케팅 리서치를 기반으로 한다고 생각합니다. 그러나 아무도 우리가 이야기하는 것을 방해하지 않습니다. :)
그런거야.
내 의견은 다음과 같습니다. 고문의 시각적 인터페이스를 사용하면 하나의 응용 프로그램에 전략을 축적할 수 있으며 이는 시장 판매에 부정적인 영향을 미칩니다. 모든 사람이 동적 전략 세트를 사용하여 Expert Advisor를 쉽게 만들 수 있다면(GUI에서 허용) 시장에서 유동적인 순환이 줄어들어 판매에 영향을 미칩니다. 1위는 자신의 내부에서 전략을 변경하고 통합하고 설정 또는 여러 조건에서만 다른 클론을 파괴하는 전문가가 차지합니다. 시장에 좋을까? 모르겠어. 하지만 어드바이저의 수준이 올라갈 것이고 창에서 그들을 보는 것은 훨씬 더 흥미로울 것입니다.
Реter Konow : 아마도 대부분의 사용자는 CCanvas, CGrafic 및 CCanvas3D가 작업하는 데 OOP 원칙 및 구문에 대한 지식이 필요한 클래스가 아니라 필요한 시각화를 제공하는 애플리케이션이 되기를 원할 것입니다. 단지 아는 것이 아니라 사실 - Nikolai가 하는 것처럼 자신의 시각화 시스템을 구축하는 것입니다.
클래스를 아는 것만으로는 충분하지 않습니다. "낮은" 수준에서 라이브러리에서 자신의 솔루션을 조합할 수 있어야 합니다. 스스로 개발자가 되어야 합니다. 그리고 이것은 사용자의 1%에게 주어집니다.
미리 만들어진 시각화 응용 프로그램이 제공되면 사용자는 더 이상 배울 필요가 없지만 더 많이 배울 것입니다.
그게 필요 할까? 모르겠어.
하나님, 여기서 알아야 할 OOP의 원리는 무엇입니까? 끝내고 목록에서 방법을 선택하시겠습니까?
글쎄, 당신이 볼랜드를 기억한다면 그래픽 인터페이스는 비주얼 편집기에서 조립되고 패널에 컨트롤 레이아웃을 넣은 다음 핸들러를 작성합니다. ME에 비주얼 모드에서 레이아웃을 조합하는 그래픽 기능이 있다면 그래픽 애플리케이션 의 구성이 크게 단순화될 것입니다. GUI 구축을 연구한 대부분의 현대 프로그래머는 시각적 그래픽 편집기에 익숙해져 있기 때문에 순수한 C 스타일 코드로 그래픽 응용 프로그램을 레이아웃하는 것은 누구에게도 관심이 없습니다. 이것은 이미 하드코어 C 스타일이기 때문입니다. 그래픽 응용 프로그램을 빌드하려면 시각적 편집기가 필요하며, 그러면 사람들이 그것을 연구하기 위해 끌릴 것이고 VS 또는 RadStudio에서 작업한 사람들은 일반적으로 시각적 편집기를 빠르게 마스터할 것입니다.
내 의견은 다음과 같습니다. 고문의 시각적 인터페이스를 사용하면 하나의 응용 프로그램에 전략을 축적할 수 있으며 이는 시장 판매에 부정적인 영향을 미칩니다. 모든 사람이 동적 전략 세트를 사용하여 Expert Advisor를 쉽게 만들 수 있다면(GUI에서 허용) 시장에서 유동적인 순환이 줄어들어 판매에 영향을 미칩니다. 1위는 자신의 내부에서 전략을 변경하고 통합하고 설정 또는 여러 조건에서만 다른 클론을 파괴하는 전문가가 차지합니다. 시장에 좋을까? 모르겠어. 하지만 어드바이저의 수준이 올라갈 것이고 창에서 그들을 보는 것은 훨씬 더 흥미로울 것입니다.
완전히 가짜 문제. 전략 수집을 위한 시각적 인터페이스는 불필요하며 큐브가 필요한 사람은 tslab에 있습니다. 예, 네트워크에서 비주얼 모드에서 큐브로 전략을 수집하는 mql 코드 생성 프로그램을 어떻게든 만났습니다. 거래 전략 및 지표를 개발하기 위해 시각적 모드는 필요하지 않으며 실제로는 필요하지 않습니다. 그러나 모듈식 그래픽 응용 프로그램의 경우 GIF에 표시된 것처럼 시각적 모드가 유용할 것입니다.
글쎄, 당신이 볼랜드를 기억한다면 그래픽 인터페이스는 비주얼 편집기에서 조립되고 패널에 컨트롤 레이아웃을 넣은 다음 핸들러를 작성합니다.
ME에 비주얼 모드에서 레이아웃을 조합할 수 있는 그래픽 기능이 있다면 그래픽 애플리케이션의 구성을 크게 단순화할 것입니다.
GUI 구축을 연구한 대부분의 현대 프로그래머는 시각적 그래픽 편집기에 익숙해져 있기 때문에
순수한 C 스타일 코드로 그래픽 응용 프로그램을 레이아웃하는 것은 누구에게도 관심이 없습니다. 이것은 이미 하드코어 C 스타일이기 때문입니다.
그래픽 응용 프로그램을 빌드하려면 시각적 편집기가 필요하며, 그러면 사람들이 그것을 연구하기 위해 끌릴 것이고 VS 또는 RadStudio에서 작업한 사람들은 일반적으로 시각적 편집기를 빠르게 마스터할 것입니다.
여기에 이미 MQL에 이러한 비주얼 편집기의 프로토타입이 있었습니다. 그러나 백성들은 산을 향하여 일어섰습니다. 그들은 말했다 - 당신은 무역에서 필요하지 않습니다.
일반적으로 그들은 최선을 다해 사기를 꺾었습니다. 그래서 사회에 정말 필요한 것이 무엇인지 모릅니다.
수집 능력이 필요하다는 점을 적극 지지합니다...
그것이 필요한지 아닌지는 다른 문제입니다.
개발자 자신이 터미널을 거래 도구 또는 프로그래밍 도구로 간주하는지 궁금합니다.
지금은 제가 틀렸을 수도 있지만, 저는 항상 ME가 사용자가 거래에 필요한 기능을 구현하기 위해 특별히 제공되었다고 생각했습니다. 무역이다!
그러나 이제 ME의 프로그래밍 깊이는 큐브를 "수집"하고 프로그래밍을 매우 진지하게 이해할 수 있어야 하는 영역으로 이동했습니다....
그리고 그것은 결국 무엇으로 이어지는가? 또한 고급 거래 도구는 숙련된 프로그래머만 사용할 수 있습니다!
즉, 프로그래머가 아니라면 거래에서 할 일이 없습니다 ... 그러나 그것은 터무니없는 것입니다 ...
ME는 부족한 기능을 채워주는 조수일 뿐입니다. 터미널 자체(다양한 마스터)에 구축하는 것이 더 정확합니다.
그리고 사실 ME는 이제 점점 더 많은 사용자의 지식을 요구하는 새로운 개발 환경으로 발전하고 있습니다.
이러한 결론을 바탕으로 시각화 도구가 필요하지만 프로그래밍에 대한 깊은 지식이 없는 사용자도 사용할 수 있어야 합니다.
이 접근 방식을 통해서만 수요가 있을 것입니다.
이것은 제 생각일 뿐 누구에게도 강요하지 않습니다.
CCanvas 클래스를 고려하면 그래픽 프리미티브를 그리기 위한 함수가 약 20개 있습니다. 사용자가 그것들을 모두 알고 있고 OOP 규칙과 구문을 알고 있다고 가정해 봅시다. 그러나 데이터를 가장 단순하게 시각화하기 전에는 이것이 너무 적습니다. 가장 단순한 컨트롤의 생성은 말할 것도 없고 버튼입니다. 즉, 캔버스에 프리미티브를 그리는 것은 비교적 쉽지만 시각화 또는 GUI를 생성할 때 이러한 프리미티브를 사용하는 것은 훨씬 더 어렵습니다. 그리고 여기서 지식 없이는 할 수 없지만 개발자의 재능 없이는 할 수 없습니다. 많은 사람들이 가지고 있습니까? 이것이 핵심 문제입니다.
Canvas 클래스의 잠재력을 사용하려면 그래픽 프리미티브를 더 복잡한 개체(컨트롤)로 결합하고, 해당 작업을 이벤트 모델에 연결하고, 함수와 연결을 작성하거나... 또는 디지털 데이터를 다양한 그래픽 곡선으로 변환할 수 있어야 합니다. ... 이것은 재능 있고 매우 열심히 일하는 사용자를 위한 작업입니다. 사실 - 사용자가 아니라 개발자입니다.
여기에 이미 MQL에 이러한 비주얼 편집기의 프로토타입이 있었습니다. 그러나 백성들은 산을 향하여 일어섰습니다. 그들은 말했다 - 당신은 무역에서 필요하지 않습니다.
일반적으로 그들은 최선을 다해 사기를 꺾었습니다. 그래서 사회에 정말 필요한 것이 무엇인지 모릅니다.
와, 프로토타입이 있습니다.
그렇다면 개발자는 커뮤니티에 대한 편협한 견해를 재고할 수 있습니까? 그리고 비주얼 모드 개발 계획을 재개합니다.
물론 실제로 매우 인기 있는 기회의 사기를 꺾는 것은 어쩐지 이상합니다.
결국, 지금은 C 스타일 로 그래픽 인터페이스를 조립하는 방법을 가르치는 곳이 거의 없습니다.
이제 모든 사람이 비주얼 모드가 있는 IDE에서 작업하는 방법을 배우게 되었으며 MT5는 오랫동안 단순한 거래 플랫폼을 넘어섰습니다.
그러면 그래픽 응용 프로그램을 구축하는 시각적 모드에 대한 수요가 매우 높을 것입니다.
솔직히 반대하시는 분들의 편협한 시각을 개발자들이 경청해서 놀랐습니다.
CCanvas 클래스를 고려하면 그래픽 프리미티브를 그리기 위한 함수가 약 20개 있습니다. 사용자가 그것들을 모두 알고 있고 OOP 규칙과 구문을 알고 있다고 가정해 보겠습니다. 그러나 데이터를 가장 단순하게 시각화하기 전에는 이것이 너무 적습니다. 가장 단순한 컨트롤의 생성은 말할 것도 없고 버튼입니다. 즉, 캔버스에 프리미티브를 그리는 것은 비교적 쉽지만 시각화 또는 GUI를 생성할 때 이러한 프리미티브를 사용하는 것은 훨씬 더 어렵습니다. 그리고 여기서 지식 없이는 할 수 없지만 개발자의 재능 없이는 할 수 없습니다. 많은 사람들이 가지고 있습니까? 이것이 핵심 문제입니다.
Canvas 클래스의 잠재력을 사용하려면 그래픽 프리미티브를 더 복잡한 개체(컨트롤)로 결합하고, 해당 작업을 이벤트 모델에 연결하고, 함수와 연결을 작성하거나... 또는 디지털 데이터를 다양한 그래픽 곡선으로 변환할 수 있어야 합니다. ... 이것은 재능 있고 매우 열심히 일하는 사용자를 위한 작업입니다. 사실 - 사용자가 아니라 개발자입니다.
피터, 당신은 올바른 말을합니다!
그래서 저는 OOP에 익숙하지 않은 프로그래머에게 직관적인 라이브러리를 만드는 데 찬성합니다.
이것은 GUI에만 적용되는 것이 아닙니다.
표준 라이브러리 와 Anatoly 라이브러리에서 간단한 형식을 조립하려면 머리를 부숴야 합니다! 정말로! 예제의 오른쪽이나 왼쪽으로 이동하면 아무 것도 작동하지 않습니다. 복잡한 내용을 이해해야 합니다.
물론 모든 언어에서 GUI는 라이브러리를 기반으로 하지만 필수적인 것이 하나 있습니다. 라이브러리의 핵심 수준에서 서로 완전히 "연결된" 초기 컨트롤 세트가 있으며 모든 기본 이벤트 핸들러는 "던져" 있으며 동작이나 보기를 변경하려는 경우에만 구독하는 것으로 남아 있습니다. .
사실, 표준 라이브러리의 아키텍처는 매우 사려깊고 보다 발전된 라이브러리의 기초로 사용될 수 있습니다.
와, 프로토타입이 있습니다.
그렇다면 개발자는 커뮤니티에 대한 편협한 견해를 재고할 수 있습니까? 그리고 비주얼 모드 개발 계획을 재개합니다.
물론 실제로 매우 인기 있는 기회의 사기를 꺾는 것은 어쩐지 이상합니다.
결국, 지금은 C 스타일로 그래픽 인터페이스를 조립하는 방법을 가르치는 곳이 거의 없습니다.
이제 모든 사람이 비주얼 모드가 있는 IDE에서 작업하는 방법을 배우게 되었으며 MT5는 오랫동안 단순한 거래 플랫폼을 넘어섰습니다.
그러면 그래픽 응용 프로그램을 구축하는 시각적 모드에 대한 수요가 매우 높을 것입니다.
솔직히 반대하시는 분들의 편협한 시각을 개발자들이 경청해서 놀랐습니다.
100%의 지표에는 가시성이 있고 80%의 고문은 가시성이 있고 20%의 스크립트는 놀라운 다른 요소가 있습니다. 좋든 싫든 모든 것에는 가시성이 있고 이에 대한 이해는 표면에 있다. 그러나 다른 개발 환경과의 통합으로 개발이 진행되고 있으며, 표면적으로는....
분명히 모든 두 번째 터미널 사용자는 python과 sql에 대해 묻습니다.
Roman, Peter, Nikolai... 터미널 개발자는 자신의 비전을 가지고 있으며 소프트웨어 제품의 저자이자 소유자입니다. ME와 단말기의 기능 개발은 전체적으로 마케팅 리서치를 기반으로 한다고 생각합니다.
그러나 아무도 우리가 이야기하는 것을 방해하지 않습니다. :)
100%의 지표에는 가시성이 있고 80%의 고문은 가시성이 있고 20%의 스크립트는 놀라운 다른 요소가 있습니다. 좋든 싫든 모든 것에는 가시성이 있고 이에 대한 이해는 표면에 있다. 그러나 다른 개발 환경과의 통합으로 개발이 진행되고 있으며, 표면적으로는....
분명히 모든 두 번째 터미널 사용자는 python과 sql에 대해 묻습니다.
Roman, Peter, Nikolai... 터미널 개발자는 자신의 비전을 가지고 있으며 소프트웨어 제품의 저자이자 소유자입니다. ME와 단말기의 기능 개발은 전체적으로 마케팅 리서치를 기반으로 한다고 생각합니다.
그러나 아무도 우리가 이야기하는 것을 방해하지 않습니다. :)
그런거야.
내 의견은 다음과 같습니다. 고문의 시각적 인터페이스를 사용하면 하나의 응용 프로그램에 전략을 축적할 수 있으며 이는 시장 판매에 부정적인 영향을 미칩니다. 모든 사람이 동적 전략 세트를 사용하여 Expert Advisor를 쉽게 만들 수 있다면(GUI에서 허용) 시장에서 유동적인 순환이 줄어들어 판매에 영향을 미칩니다. 1위는 자신의 내부에서 전략을 변경하고 통합하고 설정 또는 여러 조건에서만 다른 클론을 파괴하는 전문가가 차지합니다. 시장에 좋을까? 모르겠어. 하지만 어드바이저의 수준이 올라갈 것이고 창에서 그들을 보는 것은 훨씬 더 흥미로울 것입니다.
아마도 대부분의 사용자는 CCanvas, CGrafic 및 CCanvas3D가 작업하는 데 OOP 원칙 및 구문에 대한 지식이 필요한 클래스가 아니라 필요한 시각화를 제공하는 애플리케이션이 되기를 원할 것입니다. 단지 아는 것이 아니라 사실 - Nikolai가 하는 것처럼 자신의 시각화 시스템을 구축하는 것입니다.
하나님, 여기서 알아야 할 OOP의 원리는 무엇입니까? 끝내고 목록에서 방법을 선택하시겠습니까?
반론: 총 수에서 "가장 강력하고" "가장 단순한" MQL이 얼마나 많은 기능을 하는지
모든 기능을 완벽하게 갖추고 잠재적으로 가장 수익성이 높은 Expert Advisor를 작성하기에 충분합니다.
세계의 주요 통화 쌍에서?
그리고 여기있는 모든 사람들이 머리를 잃은 R 또는 Python의 어떤 기능이 쓰기에 충분합니까? .. 그리고보세요, 당신이 앉아있는 의자는 무엇에 적합합니까? ...
글쎄, 당신이 볼랜드를 기억한다면 그래픽 인터페이스는 비주얼 편집기에서 조립되고 패널에 컨트롤 레이아웃을 넣은 다음 핸들러를 작성합니다.
ME에 비주얼 모드에서 레이아웃을 조합하는 그래픽 기능이 있다면 그래픽 애플리케이션 의 구성이 크게 단순화될 것입니다.
GUI 구축을 연구한 대부분의 현대 프로그래머는 시각적 그래픽 편집기에 익숙해져 있기 때문에
순수한 C 스타일 코드로 그래픽 응용 프로그램을 레이아웃하는 것은 누구에게도 관심이 없습니다. 이것은 이미 하드코어 C 스타일이기 때문입니다.
그래픽 응용 프로그램을 빌드하려면 시각적 편집기가 필요하며, 그러면 사람들이 그것을 연구하기 위해 끌릴 것이고 VS 또는 RadStudio에서 작업한 사람들은 일반적으로 시각적 편집기를 빠르게 마스터할 것입니다.
그들은 왜 여기에 필요합니까?
그런거야.
내 의견은 다음과 같습니다. 고문의 시각적 인터페이스를 사용하면 하나의 응용 프로그램에 전략을 축적할 수 있으며 이는 시장 판매에 부정적인 영향을 미칩니다. 모든 사람이 동적 전략 세트를 사용하여 Expert Advisor를 쉽게 만들 수 있다면(GUI에서 허용) 시장에서 유동적인 순환이 줄어들어 판매에 영향을 미칩니다. 1위는 자신의 내부에서 전략을 변경하고 통합하고 설정 또는 여러 조건에서만 다른 클론을 파괴하는 전문가가 차지합니다. 시장에 좋을까? 모르겠어. 하지만 어드바이저의 수준이 올라갈 것이고 창에서 그들을 보는 것은 훨씬 더 흥미로울 것입니다.
완전히 가짜 문제.
전략 수집을 위한 시각적 인터페이스는 불필요하며 큐브가 필요한 사람은 tslab에 있습니다.
예, 네트워크에서 비주얼 모드에서 큐브로 전략을 수집하는 mql 코드 생성 프로그램을 어떻게든 만났습니다.
거래 전략 및 지표를 개발하기 위해 시각적 모드는 필요하지 않으며 실제로는 필요하지 않습니다.
그러나 모듈식 그래픽 응용 프로그램의 경우 GIF에 표시된 것처럼 시각적 모드가 유용할 것입니다.