1. 비트맵의 인터페이스가 빠릅니다. 너무 빨라서 시스템 1과 거의 구별할 수 없습니다. 예를 들어, 그라디언트를 사용하여 반투명 요소를 구현 했으며 이동하는 경우에도 색상 혼합을 고려하고 반투명 그라디언트가 있는 다른 개체의 알파 채널을 계산하여 눈에 보이는 지연 없이 부드럽게 렌더링됩니다.
2. 인터페이스는 확장 가능합니다. 응용 프로그램을 복잡하게 만들 수 있으며 많은 수의 그래프를 제거하고 생성하기 때문에 속도가 느려지지 않습니다. 사물. 다시 그리는 비용은 최소이며, 수천분의 1초에 그림을 교체하는 것입니다.
3. 기성 컨트롤을 생성하고 새로운 컨트롤을 생성할 수 있는 기능을 제공할 수 있습니다. 다음과 같이 고유한 이벤트 풀을 제공할 수 있습니다.
1. 비트맵의 인터페이스가 빠릅니다. 너무 빨라서 시스템 1과 거의 구별할 수 없습니다. 예를 들어, 그라디언트를 사용하여 반투명 요소를 구현 했으며 이동하는 경우에도 색상 혼합을 고려하고 반투명 그라디언트가 있는 다른 개체의 알파 채널을 계산하여 눈에 보이는 지연 없이 부드럽게 렌더링됩니다.
2. 인터페이스는 확장 가능합니다. 응용 프로그램을 복잡하게 만들 수 있으며 많은 수의 그래프를 제거하고 생성하기 때문에 속도가 느려지지 않습니다. 사물. 다시 그리는 비용은 최소이며, 수천분의 1초에 그림을 교체하는 것입니다.
3. 기성 컨트롤을 생성하고 새로운 컨트롤을 생성할 수 있는 기능을 제공할 수 있습니다. 다음과 같이 고유한 이벤트 풀을 제공할 수 있습니다.
스레드를 읽었습니다. 흥미롭습니다. 3년 전에는 인터페이스에 대한 그런 소란이 없었다는 것이 유감입니다.
내 코드를 게시하는 요점을 알지 못하기 때문에 참가자 간의 게으름과 의사 소통의 어려움 (및 이미 관찰되고 있음)으로 인해 이니셔티브가 중단 될 가능성이 높습니다. 내 코드는 자체 수정을 위해 지하실을 따라 드래그됩니다. 이로부터 이익을 얻지 못할 것입니다.
그러나 필요한 기능에 대한 논의부터 시작하여 구체적인 구현 세부 사항까지 토로 하는 프로젝트 에 참여할 수 있었습니다. 여기에는 이점이 있습니다. 프레임워크라고 합시다.
이점은 간단합니다. Alex가 첫 번째 게시물에서 밝혔습니다. 커뮤니티는 MQL 플랫폼을 개선하기 위해 터미널 개발자에게 영향을 줄 수 있습니다.
개선에 대한 나의 희망(프로그래밍 인터페이스와 직접적으로 관련됨)은 다음과 같습니다.
MQL 응용 프로그램 - 다른 사람을 취소하지 않는 별도의 유형의 프로그램으로(onTick이 없고 기본 기호에 액세스할 수 있는 기능이 없습니다. 이것은 과거의 유물이지만 모든 기호 및 거래의 거래 환경을 얻을 수 있는 기능이 있습니다. , 모든 것이 다중 통화이기 때문에) 응용 프로그램은 차트 특정 문자가 아니라 자체 창에서 시작되어야 합니다. 이러한 프로그램을 차트로 드래그하면 새 창이 열립니다. 예, 드래그 앤 드롭이 필요하지 않습니다. 네비게이터에서 2번 클릭하면 새 창이 열립니다. 다른 언어로 개발하기 위해 일부 사람들에게 터미널에 API를 제공하도록 요청하는 것과 같습니다. 주제를 개발하면 특별한 방법으로 컴파일 된 이러한 프로그램은 터미널없이 실행할 수 있다고 가정 할 수 있습니다 (안전을 위해 이러한 컴파일은 Market을 통해서만 허용됩니다). 미친 소리 같죠?
별도의 파일로 표시되는 타사 벡터 글꼴 및 리소스로 컴파일하는 기능 지원(문서에 선언되었지만 구현되지 않음)
마우스 휠 스크롤 이벤트 잡기
오른쪽 버튼의 시스템 메뉴 잠금. 오른쪽 버튼은 지금 처리 중이지만 소용이 없습니다.
시스템 클립보드로 작업하여 자신만의 텍스트 편집 컨트롤(여러 줄 편집기 포함)을 만들려면 공백과 Enter를 이미 차단할 수 있습니다. 좋습니다.
그럼, 아픈 것부터 시작하겠습니다) 가장 걱정되는 질문은 렌더링 매개변수를 저장하기 위한 일종의 보편성/추상화입니다.
----
우리가 이해하는 바와 같이 모든 컨트롤은 글꼴, 배경색 및 텍스트 색상 등을 동일하게 사용합니다. 이러한 모든 매개변수가 모든 컨트롤에 대해 동일하면 인터페이스는 단일 개념의 공통 보기를 갖습니다.
하지만 어떻게 보관합니까? 결국 항상 모든 매개변수를 사용하는 것은 아닙니다. + 요소의 상태가 다르므로 글꼴과 배경색을 다르게 사용해야 하므로 시스템이 복잡합니다. 즉, 요소가 활성일 때, 마우스에 반응하지 않을 때(비활성화), 마우스가 개체 위에 있을 때(오버), 컨트롤이 체크되었을 때(선택). 등. + 양각(버튼 유형) 및 입력 필드(편집, 목록 유형) 및 이것이 도면의 배경인 경우 제어 그룹이 있습니다.
----
현재 작업 아이디어에는 5개의 주요 매개변수(글꼴/크기, 배경/테두리 색상, 테두리 크기)가 포함된 최소 클래스 속성 요소 GAttribBase 가 있습니다.
이러한 기본 요소에서 상태에 대한 배열은 GAttribut 클래스 로 구성되며, 여기에서 상태에 대한 이러한 매개변수가 설정됩니다(Active/Disable/Over/Select 등).
이제 GAttribut는 엠보싱, 편집 가능 등 다양한 유형의 요소로 채워집니다.
따라서 렌더링 매개변수를 한 번(xml에 저장) 채우고 라이브로 편집하여 다른 디자인을 생성할 수 있으며 각 컨트롤에 대해 정의하지 않고 전역적으로 사용합니다.
물론 특정 컨트롤이 자체 렌더링 매개변수를 정의해야 하는 경우 컨트롤에서 고유한 GAttribut 개체를 만들고 원하는 색상을 지정하는 것으로 충분합니다.
----
이 모델은 작동 중이며 단일 디자인이 순식간에 이루어지며 모든 컨트롤은 공통 배열에서 색상을 가져옵니다.
그러나 내 생각에 그것은 보편적이지 않습니다. 기본 GAttribBase의 매개변수가 이 컨트롤이나 저 컨트롤을 그리는 데 사용된다는 사실이 사용자에게 투명하지 않기 때문입니다. 인코더가 어떤 색상을 변경해야 하는지 정확히 알기 위해서는 컨트롤의 그리기 기능을 살펴봐야 합니다. 스트레스를 받는 것.
------
일반적으로 - 인코더가 색상 작업에서 자유롭도록 하는 아이디어는 무엇입니까?
그리고 다른 한편으로 그는 화면에서 하나의 컨트롤을 다시 칠하려는 경우 렌더링 기능의 정글에 들어가지 않고 GAttribBase에서 사용된 것과 어떤 경우에 사용되는지 찾지 않습니다.
그리고 다른 한편으로 - 화면에서 하나의 컨트롤을 다시 칠하려는 경우 - 그는 렌더링 기능의 정글에 들어가지 않고 GAttribBase에서 사용된 것과 어떤 경우에 사용되는지 찾지 않습니다.
좋아, 주제.
예를 들어 응용 프로그램의 기본 개체인 App이라고 합시다. 이 개체는 ConcreteTheme 개체와 연결되어 있습니다.
테마 개체란 무엇입니까? 색상(배경, 전경, 비활성화, 활성 등), 기본 크기, 표준 경우의 글꼴 크기: titlesize, commonsize 등 , 스프라이트: 패널, 버튼, 체크박스 등
새 주제 - 값이 변경된 새 클래스/구조체. 그러나 테마를 상속할 수 있어 특정 매개변수만 재정의하는 것이 좋습니다.
나머지는 각 컨트롤이 기본적으로 필요한 테마 개체의 값 중 하나를 사용하는 컨트롤의 계층 구조입니다. 재정의해야 하는 경우 - 새 값을 나타내는 이 속성으로 작업하는 메서드를 호출합니다.
예를 들어 SetBgColor(XRGB(255,0,128));
CView - 이벤트 수준에서 기본 상호 작용을 제공하는 기본 클래스 - СRect - 좌표 - cPanel에는 bgcolor가 있습니다. - CButton에는 상태 개체가 있으며 각 상태에 대해 bg가 지정됩니다. - CText에는 텍스트 색상 및 글꼴 속성이 있습니다. - 서클
등.
xml을 사용하여 요소를 설명하려면
그런 다음 각 컨트롤 또는 기본 클래스에 대해 부모 클래스를 만들어야 합니다. 속성(bgcolor="(255,0,128)")이 해당 메서드( SetBgColor(attrValue)에 매핑되는 "빌드 컨테이너"라고 부르겠습니다. ) 클래스의. 이러한 빌드 컨테이너는 XML 파서에 의해 연결되며, 출력에서 필요한 값으로 초기화된 제어 개체를 얻거나 아무 것도 지정하지 않은 경우 기본값을 얻습니다.
그리고 다른 한편으로 - 화면에서 하나의 컨트롤을 다시 칠하려는 경우 - 그는 렌더링 기능의 정글에 들어가지 않고 GAttribBase에서 사용된 것과 어떤 경우에 사용되는지 찾지 않습니다.
각 요소에 대한 기본값을 설정합니다. 사용자가 무언가를 변경해야 하는 경우 요소의 각 속성에 대해 새 값을 설정하는 방법이 있어야 합니다. 이것이 내가 지금 한 방법입니다.
이것은 아직 없습니다:
"2개의 계정"에 있는 모든 요소의 속성을 변경해야 하는 경우 모든 인터페이스 요소에 액세스할 수 있는 클래스에서 별도의 메서드(디자인과 관련되고 모든 요소에 적용 가능한 일반 속성에 대해)를 생성하기만 하면 됩니다.
원칙적으로 내 계획에서는 이것이 어떻게 구현될 수 있는지 이미 알고 있습니다. 예를 들어 이벤트를 통해. 그러나 각 요소의 이벤트 핸들러에서 이 이벤트를 처리해야 합니다(코드가 부풀려짐). 두 번째 옵션은 일반 GUI 이벤트가 처리되거나 GUI 요소에 대한 모든 포인터가 저장되는 더 높은 수준의 클래스에서 특수 공용 메서드를 만드는 것입니다. 둘 다 사용자 정의 MQL 애플리케이션 클래스의 기본 클래스이며 사용자는 이에 직접 액세스할 수 있습니다. MQL의 오버로드 된 ObjectSet 메서드(예: ElementSet )와 같을 수 있습니다. 여기서 (1) 속성 및 값 또는 (2) 속성, 수정자 및 값을 설정해야 합니다.
그러나 이 모든 것은 내 계획에 대한 내 추론입니다. 새로운 단계로의 전환을 시작하면 여전히 많이 바뀔 것이라는 점을 배제하지 않는다. 따라서 위에서 작성한 모든 내용은 여기서 논의된 주제의 틀 내에서 더 이상 관련이 없을 수 있습니다. )
제 경우에는 구성원이 제품 판매로 어느 정도 이익을 얻을 수 있는 제품 개발 팀을 만드는 것이 더 쉽습니다.
글쎄요, 모두가 재정적으로 동기가 있기 때문에 프로젝트의 프레임워크 내에서 인터페이스에 필요한 라이브러리를 구현하십시오.
제 경우에는 구성원이 제품 판매로 어느 정도 이익을 얻을 수 있는 제품 개발 팀을 만드는 것이 더 쉽습니다.
글쎄요, 모두가 재정적으로 동기가 있기 때문에 프로젝트의 프레임워크 내에서 인터페이스에 필요한 라이브러리를 구현하십시오.
나는 분기를 읽었고 캔버스에 버튼을 처음부터 그리는 것이 왜 필요한지 이해하지 못했습니다. 감정 없이 설명할 수 있습니까?
MT 개발자는 전능하지 않고 사소한 위시리스트로 그들을 긴장시키는 데 시간이 많이 걸리기 때문에
이것이 유용한 이유:
1. 비트맵의 인터페이스가 빠릅니다. 너무 빨라서 시스템 1과 거의 구별할 수 없습니다. 예를 들어, 그라디언트를 사용하여 반투명 요소를 구현 했으며 이동하는 경우에도 색상 혼합을 고려하고 반투명 그라디언트가 있는 다른 개체의 알파 채널을 계산하여 눈에 보이는 지연 없이 부드럽게 렌더링됩니다.
2. 인터페이스는 확장 가능합니다. 응용 프로그램을 복잡하게 만들 수 있으며 많은 수의 그래프를 제거하고 생성하기 때문에 속도가 느려지지 않습니다. 사물. 다시 그리는 비용은 최소이며, 수천분의 1초에 그림을 교체하는 것입니다.
3. 기성 컨트롤을 생성하고 새로운 컨트롤을 생성할 수 있는 기능을 제공할 수 있습니다. 다음과 같이 고유한 이벤트 풀을 제공할 수 있습니다.
OnMouseDown - 누름 LMB
OnMouseUp - 누름 LMB
OnMouseHoverOn - 개체 위로 마우스를 가져갔습니다.
OnMouseHoverOut - 마우스 커서를 개체에서 멀리 이동했습니다.
OnMouseClick - 영향을 받는 개체의 경계 내에서 LMB를 눌렀다 뗍니다.
영향을 받는 개체 내에서 OnMouseDblClick 두 번 클릭 LMB
OnDragStart - LMB를 누른 상태에서 이동 시작 시 1회 발생하는 이벤트
OnDragMove - LMB로 이동하는 과정에서 발생하는 이벤트
OnDragEnd - LMB로 이동 후 발생하는 이벤트
OnPut - 객체가 다른 객체에 던져졌습니다.
OnGet - 다른 개체가 개체에 던져졌습니다.
OnFocus - 개체가 포커스를 받았습니다.
OnBlur - 개체가 초점을 잃었습니다.
OnResize - 개체의 크기가 변경되었습니다.
OnParentResize - 개체의 부모 크기가 변경되었습니다.
OnKeyPress - 키를 눌렀습니다.
OnChange - 필드 값이 변경되었습니다.
등.
이것이 유용한 이유:
1. 비트맵의 인터페이스가 빠릅니다. 너무 빨라서 시스템 1과 거의 구별할 수 없습니다. 예를 들어, 그라디언트를 사용하여 반투명 요소를 구현 했으며 이동하는 경우에도 색상 혼합을 고려하고 반투명 그라디언트가 있는 다른 개체의 알파 채널을 계산하여 눈에 보이는 지연 없이 부드럽게 렌더링됩니다.
2. 인터페이스는 확장 가능합니다. 응용 프로그램을 복잡하게 만들 수 있으며 많은 수의 그래프를 제거하고 생성하기 때문에 속도가 느려지지 않습니다. 사물. 다시 그리는 비용은 최소이며, 수천분의 1초에 그림을 교체하는 것입니다.
3. 기성 컨트롤을 생성하고 새로운 컨트롤을 생성할 수 있는 기능을 제공할 수 있습니다. 다음과 같이 고유한 이벤트 풀을 제공할 수 있습니다.
OnMouseDown - 누름 LMB
OnMouseUp - 누름 LMB
OnMouseHoverOn - 개체 위로 마우스를 가져갔습니다.
OnMouseHoverOut - 마우스 커서를 개체에서 멀리 이동했습니다.
OnMouseClick - 영향을 받는 개체의 경계 내에서 LMB를 눌렀다 뗍니다.
영향을 받는 개체 내에서 OnMouseDblClick 두 번 클릭 LMB
OnDragStart - LMB를 누른 상태에서 이동 시작 시 1회 발생하는 이벤트
OnDragMove - LMB로 이동하는 과정에서 발생하는 이벤트
OnDragEnd - LMB로 이동 후 발생하는 이벤트
OnPut - 객체가 다른 객체에 던져졌습니다.
OnGet - 다른 개체가 개체에 던져졌습니다.
OnFocus - 개체가 포커스를 받았습니다.
OnBlur - 개체가 초점을 잃었습니다.
OnResize - 개체의 크기가 변경되었습니다.
OnParentResize - 개체의 부모 크기가 변경되었습니다.
OnKeyPress - 키를 눌렀습니다.
OnChange - 필드 값이 변경됨
등.
완벽합니다. 감사합니다!
@이고르 볼로딘 , @콤비네이터, @ 아나톨리 카자르스키
그럼, 아픈 것부터 시작하겠습니다)
가장 걱정되는 질문은 렌더링 매개변수를 저장하기 위한 일종의 보편성/추상화입니다.
----
우리가 이해하는 바와 같이 모든 컨트롤은 글꼴, 배경색 및 텍스트 색상 등을 동일하게 사용합니다.
이러한 모든 매개변수가 모든 컨트롤에 대해 동일하면 인터페이스는 단일 개념의 공통 보기를 갖습니다.
하지만 어떻게 보관합니까? 결국 항상 모든 매개변수를 사용하는 것은 아닙니다.
+ 요소의 상태가 다르므로 글꼴과 배경색을 다르게 사용해야 하므로 시스템이 복잡합니다. 즉, 요소가 활성일 때, 마우스에 반응하지 않을 때(비활성화), 마우스가 개체 위에 있을 때(오버), 컨트롤이 체크되었을 때(선택). 등.
+ 양각(버튼 유형) 및 입력 필드(편집, 목록 유형) 및 이것이 도면의 배경인 경우 제어 그룹이 있습니다.
----
현재 작업 아이디어에는 5개의 주요 매개변수(글꼴/크기, 배경/테두리 색상, 테두리 크기)가 포함된 최소 클래스 속성 요소 GAttribBase 가 있습니다.
이러한 기본 요소에서 상태에 대한 배열은 GAttribut 클래스 로 구성되며, 여기에서 상태에 대한 이러한 매개변수가 설정됩니다(Active/Disable/Over/Select 등).
이제 GAttribut는 엠보싱, 편집 가능 등 다양한 유형의 요소로 채워집니다.
따라서 렌더링 매개변수를 한 번(xml에 저장) 채우고 라이브로 편집하여 다른 디자인을 생성할 수 있으며 각 컨트롤에 대해 정의하지 않고 전역적으로 사용합니다.
물론 특정 컨트롤이 자체 렌더링 매개변수를 정의해야 하는 경우 컨트롤에서 고유한 GAttribut 개체를 만들고 원하는 색상을 지정하는 것으로 충분합니다.
----
이 모델은 작동 중이며 단일 디자인이 순식간에 이루어지며 모든 컨트롤은 공통 배열에서 색상을 가져옵니다.
그러나 내 생각에 그것은 보편적이지 않습니다. 기본 GAttribBase의 매개변수가 이 컨트롤이나 저 컨트롤을 그리는 데 사용된다는 사실이 사용자에게 투명하지 않기 때문입니다.
인코더가 어떤 색상을 변경해야 하는지 정확히 알기 위해서는 컨트롤의 그리기 기능을 살펴봐야 합니다. 스트레스를 받는 것.
------
일반적으로 - 인코더가 색상 작업에서 자유롭도록 하는 아이디어는 무엇입니까?
그리고 다른 한편으로 그는 화면에서 하나의 컨트롤을 다시 칠하려는 경우 렌더링 기능의 정글에 들어가지 않고 GAttribBase에서 사용된 것과 어떤 경우에 사용되는지 찾지 않습니다.
@이고르 볼로딘 , @콤비네이터, @ 아나톨리 카자르스키
일반적으로 - 인코더가 색상 작업에서 자유롭도록 하는 아이디어는 무엇입니까?
그리고 다른 한편으로 - 화면에서 하나의 컨트롤을 다시 칠하려는 경우 - 그는 렌더링 기능의 정글에 들어가지 않고 GAttribBase에서 사용된 것과 어떤 경우에 사용되는지 찾지 않습니다.
좋아, 주제.
예를 들어 응용 프로그램의 기본 개체인 App이라고 합시다. 이 개체는 ConcreteTheme 개체와 연결되어 있습니다.
테마 개체란 무엇입니까?
색상(배경, 전경, 비활성화, 활성 등), 기본 크기, 표준 경우의 글꼴 크기: titlesize, commonsize 등 , 스프라이트: 패널, 버튼, 체크박스 등
새 주제 - 값이 변경된 새 클래스/구조체. 그러나 테마를 상속할 수 있어 특정 매개변수만 재정의하는 것이 좋습니다.
나머지는 각 컨트롤이 기본적으로 필요한 테마 개체의 값 중 하나를 사용하는 컨트롤의 계층 구조입니다. 재정의해야 하는 경우 - 새 값을 나타내는 이 속성으로 작업하는 메서드를 호출합니다.
예를 들어 SetBgColor(XRGB(255,0,128));
CView - 이벤트 수준에서 기본 상호 작용을 제공하는 기본 클래스
- СRect - 좌표
- cPanel에는 bgcolor가 있습니다.
- CButton에는 상태 개체가 있으며 각 상태에 대해 bg가 지정됩니다.
- CText에는 텍스트 색상 및 글꼴 속성이 있습니다.
- 서클
등.
xml을 사용하여 요소를 설명하려면
그런 다음 각 컨트롤 또는 기본 클래스에 대해 부모 클래스를 만들어야 합니다. 속성(bgcolor="(255,0,128)")이 해당 메서드( SetBgColor(attrValue)에 매핑되는 "빌드 컨테이너"라고 부르겠습니다. ) 클래스의. 이러한 빌드 컨테이너는 XML 파서에 의해 연결되며, 출력에서 필요한 값으로 초기화된 제어 개체를 얻거나 아무 것도 지정하지 않은 경우 기본값을 얻습니다.
여기 테마 는 내 것과 동일합니다. 다양한 유형의 컨트롤 및 해당 상태에 대한 GAttributs 집합입니다.
그러나 인코더의 투명도를 향한 첫 번째 단계는 이미 제안했습니다. 특정 컨트롤에 기능을 추가하여 렌더링 속성(SetBgColor 등)을 변경합니다.
원칙적으로 어떤 색상이 있고 무엇을 변경할 수 있는지 명확하다는 데 동의합니다.
그런 질문 - 테마는 사용하지 않는 매개변수의 중복성을 의미합니까?
특정 컨트롤(예: 버튼)에 대한 기본 GAttribBase에서 배경색 과 크기만 사용하고 나머지 매개변수는 테두리 두께 등이라고 가정해 보겠습니다. 이 컨트롤에서 사용되지 않습니다.
즉, 모든 컨트롤에 대한 기본 요소가 있습니까? "모든 경우에 대해" infa는 어디에 저장됩니까, 아니면 모든 컨트롤에 보편성 오버헤드 없이 자체 매개변수만 있습니까?
...
일반적으로 - 인코더가 색상 작업에서 자유롭도록 하는 아이디어는 무엇입니까?
그리고 다른 한편으로 - 화면에서 하나의 컨트롤을 다시 칠하려는 경우 - 그는 렌더링 기능의 정글에 들어가지 않고 GAttribBase에서 사용된 것과 어떤 경우에 사용되는지 찾지 않습니다.
각 요소에 대한 기본값을 설정합니다. 사용자가 무언가를 변경해야 하는 경우 요소의 각 속성에 대해 새 값을 설정하는 방법이 있어야 합니다. 이것이 내가 지금 한 방법입니다.
이것은 아직 없습니다:
그러나 이 모든 것은 내 계획에 대한 내 추론입니다. 새로운 단계로의 전환을 시작하면 여전히 많이 바뀔 것이라는 점을 배제하지 않는다. 따라서 위에서 작성한 모든 내용은 여기서 논의된 주제의 틀 내에서 더 이상 관련이 없을 수 있습니다. )