모든 대화 상자 요소(양식, 제어 요소(버튼, 목록, 그림))에는 몇 가지 속성이 있습니다. 절차적 프로그래밍은 "속성" 또는 "필드"의 개념을 정의하지 않습니다. 절차적 프로그래밍에는 함수와 변수(전역 또는 지역)가 있습니다. 그러나 변수는 공유되므로 각 개별 컨트롤의 속성을 설명하는 데 사용할 수 없습니다. 그럼 탈출구는? 네 간단합니다 - 구조!
예, 구조는 제어 요소의 필수 속성에 대한 설명과 중첩된(인정하는) 제어 요소의 배열을 가질 수 있습니다.
모든 것이 대화 상자 배열에 저장됩니다.
보다 보편적으로 만들 수 있습니다. 제어 설명 구조는 속성 배열과 종속 요소 배열의 두 가지 배열로 구성됩니다. 속성 배열은 속성-값 쌍의 구조 배열입니다. 이 접근 방식을 사용하면 각각의 새 컨트롤에 임의 의 속성 집합이 포함될 수 있습니다. 그러나 처리에 편리하지 않습니다. 크기, 위치, 색상, 프레임 등 제어 요소의 특정 속성을 구조에 표시하는 것이 더 논리적입니다. 모든 제어 요소에 필요한 모든 것입니다.
글쎄요, 구조에 이 요소의 픽셀 배열도 있을 것입니다.
마우스 이벤트가 수신되면 루프는 모든 배열을 반복하여 커서가 특정 컨트롤에 닿았는지 확인합니다. 확인은 마지막에서 처음으로 수행됩니다.
커서가 어느 컨트롤에 도달했는지 밝혀지자 마자 이 배열 요소가 다시 그리기 기능으로 전송되고 리소스 배열을 업데이트하고 차트의 그림을 업데이트합니다.
Все объекты, используемые в техническом анализе, имеют привязку на графиках по координатам цены и времени – трендовая линия, каналы, инструменты Фибоначчи и т.д. Но есть ряд вспомогательных объектов, предназначенных для улучшения интерфейса, которые имеют привязку к видимой всегда части графика (основное окно графика или подокна индикаторов...
그가 무엇을 게시했고 GUI에서 무엇을 했는지는 모르지만 내 스레드에서 그는 단일 솔루션이 아니라 단일 기술 제안을 하지 않았으며 주제에 대한 토론을 주도하지 않았습니다. 제3자 솔루션을 가리키고 바퀴를 재발명하지 말라고 외치는 빈 트롤링만 있을 뿐입니다.
다시 주제로 돌아가자.
내가 표준 라이브러리에 대해 잘 아는 한(사실 거의 없음) 요소와 창은 MT 개체로 구성됩니다. 즉, 우리 컨텍스트에서는 캔버스에 그려지지 않습니다. 물론 그것들은 그려지지만 우리의 캔버스에는 그려지지 않기 때문에 픽셀 색상을 제어하고 표면 그라디언트를 만드는 등의 기능을 제공하지 않습니다.
이론적으로 라이브러리의 구조를 가져 와서 복사하고 캔버스에 아날로그를 만들 수 있습니다. 이론에 의하면...
문제는 Ccanvas 자체가 GUI를 만드는 데 편리하지 않다는 것입니다. 왜요? 캔버스 시스템이 주로 그래픽 프리미티브에 맞게 조정되었기 때문입니다. 즉, 사실 이 클래스는 프리미티브 외에는 아무것도 제공하지 않습니다. GUI 아키텍처는 스스로 구축해야 합니다. 그리고 이 경우 클래스는 선택 사항입니다. 스스로 결정을 내리는 것이 좋습니다. 결국 이 클래스 없이 직사각형 레이블을 그릴 수 있습니다. 캔버스를 생성하거나 업로드하는 방법. 아주 간단합니다. 따라서 나는 내 솔루션을 선호했습니다.
그러나 어떤 식으로든 CCCanvas가 없는 사람에게. 그러므로 나는 주장하지 않는다.
CCanvas의 문제는 GUI가 차트 창에 엄격하게 묶여 있다는 것입니다. 즉, 터미널 인터페이스 모듈 형태의 본격적인 창을 만들 수 없습니다. 그리고 자신만의 인터페이스 모듈을 작성하는 것은 매우 멋질 것입니다.
전술한 내용을 기반으로 구조 요소는 특정 대화 상자 컨트롤이며 고유한 속성을 포함하고 중첩된 컨트롤을 포함할 수 있음을 이해할 수 있습니다. 이러한 범용 컨트롤의 속성 집합은 개발자의 상상력에 의해서만 제한됩니다.
물론 구조로 올라갈 수는 없지만 다차원 배열 에서 컨트롤의 속성을 설명할 수 있지만 일부 속성이 저장된 인덱스를 명확하게 기억해야 하기 때문에 처음에는 비용 효율적이지 않습니다. 그리고 배열은 이기종 데이터 유형을 포함할 수 없습니다. 절차적 프로그래밍에서 제어 요소를 구조를 통해서만 기술할 수 있음이 밝혀졌습니다. 즉, 구조 요소는 특정 제어 요소, 즉 고유한 속성을 가진 특정 대화 상자 개체입니다.
Переменные должны быть объявлены перед их использованием. Для идентификации переменных используются уникальные имена. Описания переменных используются для их определения и объявления типов. Описание не является оператором. Индексом массива может быть только целое число. Допускаются не более чем четырехмерные массивы. Нумерация элементов...
모든 대화 요소(양식, 제어 요소(버튼, 목록, 그림))에는 몇 가지 속성이 있습니다. 절차적 프로그래밍은 "속성" 또는 "필드"의 개념을 정의하지 않습니다. 절차적 프로그래밍에는 함수와 변수(전역 또는 지역)가 있습니다. 그러나 변수는 공유되므로 각 개별 컨트롤의 속성을 설명하는 데 사용할 수 없습니다. 그럼 탈출구는? 네 간단합니다 - 구조!
예, 구조는 제어 요소의 필수 속성에 대한 설명과 중첩된(인정하는) 제어 요소의 배열을 가질 수 있습니다.
모든 것이 대화 상자 배열에 저장됩니다.
보다 보편적으로 만들 수 있습니다. 제어 설명 구조는 속성 배열과 종속 요소 배열의 두 가지 배열로 구성됩니다. 속성 배열은 속성-값 쌍의 구조 배열입니다. 이 접근 방식을 사용하면 각각의 새 컨트롤에 임의 의 속성 집합이 있을 수 있습니다. 그러나 처리에 편리하지 않습니다. 크기, 위치, 색상, 프레임 등 제어 요소의 특정 속성을 구조에 표시하는 것이 더 논리적입니다. 모든 제어 요소에 필요한 모든 것입니다.
글쎄, 구조에 이 요소의 픽셀 배열도 있을 것입니다.
마우스 이벤트가 수신되면 루프는 모든 배열을 반복하여 커서가 특정 컨트롤에 닿았는지 확인합니다. 확인은 마지막에서 처음으로 수행됩니다.
커서가 어느 컨트롤에 도달했는지 밝혀지자 마자 이 배열 요소가 다시 그리기 기능으로 전송되고 리소스 배열을 업데이트하고 차트의 그림을 업데이트합니다.
1. 창, 버튼, 체크박스와 같은 기본 컨트롤의 가장 간단한 구조를 설계했다고 가정합니다. 각각은 구성 요소 집합인 개체로 구성됩니다. 확인란 - 기본, 텍스트, 아이콘. 버튼 - 기본, 텍스트, 아이콘 등. 각 요소의 각 개체에는 고유한 속성 집합이 있어야 합니다. 구조체나 클래스로 작성해도 되지만 제 생각에는 불편합니다. 왜요? - 창에 배치하면 커서가 있는 캔버스에서 찾아야 하기 때문입니다. 커서를 움직이면 초점이 맞춰져야 합니다. 이를 위해 현재 좌표는 배열에 있어야 합니다. 그리고 모든 속성(현재 좌표 포함)이 하나의 배열에 있으면 더 편리합니다. 따라서 커서의 초점에 속하는 캔버스의 모든 요소 속성에 즉시 액세스할 수 있습니다. 또한 요소 배열을 반복하는 것이 더 쉽습니다.
즉, 커서가 적중한 요소에 대한 검색 루프에서 하나의 배열을 우회하는 것이 더 쉽습니다. 그리고 이 배열이 전역적이면 훨씬 더 편리합니다. 그런 다음 모든 기능에서 필요한 정보를 가져올 수 있으며 모든 기능에서 필요한 속성, 필요한 요소의 값을 변경할 수 있습니다.
이것은 요소에 대한 가장 짧고 효율적인 액세스와 가장 빠른 처리입니다. 이것이 제 핵심입니다.
2. 그러나 전문가의 변덕을 알기에 표준 OOP를 최대한 모방하기 위해 노력하므로 이 기술을 제공하지 않습니다.
3. 픽셀 배열은 어디에도 저장할 필요가 없습니다. 배열에 있는 요소의 매개변수에 따라 필요한 순간에 빌드됩니다. 예: 창을 다시 그려야 합니다. 다시 그리기 기능을 호출합니다. 이 함수는 요소 배열에 액세스하고, 모든 속성을 보고, 픽셀 배열을 선언하고, 크기를 계산하고, 요소에 대한 루프에서 개체를 순차적으로 그리고 ResourceCreate()를 호출합니다. 모두.
4. 커서 아래에 있는 요소는 다시 그리기를 위해 동일한 기능으로 전송됩니다. 알림(요소 다시 그리기 플래그)과 요소 배열의 번호를 수신합니다. 다음으로 함수는 ResourceReadImage()를 통해 필요한 리소스를 호출하고 픽셀 배열에 푸시한 다음 픽셀 배열 내부에서 원하는 요소의 영역을 찾아 모든 개체를 다시 그립니다. ResourceCreate()를 통해 저장합니다. 모두.
1. 창, 버튼, 체크박스와 같은 기본 컨트롤의 가장 간단한 구조를 설계했다고 가정합니다. 각각은 구성 요소 집합인 개체로 구성됩니다. 확인란 - 기본, 텍스트, 아이콘. 버튼 - 베이스, 텍스트, 아이콘 등. 각 요소의 각 개체에는 고유한 속성 집합이 있어야 합니다. 구조체나 클래스로 작성해도 되지만 제 생각에는 불편합니다. 왜요? - 창에 배치하면 커서가 있는 캔버스에서 찾아야 하기 때문입니다. 커서를 움직이면 초점이 맞춰져야 합니다. 이를 위해 현재 좌표는 배열에 있어야 합니다. 그리고 모든 속성(현재 좌표 포함)이 하나의 배열에 있으면 더 편리합니다. 따라서 커서의 초점에 있는 캔버스의 모든 요소 속성에 즉시 액세스할 수 있습니다. 또한 요소 배열을 반복하는 것이 더 쉽습니다.
즉, 커서가 적중한 요소에 대한 검색 루프에서 하나의 배열을 우회하는 것이 더 쉽습니다. 그리고 이 배열이 전역적이면 훨씬 더 편리합니다. 그런 다음 모든 기능에서 필요한 정보를 가져올 수 있으며 모든 기능에서 필요한 속성, 필요한 요소의 값을 변경할 수 있습니다.
이것은 요소에 대한 가장 짧고 효율적인 액세스와 가장 빠른 처리입니다. 이것이 제 핵심입니다.
2. 그러나 전문가의 변덕을 알기에 표준 OOP를 최대한 모방하기 위해 노력하므로 이 기술을 제공하지 않습니다.
3. 픽셀 배열은 어디에도 저장할 필요가 없습니다. 배열에 있는 요소의 매개변수에 따라 필요한 순간에 빌드됩니다. 예: 창을 다시 그려야 합니다. 다시 그리기 기능을 호출합니다. 이 함수는 요소 배열에 액세스하고, 모든 속성을 보고, 픽셀 배열을 선언하고, 크기를 계산하고, 요소에 대한 루프에서 개체를 순차적으로 그리고 ResourceCreate()를 호출합니다. 모두.
4. 커서 아래에 있는 요소는 다시 그리기를 위해 동일한 기능으로 전송됩니다. 알림(요소 다시 그리기 플래그)과 요소 배열의 번호를 수신합니다. 다음으로 함수는 ResourceReadImage()를 통해 필요한 리소스를 호출하고 픽셀 배열에 푸시한 다음 픽셀 배열 내부에서 원하는 요소의 영역을 찾아 모든 개체를 다시 그립니다. ResourceCreate()를 통해 저장합니다. 모두.
사실 이것은 건설 기술에 관계없이 일어나야 합니다. 그것은 다른 방식으로 만 감지 될 수 있습니다. 귀하의 경우 배열을 반복하고 커서가 현재 켜져 있는 컨트롤을 결정합니다. 위의 내용을 기반으로 인덱스를 결정하면 발견된 요소의 속성을 즉시 볼 수 있습니다. 그러나 어떻게 하나의 큰 배열에 다양한 유형의 데이터 를 저장할 수 있습니까?
Любая программа оперирует данными. Данные могут быть различных типов в зависимости от назначения. Например, для доступа к элементам массива используются данные целочисленного типа. Ценовые данные имеют тип двойной точности с плавающей точкой. Это связано с тем, что в языке MQL5 не предусмотрено специального типа для ценовых данных. Данные...
사실 이것은 건설 기술에 관계없이 일어나야 합니다. 다르게 인식될 수 밖에 없습니다. 귀하의 경우 배열을 반복하고 커서가 현재 켜져 있는 컨트롤을 결정합니다. 위의 내용을 기반으로 인덱스를 결정하면 찾은 요소의 속성을 즉시 볼 수 있습니다. 그러나 어떻게 하나의 큰 배열에 다양한 유형의 데이터 를 저장할 수 있습니까?
원칙적으로 유형을 일반화할 수 있습니다. 대부분의 객체 속성이 int 유형이면 나쁜 일이 일어나지 않는다는 결론에 도달했습니다. 다른 모든 축약형(그래프 객체의 속성에는 double이 거의 없음)은 단순화를 위해 생략했습니다. 기억의 "과잉 지출"은 너무 미미하여 그것에 대해 생각하는 것이 의미가 없습니다. 물론 전문성을 높이기 위해 그런 신성모독은 함부로 할 수 없다.)) 하지만, 지금은 21세기와 불을 위협하지 않는다.))
나는 개체의 이름을 번호로 만들고 개체 속성의 일반 행에 넣습니다.
다른 데이터 유형이 필요한 유일한 곳은 컨트롤의 매개변수였습니다. 거기에서 매개변수의 속성을 저장하는 두 번째 코어를 만들었으며 값 자체는 문자열 유형으로 되어 있어 무엇이든 쉽게(더 정확하게는 매개변수 속성에 기록된 것으로) 캐스팅할 수 있습니다.
1. 창, 버튼, 체크박스와 같은 기본 컨트롤의 가장 간단한 구조를 설계했다고 가정합니다. 각각은 구성 요소 집합인 개체로 구성됩니다. 확인란 - 기본, 텍스트, 아이콘. 버튼 - 베이스, 텍스트, 아이콘 등. 각 요소의 각 개체에는 고유한 속성 집합이 있어야 합니다. 구조체나 클래스로 작성해도 되지만 제 생각에는 불편합니다. 왜요? - 창에 배치하면 커서가 있는 캔버스에서 찾아야 하기 때문입니다. 커서를 움직이면 초점이 맞춰져야 합니다. 이를 위해 현재 좌표는 배열에 있어야 합니다. 그리고 모든 속성(현재 좌표 포함)이 하나의 배열에 있으면 더 편리합니다. 따라서 커서의 초점에 있는 캔버스의 모든 요소 속성에 즉시 액세스할 수 있습니다. 또한 요소 배열을 반복하는 것이 더 쉽습니다.
즉, 커서가 적중한 요소에 대한 검색 루프에서 하나의 배열을 우회하는 것이 더 쉽습니다. 그리고 이 배열이 전역적이면 훨씬 더 편리합니다. 그런 다음 모든 기능에서 필요한 정보를 가져올 수 있으며 모든 기능에서 필요한 속성, 필요한 요소의 값을 변경할 수 있습니다.
이것은 요소에 대한 가장 짧고 효율적인 액세스와 가장 빠른 처리입니다. 이것이 제 핵심입니다.
2. 그러나 전문가의 변덕을 알기에 표준 OOP를 최대한 모방하기 위해 노력하므로 이 기술을 제공하지 않습니다.
3. 픽셀 배열은 어디에도 저장할 필요가 없습니다. 배열에 있는 요소의 매개변수에 따라 필요한 순간에 빌드됩니다. 예: 창을 다시 그려야 합니다. 다시 그리기 기능을 호출합니다. 이 함수는 요소 배열에 액세스하고, 모든 속성을 보고, 픽셀 배열을 선언하고, 크기를 계산하고, 요소에 대한 루프에서 개체를 순차적으로 그리고 ResourceCreate()를 호출합니다. 모두.
4. 커서 아래에 있는 요소는 다시 그리기를 위해 동일한 기능으로 전송됩니다. 알림(요소 다시 그리기 플래그)과 요소 배열의 번호를 수신합니다. 다음으로 함수는 ResourceReadImage()를 통해 필요한 리소스를 호출하고 픽셀 배열에 푸시한 다음 픽셀 배열 내부에서 원하는 요소의 영역을 찾아 모든 개체를 다시 그립니다. 모두.
와우, 이 영원한 네거티브 to oops, 바로 라인을 통해
그가 어떻게 거기에 왔는지 궁금해 한 적이 있습니까? 사실 절차적 스타일로 작성하고 OOP에 대해 모르는 많은 사람들이 기능을 그룹화하려는 욕구에 직면하게 되며, 이러한 욕구는 이러한 기능을 하나의 메모리 영역으로 결합하고 참조하려는 욕구로 발전합니다. 변수에 저장된 기능이 있는 섹션에 대한 물리적 링크. 그런 다음 코드를 복제하지 않고(상속을 얻음) 선택한 함수 묶음을 변경하려는 욕구가 있습니다. 그래서 처음에는 절차적 스타일에만 익숙해지고 시간이 지나면서 질문을 합니다. µl(다중 상속에 대한 참조)에 왜 그렇게 많은 제한이 있습니까?
일반적으로 절차 스타일에 익숙해지면 재교육이 매우 어려울 것이기 때문에 OOP를 즉시 가르치는 것이 더 쉽다고 믿어집니다 ( 대부분의 사람들에게). 처음에는 절차적 스타일이었습니다... 위에서 설명했습니다.
위협 OOP에는 절차적 코드 수준에서 OOP에 익숙한 것으로 추정되는 다양성이 있으며 실제로 OOP를 최대한 사용합니다.
클래스는 기본 배열을 유지하면서 다시 작성하고 추가할 수 있는 함수의 메모리(테이블)에 대한 참조 + 변수에 대한 참조입니다. 그리고 이미 다른 것을 잊어 버렸습니다 .... (32 바이트는 무게가 있어야 함)
검색은 영원한 작업입니다. 최근에 내장된 정렬 기능을 Red 정렬(템플릿 중 하나)과 비교했는데 특정 조건에서 3-6배의 속도를 잃습니다(내장된 것이 손실됨 =)
그가 어떻게 거기에 왔는지 궁금해 한 적이 있습니까? 사실 절차적 스타일로 작성하고 OOP에 대해 모르는 많은 사람들이 기능을 그룹화하려는 욕구에 직면하게 되며, 이러한 욕구는 이러한 기능을 하나의 메모리 영역으로 결합하고 참조하려는 욕구로 발전합니다. 변수에 저장된 기능이 있는 섹션에 대한 물리적 링크. 그런 다음 코드를 복제하지 않고(상속을 얻음) 선택한 함수 묶음을 변경하려는 욕구가 있습니다. 그래서 처음에는 절차적 스타일에만 익숙해지고 시간이 지나면서 질문을 합니다. µl(다중 상속에 대한 참조)에 왜 그렇게 많은 제한이 있습니까?
일반적으로 절차 스타일에 익숙해지면 재교육이 매우 어려울 것이기 때문에 OOP를 즉시 가르치는 것이 더 쉽다고 믿어집니다 (대부분의 사람들에게). 처음에는 절차적 스타일이었습니다... 위에서 설명했습니다.
위협 OOP에는 절차적 코드 수준에서 OOP에 익숙한 것으로 추정되는 다양성이 있으며 실제로 OOP를 최대한 사용합니다.
클래스는 기본 배열을 유지하면서 다시 작성하고 추가할 수 있는 함수의 메모리(테이블)에 대한 참조 + 변수에 대한 참조입니다. 그리고 이미 다른 것을 잊어 버렸습니다 .... (32 바이트는 무게가 있어야 함)
검색은 영원한 작업입니다. 최근에 내장된 정렬 기능을 Red 정렬(템플릿 중 하나)과 비교했는데 특정 조건에서 3-6배의 속도를 잃습니다(내장된 것이 손실됨 =)
ON GUI 표준 방법이 있다고 생각합니다.
,
나는 OOP의 개념에 대해 부정적인 태도를 갖고 있지 않다. 나는 그녀의 팬이다. 나는 기준에 대해 부정적인 태도를 가지고 있다. 더 정확하게는 정신없이 따라가는 것입니다.)
모든 대화 상자 요소(양식, 제어 요소(버튼, 목록, 그림))에는 몇 가지 속성이 있습니다. 절차적 프로그래밍은 "속성" 또는 "필드"의 개념을 정의하지 않습니다. 절차적 프로그래밍에는 함수와 변수(전역 또는 지역)가 있습니다. 그러나 변수는 공유되므로 각 개별 컨트롤의 속성을 설명하는 데 사용할 수 없습니다. 그럼 탈출구는? 네 간단합니다 - 구조!
예, 구조는 제어 요소의 필수 속성에 대한 설명과 중첩된(인정하는) 제어 요소의 배열을 가질 수 있습니다.
모든 것이 대화 상자 배열에 저장됩니다.
보다 보편적으로 만들 수 있습니다. 제어 설명 구조는 속성 배열과 종속 요소 배열의 두 가지 배열로 구성됩니다. 속성 배열은 속성-값 쌍의 구조 배열입니다. 이 접근 방식을 사용하면 각각의 새 컨트롤에 임의 의 속성 집합이 포함될 수 있습니다. 그러나 처리에 편리하지 않습니다. 크기, 위치, 색상, 프레임 등 제어 요소의 특정 속성을 구조에 표시하는 것이 더 논리적입니다. 모든 제어 요소에 필요한 모든 것입니다.
글쎄요, 구조에 이 요소의 픽셀 배열도 있을 것입니다.
마우스 이벤트가 수신되면 루프는 모든 배열을 반복하여 커서가 특정 컨트롤에 닿았는지 확인합니다. 확인은 마지막에서 처음으로 수행됩니다.
커서가 어느 컨트롤에 도달했는지 밝혀지자 마자 이 배열 요소가 다시 그리기 기능으로 전송되고 리소스 배열을 업데이트하고 차트의 그림을 업데이트합니다.
그가 무엇을 게시했고 GUI에서 무엇을 했는지는 모르지만 내 스레드에서 그는 단일 솔루션이 아니라 단일 기술 제안을 하지 않았으며 주제에 대한 토론을 주도하지 않았습니다. 제3자 솔루션을 가리키고 바퀴를 재발명하지 말라고 외치는 빈 트롤링만 있을 뿐입니다.
다시 주제로 돌아가자.
내가 표준 라이브러리에 대해 잘 아는 한(사실 거의 없음) 요소와 창은 MT 개체로 구성됩니다. 즉, 우리 컨텍스트에서는 캔버스에 그려지지 않습니다. 물론 그것들은 그려지지만 우리의 캔버스에는 그려지지 않기 때문에 픽셀 색상을 제어하고 표면 그라디언트를 만드는 등의 기능을 제공하지 않습니다.
이론적으로 라이브러리의 구조를 가져 와서 복사하고 캔버스에 아날로그를 만들 수 있습니다. 이론에 의하면...
문제는 Ccanvas 자체가 GUI를 만드는 데 편리하지 않다는 것입니다. 왜요? 캔버스 시스템이 주로 그래픽 프리미티브에 맞게 조정되었기 때문입니다. 즉, 사실 이 클래스는 프리미티브 외에는 아무것도 제공하지 않습니다. GUI 아키텍처는 스스로 구축해야 합니다. 그리고 이 경우 클래스는 선택 사항입니다. 스스로 결정을 내리는 것이 좋습니다. 결국 이 클래스 없이 직사각형 레이블을 그릴 수 있습니다. 캔버스를 생성하거나 업로드하는 방법. 아주 간단합니다. 따라서 나는 내 솔루션을 선호했습니다.
그러나 어떤 식으로든 CCCanvas가 없는 사람에게. 그러므로 나는 주장하지 않는다.
CCanvas의 문제는 GUI가 차트 창에 엄격하게 묶여 있다는 것입니다.
즉, 터미널 인터페이스 모듈 형태의 본격적인 창을 만들 수 없습니다.
그리고 자신만의 인터페이스 모듈을 작성하는 것은 매우 멋질 것입니다.
물론 조금 다르지만 :-)
Python/Ruby/etc에서 GUI로 공유되는 Tk 그래픽이 있는 Tcl DLL(Tool Common Language)에 대한 인터페이스를 게시했습니다.
GUI를 얻는 것이 목표가 아니었습니다. 일종의 좋은 부작용입니다 :-)
tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ;
내 의견으로는 편리하고 가장 중요하게는 짧습니다 :-)
나는 아무도 동요하지 않습니다 - 나는 tcl / tk를 알고 사용합니다. 모범 사례를 공유했습니다(sourceforge atcl 참조)
예, Max, 저는 TCL과 프로토타입에 대해 이야기하고 있습니다. 사용자가 자신의 컴퓨터에 적절한 라이브러리를 설치해야 한다는 제한이 있었습니다. 어렵지 않은 것 같긴 한데, 그래도 이것은 어느 정도 한계가 있습니다.
과거로 남겨두자. Max, 추론에 참여하십시오. 로마자도 연결))).
전술한 내용을 기반으로 구조 요소는 특정 대화 상자 컨트롤이며 고유한 속성을 포함하고 중첩된 컨트롤을 포함할 수 있음을 이해할 수 있습니다. 이러한 범용 컨트롤의 속성 집합은 개발자의 상상력에 의해서만 제한됩니다.
물론 구조로 올라갈 수는 없지만 다차원 배열 에서 컨트롤의 속성을 설명할 수 있지만 일부 속성이 저장된 인덱스를 명확하게 기억해야 하기 때문에 처음에는 비용 효율적이지 않습니다. 그리고 배열은 이기종 데이터 유형을 포함할 수 없습니다. 절차적 프로그래밍에서 제어 요소를 구조를 통해서만 기술할 수 있음이 밝혀졌습니다. 즉, 구조 요소는 특정 제어 요소, 즉 고유한 속성을 가진 특정 대화 상자 개체입니다.
CCanvas의 문제는 GUI가 차트 창에 엄격하게 묶여 있다는 것입니다.
즉, 터미널 인터페이스 모듈 형태의 본격적인 창을 만들 수 없습니다.
그리고 자신만의 인터페이스 모듈을 작성하는 것은 매우 멋질 것입니다.
그러면 인터페이스를 일정에 바인딩하기 위해 역 쓰레기가 발생합니다. 예를 들어 타임스탬프와 가격에 엄격하게 연결된 버튼을 만듭니다.
여기에 모든 테이블, 탭, 메뉴 및 휘파람과 함께 비행 중에 작성된 별도의 GUI가 있습니다. C# 또는 BASIC에서도 가능합니다. 그리고 차트 내부 - 이것은 외부 응용 프로그램에 대한 중요한 문제입니다.
모든 대화 요소(양식, 제어 요소(버튼, 목록, 그림))에는 몇 가지 속성이 있습니다. 절차적 프로그래밍은 "속성" 또는 "필드"의 개념을 정의하지 않습니다. 절차적 프로그래밍에는 함수와 변수(전역 또는 지역)가 있습니다. 그러나 변수는 공유되므로 각 개별 컨트롤의 속성을 설명하는 데 사용할 수 없습니다. 그럼 탈출구는? 네 간단합니다 - 구조!
예, 구조는 제어 요소의 필수 속성에 대한 설명과 중첩된(인정하는) 제어 요소의 배열을 가질 수 있습니다.
모든 것이 대화 상자 배열에 저장됩니다.
보다 보편적으로 만들 수 있습니다. 제어 설명 구조는 속성 배열과 종속 요소 배열의 두 가지 배열로 구성됩니다. 속성 배열은 속성-값 쌍의 구조 배열입니다. 이 접근 방식을 사용하면 각각의 새 컨트롤에 임의 의 속성 집합이 있을 수 있습니다. 그러나 처리에 편리하지 않습니다. 크기, 위치, 색상, 프레임 등 제어 요소의 특정 속성을 구조에 표시하는 것이 더 논리적입니다. 모든 제어 요소에 필요한 모든 것입니다.
글쎄, 구조에 이 요소의 픽셀 배열도 있을 것입니다.
마우스 이벤트가 수신되면 루프는 모든 배열을 반복하여 커서가 특정 컨트롤에 닿았는지 확인합니다. 확인은 마지막에서 처음으로 수행됩니다.
커서가 어느 컨트롤에 도달했는지 밝혀지자 마자 이 배열 요소가 다시 그리기 기능으로 전송되고 리소스 배열을 업데이트하고 차트의 그림을 업데이트합니다.
1. 창, 버튼, 체크박스와 같은 기본 컨트롤의 가장 간단한 구조를 설계했다고 가정합니다. 각각은 구성 요소 집합인 개체로 구성됩니다. 확인란 - 기본, 텍스트, 아이콘. 버튼 - 기본, 텍스트, 아이콘 등. 각 요소의 각 개체에는 고유한 속성 집합이 있어야 합니다. 구조체나 클래스로 작성해도 되지만 제 생각에는 불편합니다. 왜요? - 창에 배치하면 커서가 있는 캔버스에서 찾아야 하기 때문입니다. 커서를 움직이면 초점이 맞춰져야 합니다. 이를 위해 현재 좌표는 배열에 있어야 합니다. 그리고 모든 속성(현재 좌표 포함)이 하나의 배열에 있으면 더 편리합니다. 따라서 커서의 초점에 속하는 캔버스의 모든 요소 속성에 즉시 액세스할 수 있습니다. 또한 요소 배열을 반복하는 것이 더 쉽습니다.
즉, 커서가 적중한 요소에 대한 검색 루프에서 하나의 배열을 우회하는 것이 더 쉽습니다. 그리고 이 배열이 전역적이면 훨씬 더 편리합니다. 그런 다음 모든 기능에서 필요한 정보를 가져올 수 있으며 모든 기능에서 필요한 속성, 필요한 요소의 값을 변경할 수 있습니다.
이것은 요소에 대한 가장 짧고 효율적인 액세스와 가장 빠른 처리입니다. 이것이 제 핵심입니다.
2. 그러나 전문가의 변덕을 알기에 표준 OOP를 최대한 모방하기 위해 노력하므로 이 기술을 제공하지 않습니다.
3. 픽셀 배열은 어디에도 저장할 필요가 없습니다. 배열에 있는 요소의 매개변수에 따라 필요한 순간에 빌드됩니다. 예: 창을 다시 그려야 합니다. 다시 그리기 기능을 호출합니다. 이 함수는 요소 배열에 액세스하고, 모든 속성을 보고, 픽셀 배열을 선언하고, 크기를 계산하고, 요소에 대한 루프에서 개체를 순차적으로 그리고 ResourceCreate()를 호출합니다. 모두.
4. 커서 아래에 있는 요소는 다시 그리기를 위해 동일한 기능으로 전송됩니다. 알림(요소 다시 그리기 플래그)과 요소 배열의 번호를 수신합니다. 다음으로 함수는 ResourceReadImage()를 통해 필요한 리소스를 호출하고 픽셀 배열에 푸시한 다음 픽셀 배열 내부에서 원하는 요소의 영역을 찾아 모든 개체를 다시 그립니다. ResourceCreate()를 통해 저장합니다. 모두.
1. 창, 버튼, 체크박스와 같은 기본 컨트롤의 가장 간단한 구조를 설계했다고 가정합니다. 각각은 구성 요소 집합인 개체로 구성됩니다. 확인란 - 기본, 텍스트, 아이콘. 버튼 - 베이스, 텍스트, 아이콘 등. 각 요소의 각 개체에는 고유한 속성 집합이 있어야 합니다. 구조체나 클래스로 작성해도 되지만 제 생각에는 불편합니다. 왜요? - 창에 배치하면 커서가 있는 캔버스에서 찾아야 하기 때문입니다. 커서를 움직이면 초점이 맞춰져야 합니다. 이를 위해 현재 좌표는 배열에 있어야 합니다. 그리고 모든 속성(현재 좌표 포함)이 하나의 배열에 있으면 더 편리합니다. 따라서 커서의 초점에 있는 캔버스의 모든 요소 속성에 즉시 액세스할 수 있습니다. 또한 요소 배열을 반복하는 것이 더 쉽습니다.
즉, 커서가 적중한 요소에 대한 검색 루프에서 하나의 배열을 우회하는 것이 더 쉽습니다. 그리고 이 배열이 전역적이면 훨씬 더 편리합니다. 그런 다음 모든 기능에서 필요한 정보를 가져올 수 있으며 모든 기능에서 필요한 속성, 필요한 요소의 값을 변경할 수 있습니다.
이것은 요소에 대한 가장 짧고 효율적인 액세스와 가장 빠른 처리입니다. 이것이 제 핵심입니다.
2. 그러나 전문가의 변덕을 알기에 표준 OOP를 최대한 모방하기 위해 노력하므로 이 기술을 제공하지 않습니다.
3. 픽셀 배열은 어디에도 저장할 필요가 없습니다. 배열에 있는 요소의 매개변수에 따라 필요한 순간에 빌드됩니다. 예: 창을 다시 그려야 합니다. 다시 그리기 기능을 호출합니다. 이 함수는 요소 배열에 액세스하고, 모든 속성을 보고, 픽셀 배열을 선언하고, 크기를 계산하고, 요소에 대한 루프에서 개체를 순차적으로 그리고 ResourceCreate()를 호출합니다. 모두.
4. 커서 아래에 있는 요소는 다시 그리기를 위해 동일한 기능으로 전송됩니다. 알림(요소 다시 그리기 플래그)과 요소 배열의 번호를 수신합니다. 다음으로 함수는 ResourceReadImage()를 통해 필요한 리소스를 호출하고 픽셀 배열에 푸시한 다음 픽셀 배열 내부에서 원하는 요소의 영역을 찾아 모든 개체를 다시 그립니다. ResourceCreate()를 통해 저장합니다. 모두.
사실 이것은 건설 기술에 관계없이 일어나야 합니다. 그것은 다른 방식으로 만 감지 될 수 있습니다. 귀하의 경우 배열을 반복하고 커서가 현재 켜져 있는 컨트롤을 결정합니다. 위의 내용을 기반으로 인덱스를 결정하면 발견된 요소의 속성을 즉시 볼 수 있습니다. 그러나 어떻게 하나의 큰 배열에 다양한 유형의 데이터 를 저장할 수 있습니까?
사실 이것은 건설 기술에 관계없이 일어나야 합니다. 다르게 인식될 수 밖에 없습니다. 귀하의 경우 배열을 반복하고 커서가 현재 켜져 있는 컨트롤을 결정합니다. 위의 내용을 기반으로 인덱스를 결정하면 찾은 요소의 속성을 즉시 볼 수 있습니다. 그러나 어떻게 하나의 큰 배열에 다양한 유형의 데이터 를 저장할 수 있습니까?
원칙적으로 유형을 일반화할 수 있습니다. 대부분의 객체 속성이 int 유형이면 나쁜 일이 일어나지 않는다는 결론에 도달했습니다. 다른 모든 축약형(그래프 객체의 속성에는 double이 거의 없음)은 단순화를 위해 생략했습니다. 기억의 "과잉 지출"은 너무 미미하여 그것에 대해 생각하는 것이 의미가 없습니다. 물론 전문성을 높이기 위해 그런 신성모독은 함부로 할 수 없다.)) 하지만, 지금은 21세기와 불을 위협하지 않는다.))
나는 개체의 이름을 번호로 만들고 개체 속성의 일반 행에 넣습니다.
다른 데이터 유형이 필요한 유일한 곳은 컨트롤의 매개변수였습니다. 거기에서 매개변수의 속성을 저장하는 두 번째 코어를 만들었으며 값 자체는 문자열 유형으로 되어 있어 무엇이든 쉽게(더 정확하게는 매개변수 속성에 기록된 것으로) 캐스팅할 수 있습니다.
추신. "컨트롤의 매개변수"는 요소에 의해 제어되는 매개변수를 의미합니다.1. 창, 버튼, 체크박스와 같은 기본 컨트롤의 가장 간단한 구조를 설계했다고 가정합니다. 각각은 구성 요소 집합인 개체로 구성됩니다. 확인란 - 기본, 텍스트, 아이콘. 버튼 - 베이스, 텍스트, 아이콘 등. 각 요소의 각 개체에는 고유한 속성 집합이 있어야 합니다. 구조체나 클래스로 작성해도 되지만 제 생각에는 불편합니다. 왜요? - 창에 배치하면 커서가 있는 캔버스에서 찾아야 하기 때문입니다. 커서를 움직이면 초점이 맞춰져야 합니다. 이를 위해 현재 좌표는 배열에 있어야 합니다. 그리고 모든 속성(현재 좌표 포함)이 하나의 배열에 있으면 더 편리합니다. 따라서 커서의 초점에 있는 캔버스의 모든 요소 속성에 즉시 액세스할 수 있습니다. 또한 요소 배열을 반복하는 것이 더 쉽습니다.
즉, 커서가 적중한 요소에 대한 검색 루프에서 하나의 배열을 우회하는 것이 더 쉽습니다. 그리고 이 배열이 전역적이면 훨씬 더 편리합니다. 그런 다음 모든 기능에서 필요한 정보를 가져올 수 있으며 모든 기능에서 필요한 속성, 필요한 요소의 값을 변경할 수 있습니다.
이것은 요소에 대한 가장 짧고 효율적인 액세스와 가장 빠른 처리입니다. 이것이 제 핵심입니다.
2. 그러나 전문가의 변덕을 알기에 표준 OOP를 최대한 모방하기 위해 노력하므로 이 기술을 제공하지 않습니다.
3. 픽셀 배열은 어디에도 저장할 필요가 없습니다. 배열에 있는 요소의 매개변수에 따라 필요한 순간에 빌드됩니다. 예: 창을 다시 그려야 합니다. 다시 그리기 기능을 호출합니다. 이 함수는 요소 배열에 액세스하고, 모든 속성을 보고, 픽셀 배열을 선언하고, 크기를 계산하고, 요소에 대한 루프에서 개체를 순차적으로 그리고 ResourceCreate()를 호출합니다. 모두.
4. 커서 아래에 있는 요소는 다시 그리기를 위해 동일한 기능으로 전송됩니다. 알림(요소 다시 그리기 플래그)과 요소 배열의 번호를 수신합니다. 다음으로 함수는 ResourceReadImage()를 통해 필요한 리소스를 호출하고 픽셀 배열에 푸시한 다음 픽셀 배열 내부에서 원하는 요소의 영역을 찾아 모든 개체를 다시 그립니다. 모두.
와우, 이 영원한 네거티브 to oops, 바로 라인을 통해
그가 어떻게 거기에 왔는지 궁금해 한 적이 있습니까? 사실 절차적 스타일로 작성하고 OOP에 대해 모르는 많은 사람들이 기능을 그룹화하려는 욕구에 직면하게 되며, 이러한 욕구는 이러한 기능을 하나의 메모리 영역으로 결합하고 참조하려는 욕구로 발전합니다. 변수에 저장된 기능이 있는 섹션에 대한 물리적 링크. 그런 다음 코드를 복제하지 않고(상속을 얻음) 선택한 함수 묶음을 변경하려는 욕구가 있습니다. 그래서 처음에는 절차적 스타일에만 익숙해지고 시간이 지나면서 질문을 합니다. µl(다중 상속에 대한 참조)에 왜 그렇게 많은 제한이 있습니까?
일반적으로 절차 스타일에 익숙해지면 재교육이 매우 어려울 것이기 때문에 OOP를 즉시 가르치는 것이 더 쉽다고 믿어집니다 ( 대부분의 사람들에게). 처음에는 절차적 스타일이었습니다... 위에서 설명했습니다.
위협 OOP에는 절차적 코드 수준에서 OOP에 익숙한 것으로 추정되는 다양성이 있으며 실제로 OOP를 최대한 사용합니다.
클래스는 기본 배열을 유지하면서 다시 작성하고 추가할 수 있는 함수의 메모리(테이블)에 대한 참조 + 변수에 대한 참조입니다. 그리고 이미 다른 것을 잊어 버렸습니다 .... (32 바이트는 무게가 있어야 함)
검색은 영원한 작업입니다. 최근에 내장된 정렬 기능을 Red 정렬(템플릿 중 하나)과 비교했는데 특정 조건에서 3-6배의 속도를 잃습니다(내장된 것이 손실됨 =)
ON GUI 표준 방법이 있다고 생각합니다.
,
와우, 이 영원한 네거티브 to oops, 바로 라인을 통해
그가 어떻게 거기에 왔는지 궁금해 한 적이 있습니까? 사실 절차적 스타일로 작성하고 OOP에 대해 모르는 많은 사람들이 기능을 그룹화하려는 욕구에 직면하게 되며, 이러한 욕구는 이러한 기능을 하나의 메모리 영역으로 결합하고 참조하려는 욕구로 발전합니다. 변수에 저장된 기능이 있는 섹션에 대한 물리적 링크. 그런 다음 코드를 복제하지 않고(상속을 얻음) 선택한 함수 묶음을 변경하려는 욕구가 있습니다. 그래서 처음에는 절차적 스타일에만 익숙해지고 시간이 지나면서 질문을 합니다. µl(다중 상속에 대한 참조)에 왜 그렇게 많은 제한이 있습니까?
일반적으로 절차 스타일에 익숙해지면 재교육이 매우 어려울 것이기 때문에 OOP를 즉시 가르치는 것이 더 쉽다고 믿어집니다 (대부분의 사람들에게). 처음에는 절차적 스타일이었습니다... 위에서 설명했습니다.
위협 OOP에는 절차적 코드 수준에서 OOP에 익숙한 것으로 추정되는 다양성이 있으며 실제로 OOP를 최대한 사용합니다.
클래스는 기본 배열을 유지하면서 다시 작성하고 추가할 수 있는 함수의 메모리(테이블)에 대한 참조 + 변수에 대한 참조입니다. 그리고 이미 다른 것을 잊어 버렸습니다 .... (32 바이트는 무게가 있어야 함)
검색은 영원한 작업입니다. 최근에 내장된 정렬 기능을 Red 정렬(템플릿 중 하나)과 비교했는데 특정 조건에서 3-6배의 속도를 잃습니다(내장된 것이 손실됨 =)
ON GUI 표준 방법이 있다고 생각합니다.
,
나는 OOP의 개념에 대해 부정적인 태도를 갖고 있지 않다. 나는 그녀의 팬이다. 나는 기준에 대해 부정적인 태도를 가지고 있다. 더 정확하게는 정신없이 따라가는 것입니다.)
그렇지 않으면 나는 OOP를 지지합니다. 그러나 단순화를 위해.