네. 정확히. 엔진이 특정 GUI를 렌더링하고 작업하는 데 필요한 모든 정보입니다. 이제 엔진에 직접 설치하고 생성자가 인쇄하는 파일에서 로드 가능하게 만들 것입니다.
얼마나 복잡하고 혼란스러운지.
shaitan-boiler 사용자가 필요한 양식, 창 및 요소를 만든 후 #include를 사용하여 프로그램에 연결하기 위해 mqh 파일을 발행하도록 만드는 것이 더 쉽지 않을까요? 파일에는 이미 OnChartEvent() , OnTimer() , OnTick() 및 기타 연결 요소가 포함되어 있습니다. 그를 위해 필요한 조치를 처방하는 것만 남아 있습니다. 어쨌든 그는 처방해야하지만 동시에 마크 업 언어도 배워야합니다. 그래서 - 이 중 어느 것도 필요하지 않습니다 - 생성된 mqh-file에 필요한 것을 mql에 등록하고 기뻐합니다.
어떤 이유로 사용자가 이해하지 못하는 언어를 사용하여 마크업 언어를 만들고 연결하는 경로를 택했습니다. 이 결정은 mql 언어 사용자를 제품으로 끌어들이지 않을 것입니다.
사탄 보일러 사용자가 필요한 양식, 창 및 요소를 만든 후 #include를 사용하여 프로그램에 연결하기 위해 mqh 파일을 발행하도록 만드는 것이 더 쉽지 않을까요? 파일에는 이미 OnChartEvent(), OnTimer(), OnTick() 및 기타 연결 요소가 포함되어 있습니다. 그를 위해 필요한 조치를 처방하는 것만 남아 있습니다. 어쨌든 그는 처방해야하지만 동시에 마크 업 언어도 배워야합니다. 그래서 - 이 중 어느 것도 필요하지 않습니다 - 생성된 mqh-file에 필요한 것을 mql에 등록하고 기뻐합니다.
어떤 이유로 사용자가 이해하지 못하는 언어를 사용하여 마크업 언어를 만들고 연결하는 경로를 택했습니다. 이 결정은 mql 언어 사용자를 제품으로 끌어들이지 않을 것입니다.
그건 그렇고, 그렇습니다.
이것이 바로 내가 재컴파일할 때 가는 방식입니다. 사실, 기성품 MQH 파일을 만들지 않고 일반 텍스트 파일을 작성한 다음 초기화 절차 텍스트를 기본 모듈로 전송하지만 아이디어는 동일합니다.
Peter, 실제로 사용 방법을 기억해야 하는 설정 대신 기성 설정이 포함된 기성 MQH 파일이 생성된다면 사용자의 삶이 훨씬 쉬워질 것입니다!
인터페이스 요소에서 "눌림" "해제"로 메시지를 발송하는 많은 중첩 스위치가 있는 함수가 있는 파일을 생성합니다. 그곳의 사용자는 이벤트에 반응하여 운전합니다. 변경 편집된 인터페이스, 이제 이 파일은 무엇입니까?
예를 들어 사용자가 위의 패널을 두 개의 창으로 나누기 위해 수행해야 하는 작업의 양은 하나의 버튼에서, 두 번째 테이블에서(예를 들어, 닫힐 수 있고 화면에 표시되지 않도록) 수행해야 합니다. 그리고 예를 들어 일부 기둥은 장소를 변경합니다. 그냥 전형입니다 - 레이아웃을 만들고 사용하고 더 편안한 모양으로 변경했습니다.
무슨 설정을 말씀하시는지 이해가 안됩니다. 하지만, 나는 내가 할 수 있는 일을 할 것입니다.
OOP를 배우면 오래전에 했을 것입니다. 할 수 있는 것 뿐만 아니라 훨씬 더 많은 - 지금은 의심조차 하지 않는 거대한 창의성의 공간이 여러분 앞에 열릴 것입니다. 빠르고 고품질이며 전문적입니다. 그리고 당신은 수년간 부풀려진 당신의 모터를 부수고 있었습니다. 게다가 작성된 코드의 양이 자랑스럽다면 프로그래밍의 "인도인"입니다. 이것은 이름을 부르는 것이 아닙니다. 이 정의를 검색하기만 하면 됩니다. 이것은 여러분이 하는 일에 정확히 맞습니다. 천 줄의 코드를 작성할 수 있고 백 줄의 코드를 작성할 수 있으며 둘 다 그 안에 포함된 동일한 일련의 작업을 수행합니다. 그러나 부풀려진 코드를 변경하거나 추가하는 것은 부풀려지지 않은 코드보다 훨씬 어렵습니다. 그러나 당신은 쓰여진 줄의 수에 대해 자랑하는 것을 선호하며(Nikolai 코를 찔러서) 모든 것을 거대한 프로젝트 라고 부릅니다. 신의 아이처럼.
네. 정확히. 엔진이 특정 GUI를 렌더링하고 작업하는 데 필요한 모든 정보입니다. 이제 엔진에 직접 설치하고 생성자가 인쇄하는 파일에서 로드 가능하게 만들 것입니다.
얼마나 복잡하고 혼란스러운지.
shaitan-boiler 사용자가 필요한 양식, 창 및 요소를 만든 후 #include를 사용하여 프로그램에 연결하기 위해 mqh 파일을 발행하도록 만드는 것이 더 쉽지 않을까요? 파일에는 이미 OnChartEvent() , OnTimer() , OnTick() 및 기타 연결 요소가 포함되어 있습니다. 그를 위해 필요한 조치를 처방하는 것만 남아 있습니다. 어쨌든 그는 처방해야하지만 동시에 마크 업 언어도 배워야합니다. 그래서 - 이 중 어느 것도 필요하지 않습니다 - 생성된 mqh-file에 필요한 것을 mql에 등록하고 기뻐합니다.
어떤 이유로 사용자가 이해하지 못하는 언어를 사용하여 마크업 언어를 만들고 연결하는 경로를 택했습니다. 이 결정은 mql 언어 사용자를 제품으로 끌어들이지 않을 것입니다.
캠페인, 이 스레드의 기적을 바라보는 것 - 대부분의 정신적 노력은 사람이 바보로 남아 있는 경향이 있습니다.
그러나 이벤트에 있는 모든 사용자 지정 편집 바인딩도 재정의합니까?
GUI가 변경되자마자 사용자는 버튼을 누르고 새 파일을 인쇄합니다. 엔진은 새 커널을 로드하고 사용자 애플리케이션은 업데이트된 인터페이스 파일을 포함해야 합니다.
이 경우 하나의 파일만 교체하면 되고(연결 속성) 두 번째 파일은 다시 연결해야 합니다. 그러나 이전 파일에서 이미 작성된 코드를 복사할 수 있습니다.
중요한 것은 사람이 GUI를 결정하기 전에 연결 파일을 채우지 않는 것입니다. 새 창이 추가되면 거의 영향을 미치지 않습니다. 이전 창과 요소가 변경되면 프로그램에서 코드를 다시 실행해야 할 수 있습니다.
그것은 모두 생성자에 있습니다. KIB 코드가 작성되고 파일이 다시 컴파일됩니다.
생성자와 함께 작업하는 방법은 다음과 같습니다. https://www.mql5.com/en/blogs/post/717782
찾아보니.. 파일이름과 폴더이름이 유치한 바보같은 실수, 에디터에서도 처음 여는듯 작업을 하고...
그리고 내가 이해한 것은 이것이 생성자가 전혀 아니라는 것입니다. 시각적 생성자가 있는 줄 알았는데...
그리고 당신은 당신의 이 개념을 돌파구라고 부르나요? 어디에서?
얼마나 복잡하고 혼란스러운지.
사탄 보일러 사용자가 필요한 양식, 창 및 요소를 만든 후 #include를 사용하여 프로그램에 연결하기 위해 mqh 파일을 발행하도록 만드는 것이 더 쉽지 않을까요? 파일에는 이미 OnChartEvent(), OnTimer(), OnTick() 및 기타 연결 요소가 포함되어 있습니다. 그를 위해 필요한 조치를 처방하는 것만 남아 있습니다. 어쨌든 그는 처방해야하지만 동시에 마크 업 언어도 배워야합니다. 그래서 - 이 중 어느 것도 필요하지 않습니다 - 생성된 mqh-file에 필요한 것을 mql에 등록하고 기뻐합니다.
어떤 이유로 사용자가 이해하지 못하는 언어를 사용하여 마크업 언어를 만들고 연결하는 경로를 택했습니다. 이 결정은 mql 언어 사용자를 제품으로 끌어들이지 않을 것입니다.
그건 그렇고, 그렇습니다.
이것이 바로 내가 재컴파일할 때 가는 방식입니다. 사실, 기성품 MQH 파일을 만들지 않고 일반 텍스트 파일을 작성한 다음 초기화 절차 텍스트를 기본 모듈로 전송하지만 아이디어는 동일합니다.
Peter, 실제로 사용 방법을 기억해야 하는 설정 대신 기성 설정이 포함된 기성 MQH 파일이 생성된다면 사용자의 삶이 훨씬 쉬워질 것입니다!
그리고 당신은 당신의 이 개념을 돌파구라고 부르나요? 어디에서?
아르템, 당신은 틀렸습니다. 이것은 하나의 버튼으로 "전리품 자르기"(또는 최악의 경우 두 개의 버튼으로 하나 더 - "거대한 전리품 자르기")가 있는 기성 전문가 고문을 원하는 사람들에서 반자동 모드, 거래 시작, 동반 및 Peter의 시각적 구성 요소로 거래 마감!
그런 분들이 나온다면 정말 획기적인 일이 될 거라고 확신합니다.
나는 이것이 가능한지 의심스러울 뿐이다. 사람은 천성적으로 게으르고 손으로 거래(반자동도 가능)에는 많은 경험이 필요하지만 현지 보몽드는 어디서 얻나요?
그건 그렇고, 그렇습니다.
이것이 바로 내가 재컴파일할 때 가는 방식입니다. 사실, 기성품 MQH 파일을 만들지 않고 일반 텍스트 파일을 작성한 다음 초기화 절차 텍스트를 기본 모듈로 전송하지만 아이디어는 동일합니다.
Peter, 실제로 사용 방법을 기억해야 하는 설정 대신 기성 설정이 포함된 기성 MQH 파일이 생성된다면 사용자의 삶이 훨씬 쉬워질 것입니다!
무슨 설정을 말씀하시는지 이해가 안됩니다. 하지만, 나는 내가 할 수 있는 일을 할 것입니다.
더 자세히 설명하십시오.
문서가 없으므로 링크는 메모리에서 가져옵니다(스레드의 깊이에서 어딘가에 있음) :-)
인터페이스 요소에서 "눌림" "해제"로 메시지를 발송하는 많은 중첩 스위치가 있는 함수가 있는 파일을 생성합니다. 그곳의 사용자는 이벤트에 반응하여 운전합니다.
변경 편집된 인터페이스, 이제 이 파일은 무엇입니까?
예를 들어 사용자가 위의 패널을 두 개의 창으로 나누기 위해 수행해야 하는 작업의 양은 하나의 버튼에서, 두 번째 테이블에서(예를 들어, 닫힐 수 있고 화면에 표시되지 않도록) 수행해야 합니다.
그리고 예를 들어 일부 기둥은 장소를 변경합니다. 그냥 전형입니다 - 레이아웃을 만들고 사용하고 더 편안한 모양으로 변경했습니다.
무슨 설정을 말씀하시는지 이해가 안됩니다. 하지만, 나는 내가 할 수 있는 일을 할 것입니다.
결론은 모든 양식, 창, 시각적 요소를 빌드한 후 직접 컴파일용으로 미리 만들어진 MQL 파일이 생성된다는 것입니다.
내가 알기로는 이제 사용자는 모든 치수, 좌표, 들여쓰기를 직접 입력해야 합니다... 이것은 매우 힘들고 지루한 작업입니다. 자동화되면 좋을텐데 말이죠. 그 결과는 재컴파일할 준비가 된 MQH 파일이 됩니다.
무슨 설정을 말씀하시는지 이해가 안됩니다. 하지만, 나는 내가 할 수 있는 일을 할 것입니다.
OOP를 배우면 오래전에 했을 것입니다. 할 수 있는 것 뿐만 아니라 훨씬 더 많은 - 지금은 의심조차 하지 않는 거대한 창의성의 공간이 여러분 앞에 열릴 것입니다. 빠르고 고품질이며 전문적입니다.
그리고 당신은 수년간 부풀려진 당신의 모터를 부수고 있었습니다.
게다가 작성된 코드의 양이 자랑스럽다면 프로그래밍의 "인도인"입니다. 이것은 이름을 부르는 것이 아닙니다. 이 정의를 검색하기만 하면 됩니다. 이것은 여러분이 하는 일에 정확히 맞습니다.
천 줄의 코드를 작성할 수 있고 백 줄의 코드를 작성할 수 있으며 둘 다 그 안에 포함된 동일한 일련의 작업을 수행합니다. 그러나 부풀려진 코드를 변경하거나 추가하는 것은 부풀려지지 않은 코드보다 훨씬 어렵습니다. 그러나 당신은 쓰여진 줄의 수에 대해 자랑하는 것을 선호하며(Nikolai 코를 찔러서) 모든 것을 거대한 프로젝트 라고 부릅니다. 신의 아이처럼.