Peter는 mql 외에는 프로그래밍하지 않는다고 감히 가정합니다. 모든 최신 버전의 언어에는 Java, Kotlin, Sharp, Python, C++ 등의 클래스 작업에 대한 지식이 필요합니다. 1C에서도 고정 유형의 객체 형태로 클래스의 유사성이 있습니다. 하지만 그게 다야, 탈선.
내 관점에서 인터페이스 빌드 시스템은 다음과 같아야 합니다.
CForm Форма = new CForm;
Интерфейс.Добавить(Форма);
CButton КнопкаBUY= new CButton;
КнопкаBUY.Заголовок = "BUY" ;
КнопкаBUY.ЦветФона = clrBlue ;
КнопкаBUY.Позиция( 7 , 20 );
Форма.Добавить(КнопкаBUY);
즉, 인터페이스 생성은 선언적이어야 합니다. 다른 프로그래머가 인덱스 에 액세스하여 컨트롤의 속성에 대한 설명을 추가하는 방법을 상상조차 할 수 없습니다.....
Peter는 mql 외에는 프로그래밍하지 않는다고 감히 가정합니다. 모든 최신 버전의 언어에는 Java, Kotlin, Sharp, Python, C++ 등의 클래스 작업에 대한 지식이 필요합니다. 1C에서도 고정 유형의 객체 형태로 클래스의 유사성이 있습니다. 그러나 그것은, 탈선입니다.
내 관점에서 인터페이스 빌드 시스템은 다음과 같아야 합니다.
즉, 인터페이스 생성은 선언적이어야 합니다. 다른 프로그래머가 인덱스에 액세스하여 제어 요소의 속성에 대한 설명을 추가하는 방법을 상상조차 할 수 없습니다.....
초보자는 말할 것도 없고 평범한 프로그래머에게도 퍼즐이 될 것이라고 확신합니다.
많은 요소 및 / 또는 속성이 인덱스에 의존하는 경우 문제없이 또는 그 반대의 경우도 각 개별을 참조하여 발보를 작성하기가 어렵습니다.
1. Peter, 핵심은 요소 속성의 전역 행렬, 요소 값의 전역 행렬, 전역 종속성 행렬, 그림의 전역 행렬로 구성됩니다.
2. 속성을 더 추가해야 하는 경우 행렬의 차원이 증가합니다.
3. 속성에 대한 액세스는 셀에 이름이 없기 때문에 인덱스에 의해 엄격하게 수행됩니다.
적어도 필드 이름에 대한 구조에서는 주소 지정이 가능합니다.
피터, 너... 거인...
예를 들어 다음과 같이 표시됩니다(단순화됨).
4. 사실상 "class"는 전역 배열의 특정 문자열이며 더 "인간적인" 얼굴입니다. 클래스는 인덱스가 아니라 이름으로 액세스할 수 있는 이해 가능한 속성 집합을 사용하여 고유한 데이터 개체를 생성하도록 설계되었습니다. 클래스는 제네릭 형식 생성자일 뿐입니다.
따라서 거의 모든 컨트롤에 있는 가장 일반적인 속성을 포함하는 기본 컨트롤을 만듭니다.
이를 기반으로 특수 개체를 만들 수 있습니다.
즉, 각 후속 컨트롤 유형은 기본 유형에 필요한 속성을 추가하기만 하면 됩니다.
그리고 앞서 쓴 것처럼 주요 속성은 기본 컨트롤러에 저장되어 있으므로 CControl이라는 데이터 유형 을 확인할 때 커서의 "적중"을 컨트롤로 우회하는 작업이 수행됩니다. 원하는 개체를 찾으면 프로그램은 루프에서 프로그램이 원하는 배열 줄에 있는 것처럼 프로그램의 지점이 이미 개체 자체에 있기 때문에 이 개체의 속성에 즉시 액세스할 수 있습니다.
1. 핵심은 하나의 글로벌 매트릭스입니다. 2차원. 에 의해 만들어진 핵 생성할 윈도우와 요소가 마크업 언어로 작성된 파일을 읽는 함수.
2. 아니요, 행렬의 차원은 일정합니다. 2차원만.
3. 커널에 있는 객체의 속성이 정렬됩니다. 각각 고유한 인덱스가 있습니다. 인덱스는 정의를 통해 이름이 지정됩니다. 객체의 속성 수가 증가함에 따라 행렬의 너비가 커집니다. 성장을 억제하고 내부의 물체를 압축하는 방법이 있습니다.
4. 객체에 대한 설명으로서 클래스는 좋지만 메커니즘(코드)이 커널과 함께 더 효율적으로 작동합니다. 그러나 그것은 중요하지 않습니다. 누가 편해.
객체 속성(기본 클래스의 주요 속성, 나머지는 상속자)의 흩어져 있는 설명과 저장으로 인해 액세스 및 처리가 더 복잡해집니다. 가시성 제한, 접근 수식어, 외국어를 추가하면 메커니즘뿐만 아니라 개발 효율성도 크게 떨어집니다. 그러나 이것은 IMHO입니다.
Реter Konow : 1. 핵심은 하나의 글로벌 매트릭스입니다. 2차원. 에 의해 만들어진 핵 생성할 창과 요소가 마크업 언어로 표시된 파일을 읽는 함수입니다.
2. 아니요, 행렬의 차원은 일정합니다. 2차원만.
3. 커널에 있는 객체의 속성이 정렬됩니다. 각각 고유한 인덱스가 있습니다. 인덱스는 정의를 통해 이름이 지정됩니다. 객체의 속성 수가 증가함에 따라 행렬의 너비가 커집니다. 성장을 억제하고 내부의 물체를 압축하는 방법이 있습니다.
4. 객체에 대한 설명으로서 클래스는 좋지만, 메커니즘(코드)이 커널에서 더 효율적으로 작동합니다. 그러나 그것은 중요하지 않습니다. 누가 편해.
객체 속성(기본 클래스의 주요 속성, 나머지는 상속자)의 흩어져 있는 설명과 저장으로 인해 액세스 및 처리가 더 복잡해집니다 . 가시성 제한, 접근 수식어 및 외국어를 추가하면 메커니즘뿐만 아니라 개발 효율성도 크게 떨어집니다. 그러나 이것은 IMHO입니다.
전혀 복잡하지 않고 그것이 바로 수업의 아름다움이자 힘입니다. 다음 각각은 원래 개체의 기능을 기반으로 기능을 구축합니다. 결과적으로 모든 기본 기능(포커스, 클릭, 요소 너머로 이동, 드래그, 그리기)-이 모든 것이 기본 개체를 기반으로 구현됩니다. 추가 개발 및 수정, 새로운 컨트롤 개발 - 이 모든 것은 기본 기능에 어떤 식으로든 영향을 미치지 않습니다. 이는 라이브러리의 "핵심" 수준에서 귀하의 언어로 생성되기 때문입니다. 이 경우 개체에는 특정 속성에 필요한 데이터 유형 이 정확히 포함됩니다.
"커널은 생성할 창과 요소가 있는 마크업 언어로 작성된 파일을 읽는 특수 기능에 의해 구축됩니다." - 그냥 주석입니다. 즉, 모든 속성을 저장하는 행렬이 있고 속성이 있는 행렬을 정확히 읽는 방법을 나타내는 마크업 파일도 있습니다. " 인덱스는 정의를 통해 명명됩니다 " - 각 인덱스는 정의에 단단히 묶여 있습니다. 실수로 추가 필드를 삽입하면 결과적으로 속성이 이동하게 됩니다. "객체의 속성 수가 증가함에 따라 행렬의 너비가 커집니다." - 이것은 차원에 대해 말하면서 의미한 것입니다(죄송합니다. 용어를 잘못 적용했습니다). 데이터 개체를 클래스로 생성하면 이러한 모든 복잡성을 피할 수 있습니다. 그리고 이것들은 실제로 필요하지 않은 실제 어려움입니다. 우리는 나중에 성공적으로 극복하기 위해 스스로 어려움을 만드는 방법을 알고 있습니다.
예, 클래스를 계층적으로 만들 필요가 없으며 실제로 사용할 필요도 없습니다. 그러나 불필요한 데이터 흐름을 제거하기 위해 구조를 사용하는 것이 좋습니다. 임호
Peter, 당신은 당신의 스타일로 GUI 라이브러리를 만드는 일을 훌륭하게 해냈습니다. 그러나 이 사례를 게시할 계획이라면 다른 기술을 위해 모든 것을 다시 할 가치가 있습니다. 나는 당신을 도울 준비가 되어 있고 당신의 도서관의 모든 힘을 새로운 방향으로 옮기기 위해 단계별로 당신을 도울 준비가 되어 있습니다.
전혀 복잡하지 않고 그것이 바로 수업의 아름다움이자 힘입니다. 다음 각각은 원래 개체의 기능을 기반으로 기능을 구축합니다. 결과적으로 모든 기본 기능(포커스, 클릭, 요소 너머로 이동, 드래그, 그리기)-이 모든 것이 기본 개체를 기반으로 구현됩니다. 추가 개발 및 수정, 새로운 컨트롤 개발 - 이 모든 것은 기본 기능에 어떤 식으로든 영향을 미치지 않습니다. 이는 라이브러리의 "핵심" 수준에서 귀하의 언어로 생성되기 때문입니다. 이 경우 개체에는 특정 속성에 필요한 데이터 유형 이 정확히 포함됩니다.
"커널은 생성할 창과 요소가 있는 마크업 언어로 작성된 파일을 읽는 특수 기능에 의해 구축됩니다." - 그냥 주석입니다. 즉, 모든 속성을 저장하는 행렬이 있고 속성이 있는 행렬을 정확히 읽는 방법을 지정하는 마크업 파일도 있습니다... 데이터 개체를 클래스로 생성하면 이러한 모든 어려움을 피할 수 있습니다. 그리고 이것들은 실제로 필요하지 않은 실제 어려움입니다. 우리는 나중에 성공적으로 극복하기 위해 스스로 어려움을 만드는 방법을 알고 있습니다.
예, 클래스를 계층적으로 만들 필요가 없으며 실제로 사용할 필요도 없습니다. 그러나 불필요한 데이터 흐름을 제거하기 위해 구조를 사용하는 것이 좋습니다. 임호
Peter, 당신은 당신의 스타일로 GUI 라이브러리를 만드는 일을 훌륭하게 해냈습니다. 그러나 이 사례를 게시할 계획이라면 다른 기술을 위해 모든 것을 다시 할 가치가 있습니다. 나는 당신을 도울 준비가 되어 있고 당신의 도서관의 모든 힘을 새로운 방향으로 옮기기 위해 단계별로 당신을 도울 준비가 되어 있습니다.
알다시피, 나는 여기에서 나와 다른 사람들의 결정을 실행하는 것에 대해 너무 많이 논쟁을 벌여서 지쳤습니다. )) 단순히, 정말 피곤합니다. 내 생각은 매트릭스에 더 적응하고, 다른 사람의 생각은 클래스에 ... 이것에 창을 끊지 마십시오.
일반적으로 나는 규칙을 변경하거나 단순화하고 일반적인 과정에서 벗어나 다른 사람의 것보다 내 자신을 주장하는 경향이 있습니다. 날 바꾸지 마
제안 고마워. GUI 개발에서 자신의 길을 갈 수 있습니다. 나는 이미 내 길을 갔고 다른 스타일로 그것을 반복하는 요점을 보지 못합니다. 마크업 언어가 있습니다. 비주얼 편집기로 가는 몇 단계와 출판 1주일 전입니다. 작업 표시줄을 다시 실행하고 사소한 버그를 잡아야 합니다. 그러면 당신은 내 작업을 평가할 것입니다. 나는 그것이 모두에게 유용하기를 바랍니다.
추신. 게시 후 솔루션에 대해 더 자세히 설명할 수 있으며 이는 수업에서 상대방을 만드는 데 도움이 될 수 있습니다.
Реter Konow : 알다시피, 나는 여기에서 나와 다른 사람들의 결정을 실행하는 것에 대해 너무 많이 논쟁을 벌여서 지쳤습니다. )) 단순히, 정말 피곤합니다. 내 생각은 매트릭스에 더 적응하고, 다른 사람의 생각은 클래스에 ... 이것에 창을 끊지 마십시오.
일반적으로 나는 규칙을 변경하거나 단순화하는 경향이 있으며 일반적인 과정에서 벗어나 다른 사람의 것보다 내 것을 주장하는 경향이 있습니다. 날 바꾸지 마
제안 고마워. GUI 개발에서 자신의 길을 갈 수 있습니다. 나는 이미 내 방식대로 해왔고 다른 스타일로 그것을 반복하는 것은 의미가 없습니다. 마크업 언어가 있습니다. 비주얼 편집기로 가는 몇 단계와 출판 1주일 전입니다. 작업 표시줄을 다시 실행하고 사소한 버그를 잡아야 합니다. 그러면 당신은 내 작업을 평가할 것입니다. 나는 그것이 모두에게 유용하기를 바랍니다.
핵심은 매트릭스입니다. 여기에는 개체의 모든 속성이 포함됩니다.
Peter, 현재 버전뿐만 아니라 GUI를 작성한 경험과 예가 있습니까?
당신은 다른 패러다임을 완전히 부정하지만 당신의 모델이 GUI 구현에 가장 성공적이라고 주장합니다. 이 진술은 매우 논쟁의 여지가 있습니다.
그려진 선의 각도, 교차점 및 타원의 비율을 수정하는 표시기를 만드십시오. 앵커 포인트가 미래에 설정되는 동안
2주 후, 그리고 얼마나 지독한 칠면조 날..
추신/인터페이스를 그리는 사람들은 거래에 전혀 관여하지 않는 것 같습니다
그려진 선의 각도, 교차점 및 타원의 비율을 수정하는 표시기를 만드십시오. 앵커 포인트가 미래에 설정되는 동안
2주 후, 그리고 얼마나 지독한 칠면조 날..
추신/인터페이스를 그리는 사람들은 거래에 전혀 관여하지 않는 것 같습니다
맥스, 절반의 경우에 그렇다고 감히 말할 수 있습니다. 상인은 프로그래머가 될 필요가 전혀 없으며 프로그래머는 상인이 될 필요가 전혀 없습니다.
Peter는 mql 외에는 프로그래밍하지 않는다고 감히 가정합니다. 모든 최신 버전의 언어에는 Java, Kotlin, Sharp, Python, C++ 등의 클래스 작업에 대한 지식이 필요합니다. 1C에서도 고정 유형의 객체 형태로 클래스의 유사성이 있습니다. 하지만 그게 다야, 탈선.
내 관점에서 인터페이스 빌드 시스템은 다음과 같아야 합니다.
즉, 인터페이스 생성은 선언적이어야 합니다. 다른 프로그래머가 인덱스 에 액세스하여 컨트롤의 속성에 대한 설명을 추가하는 방법을 상상조차 할 수 없습니다.....
초보자는 말할 것도 없고 평범한 프로그래머에게도 퍼즐이 될 것이라고 확신합니다.
Peter는 mql 외에는 프로그래밍하지 않는다고 감히 가정합니다. 모든 최신 버전의 언어에는 Java, Kotlin, Sharp, Python, C++ 등의 클래스 작업에 대한 지식이 필요합니다. 1C에서도 고정 유형의 객체 형태로 클래스의 유사성이 있습니다. 그러나 그것은, 탈선입니다.
내 관점에서 인터페이스 빌드 시스템은 다음과 같아야 합니다.
즉, 인터페이스 생성은 선언적이어야 합니다. 다른 프로그래머가 인덱스에 액세스하여 제어 요소의 속성에 대한 설명을 추가하는 방법을 상상조차 할 수 없습니다.....
초보자는 말할 것도 없고 평범한 프로그래머에게도 퍼즐이 될 것이라고 확신합니다.
많은 요소 및 / 또는 속성이 인덱스에 의존하는 경우 문제없이 또는 그 반대의 경우도 각 개별을 참조하여 발보를 작성하기가 어렵습니다.
행렬은 루프의 중첩이고 중첩 루프는 시간입니다. IMHO, 비꼬는 것이 아니라 논리적인 추론일 뿐입니다.
1. Peter, 핵심은 요소 속성의 전역 행렬, 요소 값의 전역 행렬, 전역 종속성 행렬, 그림의 전역 행렬로 구성됩니다.
2. 속성을 더 추가해야 하는 경우 행렬의 차원이 증가합니다.
3. 속성에 대한 액세스는 셀에 이름이 없기 때문에 인덱스에 의해 엄격하게 수행됩니다.
적어도 필드 이름에 대한 구조에서는 주소 지정이 가능합니다.
피터, 너... 거인...
예를 들어 다음과 같이 표시됩니다(단순화됨).
4. 사실상 "class"는 전역 배열의 특정 문자열이며 더 "인간적인" 얼굴입니다. 클래스는 인덱스가 아니라 이름으로 액세스할 수 있는 이해 가능한 속성 집합을 사용하여 고유한 데이터 개체를 생성하도록 설계되었습니다. 클래스는 제네릭 형식 생성자일 뿐입니다.
따라서 거의 모든 컨트롤에 있는 가장 일반적인 속성을 포함하는 기본 컨트롤을 만듭니다.
이를 기반으로 특수 개체를 만들 수 있습니다.
즉, 각 후속 컨트롤 유형은 기본 유형에 필요한 속성을 추가하기만 하면 됩니다.
그리고 앞서 쓴 것처럼 주요 속성은 기본 컨트롤러에 저장되어 있으므로 CControl이라는 데이터 유형 을 확인할 때 커서의 "적중"을 컨트롤로 우회하는 작업이 수행됩니다. 원하는 개체를 찾으면 프로그램은 루프에서 프로그램이 원하는 배열 줄에 있는 것처럼 프로그램의 지점이 이미 개체 자체에 있기 때문에 이 개체의 속성에 즉시 액세스할 수 있습니다.
1. 핵심은 하나의 글로벌 매트릭스입니다. 2차원. 에 의해 만들어진 핵 생성할 창과 요소가 마크업 언어로 표시된 파일을 읽는 함수입니다.
전혀 복잡하지 않고 그것이 바로 수업의 아름다움이자 힘입니다. 다음 각각은 원래 개체의 기능을 기반으로 기능을 구축합니다. 결과적으로 모든 기본 기능(포커스, 클릭, 요소 너머로 이동, 드래그, 그리기)-이 모든 것이 기본 개체를 기반으로 구현됩니다. 추가 개발 및 수정, 새로운 컨트롤 개발 - 이 모든 것은 기본 기능에 어떤 식으로든 영향을 미치지 않습니다. 이는 라이브러리의 "핵심" 수준에서 귀하의 언어로 생성되기 때문입니다. 이 경우 개체에는 특정 속성에 필요한 데이터 유형 이 정확히 포함됩니다.
"커널은 생성할 창과 요소가 있는 마크업 언어로 작성된 파일을 읽는 특수 기능에 의해 구축됩니다." - 그냥 주석입니다. 즉, 모든 속성을 저장하는 행렬이 있고 속성이 있는 행렬을 정확히 읽는 방법을 나타내는 마크업 파일도 있습니다. " 인덱스는 정의를 통해 명명됩니다 " - 각 인덱스는 정의에 단단히 묶여 있습니다. 실수로 추가 필드를 삽입하면 결과적으로 속성이 이동하게 됩니다. "객체의 속성 수가 증가함에 따라 행렬의 너비가 커집니다." - 이것은 차원에 대해 말하면서 의미한 것입니다(죄송합니다. 용어를 잘못 적용했습니다). 데이터 개체를 클래스로 생성하면 이러한 모든 복잡성을 피할 수 있습니다. 그리고 이것들은 실제로 필요하지 않은 실제 어려움입니다. 우리는 나중에 성공적으로 극복하기 위해 스스로 어려움을 만드는 방법을 알고 있습니다.
예, 클래스를 계층적으로 만들 필요가 없으며 실제로 사용할 필요도 없습니다. 그러나 불필요한 데이터 흐름을 제거하기 위해 구조를 사용하는 것이 좋습니다. 임호
Peter, 당신은 당신의 스타일로 GUI 라이브러리를 만드는 일을 훌륭하게 해냈습니다. 그러나 이 사례를 게시할 계획이라면 다른 기술을 위해 모든 것을 다시 할 가치가 있습니다. 나는 당신을 도울 준비가 되어 있고 당신의 도서관의 모든 힘을 새로운 방향으로 옮기기 위해 단계별로 당신을 도울 준비가 되어 있습니다.
전혀 복잡하지 않고 그것이 바로 수업의 아름다움이자 힘입니다. 다음 각각은 원래 개체의 기능을 기반으로 기능을 구축합니다. 결과적으로 모든 기본 기능(포커스, 클릭, 요소 너머로 이동, 드래그, 그리기)-이 모든 것이 기본 개체를 기반으로 구현됩니다. 추가 개발 및 수정, 새로운 컨트롤 개발 - 이 모든 것은 기본 기능에 어떤 식으로든 영향을 미치지 않습니다. 이는 라이브러리의 "핵심" 수준에서 귀하의 언어로 생성되기 때문입니다. 이 경우 개체에는 특정 속성에 필요한 데이터 유형 이 정확히 포함됩니다.
"커널은 생성할 창과 요소가 있는 마크업 언어로 작성된 파일을 읽는 특수 기능에 의해 구축됩니다." - 그냥 주석입니다. 즉, 모든 속성을 저장하는 행렬이 있고 속성이 있는 행렬을 정확히 읽는 방법을 지정하는 마크업 파일도 있습니다... 데이터 개체를 클래스로 생성하면 이러한 모든 어려움을 피할 수 있습니다. 그리고 이것들은 실제로 필요하지 않은 실제 어려움입니다. 우리는 나중에 성공적으로 극복하기 위해 스스로 어려움을 만드는 방법을 알고 있습니다.
예, 클래스를 계층적으로 만들 필요가 없으며 실제로 사용할 필요도 없습니다. 그러나 불필요한 데이터 흐름을 제거하기 위해 구조를 사용하는 것이 좋습니다. 임호
Peter, 당신은 당신의 스타일로 GUI 라이브러리를 만드는 일을 훌륭하게 해냈습니다. 그러나 이 사례를 게시할 계획이라면 다른 기술을 위해 모든 것을 다시 할 가치가 있습니다. 나는 당신을 도울 준비가 되어 있고 당신의 도서관의 모든 힘을 새로운 방향으로 옮기기 위해 단계별로 당신을 도울 준비가 되어 있습니다.
알다시피, 나는 여기에서 나와 다른 사람들의 결정을 실행하는 것에 대해 너무 많이 논쟁을 벌여서 지쳤습니다. )) 단순히, 정말 피곤합니다. 내 생각은 매트릭스에 더 적응하고, 다른 사람의 생각은 클래스에 ... 이것에 창을 끊지 마십시오.
귀하의 경우 이것은 단순화가 아니라 실제 합병증입니다. 임호