나는 OOP와 커널의 하이브리드인 새로운 프리즘을 통해 프로그램에 설명된 개체 시스템에서 내 두뇌가 거의 터질 뻔했습니다. 먼저 GUI의 시스템을 새롭게 살펴보았습니다. 이러한 모든 매개변수 개체, 상태 개체, 이벤트 개체 및 처리기 개체를 통해. GUI와 그 기술은 나에게 알려져 있기 때문에 모든 것이 매우 명확하게 나타 났지만 시스템은 매우 복잡했습니다. 많은 매개변수, 바인딩 및 핸들러. 나는 그러한 체계가 저절로 생겨날 수 없다는 결론에 이르렀다. 그리고 자연 선택은 여기서 무력합니다.)))
그 이유는 다음과 같습니다.
각 매개변수는 n번째 파생 매개변수를 가질 수 있습니다. 예를 들어, X의 변화는 매 순간에 이 X의 값으로부터 무한히 많은 매개변수의 도함수를 일으킬 수 있습니다.
파생된 각 매개변수에는 핸들러와 다른 매개변수에 대한 링크가 있어야 합니다. 매개변수 자체는 존재하지 않습니다. 통신이 필요합니다.
연결이 다를 수 있으므로 다양한 필터 프로세서, 교정기 및 변환기가 나타날 수 있습니다.
시스템에 중요한 것으로 간주될 수 있는 이벤트가 무한정 많이 있습니다. 각각에는 고유한 속성, 링크 및 핸들러가 있습니다. 옵션은 셀 수 없습니다.
"커서" 개체에서 x, y라는 두 개의 매개변수를 가져옵니다. x와 y의 현재 값과 과거 값의 차이를 저장할 두 개의 파생 매개변수 개체를 만듭니다. (매개변수 객체는 단순한 변수가 아니라 고유한 속성이 있는 객체입니다.)
(1) x 및 y 값을 처리하고 핸들러 속성에 기록된 창 핸들 잡기 이벤트에서 현재 값과 과거 값 간의 차이를 가져오는 매개변수 개체에 대한 핸들러 개체를 만듭니다. (2 ) 볼륨 동일한 이벤트에서 파생된 매개변수에 차이를 씁니다.
우리는 객체에서 파생된 매개변수와 각 창 객체의 객체 매개변수 x, y 사이에 객체 링크를 생성하여 값이 전송됩니다.
바인딩 개체 이후에 각 창 개체의 개체 매개변수 x 및 y에서 값을 가져와 번들을 통과하는 값을 추가해야 하는 또 다른 핸들러 개체를 만듭니다.
따라서 이 시스템 덕분에 창의 핸들을 커서로 잡는 경우 창과 해당 개체의 좌표를 변경할 수 있습니다. 이동하려면 이 모든 것을 차트에서 MT 개체의 위치를 변경하는 ObjectSetInteger 처리기 함수와 연결해야 합니다.
Parameter Objects, Handler Objects 등 특수 블록 시스템을 연결하여 하나의 GUI 기능을 구현한 것입니다.
Core에서 이러한 시스템을 구축하는 것은 모든 것을 객체로 바꾸지 않고 일반 코드를 작성하는 것만큼 쉽지도 않고 더 어려울 수도 있습니다. 하지만 계속 파고들게..
추신. 창을 이동하려면 창 핸들을 누르고 커서를 이동하는 것을 등록하는 이벤트 개체도 "만들어"야 한다는 것을 추가하는 것을 잊었습니다. 그리고 이 Event-Object를 커서의 x,y 값의 Object-handler(파생 매개변수에 차이를 기록함)에 대한 링크와 연결하여 이 이벤트의 신호에서만 작동하도록 합니다.
ZYY. 그리고 각 Event Object에 대해 자신만의 핸들러 Object를 생성하고 연결해야 합니다.
ZYYY. 그리고 각 핸들러 객체에는 매개변수나 이벤트로 작업할 때 사용하는 고유한 속성이 있습니다. 따라서 템플릿이 있어야 합니다. 그렇지 않으면 이 모든 것을 만드는 데 "지칠 수 있습니다."))
"커서" 개체에서 x, y라는 두 개의 매개변수를 가져옵니다. x와 y의 현재 값과 과거 값의 차이를 저장할 두 개의 파생 매개변수 개체를 만듭니다. (매개변수 객체는 단순한 변수가 아니라 고유한 속성이 있는 객체입니다.)
(1) x 및 y 값을 처리하고 핸들러 속성에 기록된 창 핸들 잡기 이벤트에서 현재 값과 과거 값 간의 차이를 가져오는 매개변수 개체에 대한 핸들러 개체를 만듭니다. (2 ) 볼륨 동일한 이벤트에서 파생된 매개변수에 차이를 씁니다.
우리는 객체에서 파생된 매개변수와 각 창 객체의 객체 매개변수 x, y 사이에 객체 링크를 생성하여 값이 전송됩니다.
바인딩 개체 이후에 각 창 개체의 개체 매개변수 x 및 y에서 값을 가져와 번들을 통과하는 값을 추가해야 하는 또 다른 핸들러 개체를 만듭니다.
따라서 이 시스템 덕분에 창의 핸들을 커서로 잡는 경우 창과 해당 개체의 좌표를 변경할 수 있습니다. 이동하려면 이 모든 것을 차트에서 MT 개체의 위치를 변경하는 ObjectSetInteger 처리기 함수와 연결해야 합니다.
Parameter Objects, Handler Objects 등 특수 블록 시스템을 연결하여 하나의 GUI 기능을 구현한 것입니다.
Core에서 이러한 시스템을 구축하는 것은 모든 것을 객체로 바꾸지 않고 일반 코드를 작성하는 것만큼 쉽지도 않고 더 어려울 수도 있습니다. 하지만 계속 파고들게..
추신. 창을 이동하려면 창 핸들을 누르고 커서를 이동하는 것을 등록하는 이벤트 개체도 "만들어"야 한다는 것을 추가하는 것을 잊었습니다. 그리고 이 Event-Object를 커서의 x,y 값의 Object-handler(파생 매개변수에 차이를 기록함)에 대한 링크와 연결하여 이 이벤트의 신호에서만 작동하도록 합니다.
ZYY. 그리고 각 Event Object에 대해 자신만의 핸들러 Object를 생성하고 연결해야 합니다.
ZYYY. 그리고 각 핸들러 객체에는 매개변수나 이벤트로 작업할 때 사용하는 고유한 속성이 있습니다. 따라서 템플릿이 있어야 합니다. 그렇지 않으면 이 모든 것을 만드는 데 "지칠 수 있습니다."))
복잡한. 터무니없이 어렵습니다.
이 양식의 나머지 개체가 내부에 있는 양식의 주요 개체 - 좌표만 받습니다. 좌표를 변경하면 기본 양식 개체의 위치가 변경됩니다. 이 형식의 나머지 개체에는 형식 내에서 개체의 위치를 결정하는 상대 좌표가 주어집니다. 모든 개체는 형식에서 고유한 순서를 가지며 이 순서로 다시 작성됩니다. 모든 개체에는 그 안에 포함된 목록이 있습니다. 목록을 통해 콘텐츠에 액세스하면 각 콘텐츠에 shift 명령을 보낼 수 있습니다. 따라서 폼 객체에 이동 명령을 내리면 폼의 전체 내용으로 이동 명령이 체인을 따라 자동으로 전달된다. 즉, 양식에 대해서만 오프셋을 수행하고 나머지는 자동으로 오프셋됩니다. 각 양식 개체에 직접 시프트 명령을 줄 필요가 없습니다.
우리는 단 하나의 개체에 대해 모든 것을 수행합니다. 다른 모든 사람들은 그것을 반복할 것입니다. 양식 개체가 아무리 복잡하더라도 양식을 이동하는 단일 명령은 해당 양식의 전체 내용에 넘쳐납니다.
이 양식의 나머지 개체가 내부에 있는 양식의 주요 개체 - 좌표만 받습니다. 좌표를 변경하면 기본 양식 개체의 위치가 변경됩니다. 이 형식의 나머지 개체에는 형식 내에서 개체의 위치를 결정하는 상대 좌표가 주어집니다. 모든 개체는 형식에서 고유한 순서를 가지며 이 순서로 다시 작성됩니다. 모든 개체에는 그 안에 포함된 목록이 있습니다. 목록을 통해 콘텐츠에 액세스하면 각 콘텐츠에 shift 명령을 보낼 수 있습니다. 따라서 폼 객체에 이동 명령을 내리면 폼의 전체 내용으로 이동 명령이 체인을 따라 자동으로 전달된다. 즉, 양식에 대해서만 오프셋을 수행하고 나머지는 자동으로 오프셋됩니다. 각 양식 개체에 직접 시프트 명령을 줄 필요가 없습니다.
우리는 단 하나의 객체를 위해 모든 것을 합니다. 다른 모든 사람들은 그것을 반복할 것입니다. 양식 개체가 아무리 복잡하더라도 양식을 이동하는 단일 명령은 해당 양식의 전체 내용에 넘쳐납니다.
우리는 모든 것을 한 번만 합니다. 그런 다음 모든 것이 체인에서 수행됩니다.
괜찮은.
커서의 x,y 차이를 포함하는 파생 매개변수와 양식 개체(연쇄됨) 사이의 링크에는 각 양식 개체의 x,y 매개변수에 직렬로 연결할 수 있는 핸들러가 중앙에 있습니다. 즉, 직렬 연결 핸들러를 통해 매개변수를 바인딩하면 각 양식 개체의 바인딩을 x,y 차이 값을 전달하는 파생 매개변수로 대체할 수 있습니다. 나도 이것에 대해 생각했다.
커서의 x,y 차이를 포함하는 파생 매개변수와 양식 개체(연쇄됨) 사이의 링크에는 각 양식 개체의 x,y 매개변수에 직렬로 연결할 수 있는 핸들러가 중앙에 있습니다. 즉, 직렬 연결 핸들러를 통해 매개변수를 바인딩하면 각 양식 개체의 바인딩을 x,y 차이 값을 전달하는 파생 매개변수로 대체할 수 있습니다. 나도 이것에 대해 생각했다.
따라서 함수 내부의 구현이 정확합니다. Handler Objects, Parameter Objects 및 Link Objects를 통한 구현은 이러한 배경에서 어색해 보입니다 . 하지만 파헤치자...
예, 개체와 별도로 이러한 처리기를 수행할 필요가 없기 때문입니다. 커서 좌표를 반환하는 클래스는 정적으로 만들 수 있습니다. 이는 프로그램의 모든 클래스에서 사용할 수 있으며 좌표를 가져오고 이에 대한 반응은 각 개체에서 구현되어야 합니다. 그러나 이러한 처리기에 대한 호출은 양식의 기본 개체에서만 이루어져야 합니다. 그런 다음 양식의 다른 모든 개체에 대해 새 좌표를 지정하고 다시 그리는 것으로 충분합니다. 양식 개체 내부에는 모든 개체 목록이 있습니다. 양식 개체가 좌표 변경을 감지했습니다. 좌표에 대한 새 값을 설정하고 개체 목록을 살펴보고 목록에 있는 각 개체의 좌표를 설정하는 메서드를 호출합니다. 동시에 각 다음 개체는 좌표를 변경할 때 동일한 작업을 수행합니다. 개체 목록을 살펴보고 좌표를 변경하라는 명령을 제공합니다. 목록에서 개체는 그려진 순서(Z 시퀀스)로 정렬됩니다. 즉, 각 개체에는 좌표를 변경하는 고유한 방법이 있지만 동일한 방식으로 구현됩니다. 모든 "자신의" 개체 목록을 살펴보고 각각에 대해 동일한 방법을 호출합니다. 따라서 주 양식 개체에서 이 메서드를 한 번 호출하면 절대적으로 모든 양식 개체에 대한 좌표 변경이 자동으로 시작됩니다. 양식 개체의 "자신의" 개체의 전체 목록을 처리한 후 차트를 다시 그리는 메서드가 호출됩니다. 변경된 모든 개체에 대해 한 번입니다.
이것은 창 이동 메커니즘의 표준 OOP 보기입니다. 하나 더 보여드리겠습니다. 이렇게 하려면 잠시 마음을 비우고 내 생각을 따르십시오.
배열 행렬을 상상해보십시오. 치수가 정의되지 않았습니다. 어쩌면 무한할 수도 있고 아닐 수도 있습니다. 그것은 중요하지 않습니다.
행렬은 0으로 초기화됩니다. 0은 공허함을 나타냅니다. 즉, 행렬이 비어 있습니다.
매트릭스의 허공에 공허함 이외의 것이 나타났다. 이 0은 특정 값으로 대체되었습니다. 어느 쪽이든 상관없습니다.
빈 행렬에서 이 값을 보고 "이것은 매개변수입니다"라고 말합니다. 즉, 값 자체가 아니라 값이 나타난 셀입니다. 셀에 제목이 부여되고 매개변수, 즉 값을 포함하는 "용량"이라는 이름이 지정되었습니다.
매개변수는 즉시 정의해야 합니다. "나는 매개변수고, 나는 개성이 있다! 내 속성은 어디에?!"라고 말하는 것 같다. 그리고 우리는 매개변수에 속성을 추가하는 것 외에 다른 선택의 여지가 없습니다. 이 속성 역시 고유한 값을 가진 매개변수입니다. 우리는 그것들을 옆에 놓고 매개변수와 그 속성인 사슬을 얻습니다. "우리는 매개변수 개체를 만들었습니다!"라고 말합니다.
또한 매개변수가 "말합니다": "다른 매개변수는 어디에?! 왜 나만 혼자야?" 그런 다음 행렬의 빈 공간에 매개변수를 몇 개 더 만들어 "처음 태어난 사람"이 지루하지 않도록 합니다. 물론, 각각의 새로운 매개변수는 고유성을 선언하고 매개변수로 속성이 필요합니다. 이것이 매개변수 사슬이 성장하는 방식이며, 그 중 "첫 번째 출생"과 해당 속성이 있습니다. "우리는 매개변수 개체를 만들었습니다!"라고 말합니다.
이제 행렬의 공백에 속성 체인이 있는 여러 매개변수가 있습니다. 그러나 그들 각자는 자신의 존재의 무의미함에 대해 "비명을 지른다". 그들 각각은 혼자입니다. 그런 다음 매개변수를 연결하기로 결정하여 "지루해지지" 않습니다. 이를 위해 다른 매개변수 간의 링크 역할을 하는 특수 매개변수를 생성합니다. 또한 속성 체인으로 구성됩니다. 이제 첫 번째 매개변수는 번들 매개변수로 상호 연결됩니다. 모든 사람이 행복하다! "우리는 매개변수 바인딩 개체를 만들었습니다!"라고 말합니다.
그러나 여기서 첫 번째 매개 변수는 번들을 통해 서로 통신하고 값을 전달하기를 원하지만 번들은 값 전송(매개 변수 언어)을 제공하지만 번역은 제공하지 않는다는 것이 밝혀졌습니다. 그리고 혼자 있는 매개변수는 자신의 언어만 이해하므로 매개변수 사이에 "언어 장벽"이 발생하고 우리의 결정이 필요합니다.
"매개변수 통신" 문제를 해결하기 위해 링크가 거의 없었고 번역이 필요했습니다. 즉, 각 매개변수의 속성을 고려하여 매개변수 간에 전달되는 값을 변환해야 합니다. 그들 중 일부는 1-10 범위의 값과 일부 (-5)-(-105) 값을 이해합니다. 누군가는 분수로 작동하고 누군가는 학위로 작동합니다. 그런 다음 "번역자", 즉 매개 변수의 속성을 고려하는 가치 프로세서가 필요하다는 결론에 도달합니다. 우리는 특별한 Handler Objects를 생성하고 그것들을 매개변수들 사이의 바인딩에 삽입합니다. 값 핸들러 개체는 전달 및 수신하는 매개변수의 속성과 자체 속성을 사용하여 매개변수 간에 전달된 값을 "변환"합니다. "우리는 핸들러 개체를 만들었습니다! 이제 매개변수가 자유롭게 통신할 수 있습니다!"라고 말합니다.
처음 태어난 매개 변수는 이야기하고 말하고 지쳤습니다. 피곤한. 그런 다음 그들은 특별한 경우에만 의사 소통하기로 결정했습니다. 글쎄, 그들 중 하나가 놀라운 의미를 가질 때. 그러나 아이처럼 지칠 줄 모르고 의미를 따라야한다는 것이 밝혀졌습니다. 그런 다음 첫 번째 매개 변수는 값에 대한 비정상적인 "속임수"의 경우를 알려주는 일종의 "제어 시스템"을 제시하여 이에 대해 걱정하지 않도록 요청했습니다. 그런 다음 응답해야 하는 값의 캐스트를 만들고 그것에 특별함을 부여합니다. 핸들러와 우리는 "Object-event"를 얻었습니다. 우리는 그것을 각각의 첫 번째 매개변수에 연결했고 그들은 Event Objects의 신호를 사용하여 통신하기 시작했습니다. 그래서 우리는 "이벤트 개체"를 만들었습니다.
이것으로 이야기의 끝...
우리는 옆에서 매트릭스를보고 헐떡였습니다! "예, 우리는 개체 시스템을 만들었습니다!"))
추신. 모든 것이 행렬 배열로 생성될 수 있다는 점에 유의하십시오. 그리고 어레이 매트릭스는 핵심입니다. 그리고 그 안에 있는 개체는 실제 개체입니다. 그리고 매개변수, 이벤트, 번들, 속성, 핸들러가 있습니다. 이러한 기본 요소로 Core에 구축할 수 있는 시스템은 셀 수 없이 많습니다.
11. 패션의 첫 번째 매개 변수를 따르는 방법을 결정했습니다. 우리는 매트릭스 어딘가에 부동산 박람회가 있고 새로움에는 특정 공간이 있다는 것을 배웠습니다. 마찬가지로 세 가지 속성이 있습니다. "측정"이라고 합니다. 이러한 속성에 대한 값 선택은 무한하다고 가정하며 보너스로 "매개변수 시간"도 보너스로 제공합니다. 매개변수는 박람회에 와서 x, y, x_size, y_size 속성을 사용했습니다. 그들은 우리가 우주에서 우리 자신을 위한 껍질을 만들고 싶다고 말합니다. 글쎄, 그들은 다른 색상 (색상)을 캡처했습니다. 그들은 돌아와서 새 옷을 입기 시작했습니다. 그들은 지칠 때까지 자신을 위해 조각하고 조각한 공간 껍질을 조각했습니다. 어마어마하게 자랐다가 무너지더니.. 그러고는 색을 입혀서 진정을 했다. 그들은 다음에 무엇을 할지 고민하기 시작했습니다. 그리고 그들은 속성-시간 상자를 보았습니다. 그들이 생각하게하고 어떤 종류의 것을 시도합시다 ... 그들은 그것을 열고 스스로 조정했지만 값을 계산하지 않았고 순식간에 공허로 증발했습니다. 결국, 시간은 매우 조심해야 하는 매개변수입니다 ...
11. 패션의 첫 번째 매개 변수를 따르는 방법을 결정했습니다. 우리는 매트릭스 어딘가에 부동산 박람회가 있고 새로움에는 특정 공간이 있다는 것을 배웠습니다. 마찬가지로 세 가지 속성이 있습니다. "측정"이라고 합니다. 이러한 속성에 대한 값 선택은 무한하다고 가정하며 보너스로 "매개변수 시간"도 보너스로 제공합니다. 매개변수는 박람회에 와서 x, y, x_size, y_size 속성을 사용했습니다. 그들은 우리가 우주에서 우리 자신을 위한 껍질을 만들고 싶다고 말합니다. 글쎄, 그들은 다른 색상 (색상)을 캡처했습니다. 그들은 돌아와서 새 옷을 입기 시작했습니다. 그들은 지칠 때까지 스스로를 위한 공간 껍질을 성형하고 성형했습니다. 어마어마하게 자랐다가 무너지더니.. 그러고는 색을 입혀서 진정을 했다. 그들은 다음에 무엇을 할지 고민하기 시작했습니다. 그리고 그들은 속성-시간 상자를 보았습니다. 그들이 생각하게하고 어떤 종류의 것을 시도합시다 ... 그들은 그것을 열고 스스로 조정했지만 값을 계산하지 않았고 순식간에 공허로 증발했습니다. 결국, 시간은 매우 조심해야 하는 매개변수입니다 ...
이 모든 "객관성"은 두뇌를 많이 혼란스럽게합니다. 동의해야합니다 ... 조심해야합니다. Nikolai Semko가 천재와 정신분열증의 근접성에 대해 말한 것은 옳았습니다. 당신은 갈 수 있습니다". 더 잘 이해되지 않는 것들이 있습니다. 어떤 문은 우리의 의식에 대해 항상 닫혀 있어야 합니다. 그들이 한 영화에서 말했듯이 - "가장 위험한 기생충은 아이디어입니다. 일단 뇌에 들어가면 이미 도발하는 것이 불가능합니다." 내가 말한 매트릭스는 마음에 위험합니다. 그것에 빠져 영원히 길을 잃기 쉽습니다. 조심합시다.)))
Matrix에서 시스템을 표현하면 시스템의 구조를 새롭게 볼 수 있지만 시스템 생성을 용이하게 한다는 힌트는 보지 못했습니다. 일종의 "자기 개발"은 말할 것도 없습니다. 이런 식으로 시스템을 고려하는 것은 흥미롭지만 더 이상은 아닙니다. 나는 자기 발전을 보지도 않고, 암시조차 하지 않는다. 그러므로 신은 하나님께 맡기도록 합시다. 표준 OOP 접근 방식이나 필자는 시스템 자체 개발을 달성할 수 없습니다.
나는 OOP와 커널의 하이브리드인 새로운 프리즘을 통해 프로그램에 설명된 개체 시스템에서 내 두뇌가 거의 터질 뻔했습니다. 먼저 GUI의 시스템을 새롭게 살펴보았습니다. 이러한 모든 매개변수 개체, 상태 개체, 이벤트 개체 및 처리기 개체를 통해. GUI와 그 기술은 나에게 알려져 있기 때문에 모든 것이 매우 명확하게 나타 났지만 시스템은 매우 복잡했습니다. 많은 매개변수, 바인딩 및 핸들러. 나는 그러한 체계가 저절로 생겨날 수 없다는 결론에 이르렀다. 그리고 자연 선택은 여기서 무력합니다.)))
그 이유는 다음과 같습니다.
각 매개변수는 n번째 파생 매개변수를 가질 수 있습니다. 예를 들어, X의 변화는 매 순간에 이 X의 값으로부터 무한히 많은 매개변수의 도함수를 일으킬 수 있습니다.
파생된 각 매개변수에는 핸들러와 다른 매개변수에 대한 링크가 있어야 합니다. 매개변수 자체는 존재하지 않습니다. 통신이 필요합니다.
연결이 다를 수 있으므로 다양한 필터 프로세서, 교정기 및 변환기가 나타날 수 있습니다.
시스템에 중요한 것으로 간주될 수 있는 이벤트가 무한정 많이 있습니다. 각각에는 고유한 속성, 링크 및 핸들러가 있습니다. 옵션은 셀 수 없습니다.
따라서 개념이 없으면 시스템이 존재할 수 없습니다. (더 가능성 있음).
지구에 생명체가 어떻게 생겨났는지는 불분명...
다른 예를 드리겠습니다.
차트에 따라 컨트롤이 있는 창을 이동하는 시스템을 고려해 보겠습니다.
따라서 이 시스템 덕분에 창의 핸들을 커서로 잡는 경우 창과 해당 개체의 좌표를 변경할 수 있습니다. 이동하려면 이 모든 것을 차트에서 MT 개체의 위치를 변경하는 ObjectSetInteger 처리기 함수와 연결해야 합니다.
Parameter Objects, Handler Objects 등 특수 블록 시스템을 연결하여 하나의 GUI 기능을 구현한 것입니다.
Core에서 이러한 시스템을 구축하는 것은 모든 것을 객체로 바꾸지 않고 일반 코드를 작성하는 것만큼 쉽지도 않고 더 어려울 수도 있습니다. 하지만 계속 파고들게..
추신. 창을 이동하려면 창 핸들을 누르고 커서를 이동하는 것을 등록하는 이벤트 개체도 "만들어"야 한다는 것을 추가하는 것을 잊었습니다. 그리고 이 Event-Object를 커서의 x,y 값의 Object-handler(파생 매개변수에 차이를 기록함)에 대한 링크와 연결하여 이 이벤트의 신호에서만 작동하도록 합니다.
ZYY. 그리고 각 Event Object에 대해 자신만의 핸들러 Object를 생성하고 연결해야 합니다.
ZYYY. 그리고 각 핸들러 객체에는 매개변수나 이벤트로 작업할 때 사용하는 고유한 속성이 있습니다. 따라서 템플릿이 있어야 합니다. 그렇지 않으면 이 모든 것을 만드는 데 "지칠 수 있습니다."))
다른 예를 드리겠습니다.
차트에 따라 컨트롤이 있는 창을 이동하는 시스템을 고려해 보겠습니다.
따라서 이 시스템 덕분에 창의 핸들을 커서로 잡는 경우 창과 해당 개체의 좌표를 변경할 수 있습니다. 이동하려면 이 모든 것을 차트에서 MT 개체의 위치를 변경하는 ObjectSetInteger 처리기 함수와 연결해야 합니다.
Parameter Objects, Handler Objects 등 특수 블록 시스템을 연결하여 하나의 GUI 기능을 구현한 것입니다.
Core에서 이러한 시스템을 구축하는 것은 모든 것을 객체로 바꾸지 않고 일반 코드를 작성하는 것만큼 쉽지도 않고 더 어려울 수도 있습니다. 하지만 계속 파고들게..
추신. 창을 이동하려면 창 핸들을 누르고 커서를 이동하는 것을 등록하는 이벤트 개체도 "만들어"야 한다는 것을 추가하는 것을 잊었습니다. 그리고 이 Event-Object를 커서의 x,y 값의 Object-handler(파생 매개변수에 차이를 기록함)에 대한 링크와 연결하여 이 이벤트의 신호에서만 작동하도록 합니다.
ZYY. 그리고 각 Event Object에 대해 자신만의 핸들러 Object를 생성하고 연결해야 합니다.
ZYYY. 그리고 각 핸들러 객체에는 매개변수나 이벤트로 작업할 때 사용하는 고유한 속성이 있습니다. 따라서 템플릿이 있어야 합니다. 그렇지 않으면 이 모든 것을 만드는 데 "지칠 수 있습니다."))
복잡한. 터무니없이 어렵습니다.
괜찮은.
커서의 x,y 차이를 포함하는 파생 매개변수와 양식 개체(연쇄됨) 사이의 링크에는 각 양식 개체의 x,y 매개변수에 직렬로 연결할 수 있는 핸들러가 중앙에 있습니다. 즉, 직렬 연결 핸들러를 통해 매개변수를 바인딩하면 각 양식 개체의 바인딩을 x,y 차이 값을 전달하는 파생 매개변수로 대체할 수 있습니다. 나도 이것에 대해 생각했다.
내 GUI에서 창 이동은 다음을 수행하는 함수 내에서 구현됩니다.
(1) 창 핸들의 클릭 이벤트 확인
(2) 커서 이동 이벤트
(3) 현재 커서 좌표와 과거 커서 좌표의 차이 계산
(4) 창 개체를 순환하고 커서 위치의 차이를 수정하여 좌표를 변경합니다.
(5) ObjectSetInteger를 호출 하여 창 모양(캔버스)의 MT 개체를 차트를 따라 지정된 거리만큼 이동합니다.
따라서 함수 내부의 구현이 정확합니다. Handler Objects, Parameter Objects 및 Link Objects를 통한 구현은 이러한 배경에서 어색해 보입니다. 하지만 파헤치자...
괜찮은.
커서의 x,y 차이를 포함하는 파생 매개변수와 양식 개체(연쇄됨) 사이의 링크에는 각 양식 개체의 x,y 매개변수에 직렬로 연결할 수 있는 핸들러가 중앙에 있습니다. 즉, 직렬 연결 핸들러를 통해 매개변수를 바인딩하면 각 양식 개체의 바인딩을 x,y 차이 값을 전달하는 파생 매개변수로 대체할 수 있습니다. 나도 이것에 대해 생각했다.
내 GUI에서 창 이동은 다음을 수행하는 함수 내에서 구현됩니다.
(1) 창 핸들의 클릭 이벤트 확인
(2) 커서 이동 이벤트
(3) 현재 커서 좌표와 과거 커서 좌표의 차이 계산
(4) 창 개체를 순환하고 커서 위치의 차이를 수정하여 좌표를 변경합니다.
(5) ObjectSetInteger를 호출 하여 창 모양(캔버스)의 MT 개체를 차트를 따라 지정된 거리만큼 이동합니다.
따라서 함수 내부의 구현이 정확합니다. Handler Objects, Parameter Objects 및 Link Objects를 통한 구현은 이러한 배경에서 어색해 보입니다 . 하지만 파헤치자...
예, 개체와 별도로 이러한 처리기를 수행할 필요가 없기 때문입니다. 커서 좌표를 반환하는 클래스는 정적으로 만들 수 있습니다. 이는 프로그램의 모든 클래스에서 사용할 수 있으며 좌표를 가져오고 이에 대한 반응은 각 개체에서 구현되어야 합니다. 그러나 이러한 처리기에 대한 호출은 양식의 기본 개체에서만 이루어져야 합니다. 그런 다음 양식의 다른 모든 개체에 대해 새 좌표를 지정하고 다시 그리는 것으로 충분합니다. 양식 개체 내부에는 모든 개체 목록이 있습니다. 양식 개체가 좌표 변경을 감지했습니다. 좌표에 대한 새 값을 설정하고 개체 목록을 살펴보고 목록에 있는 각 개체의 좌표를 설정하는 메서드를 호출합니다. 동시에 각 다음 개체는 좌표를 변경할 때 동일한 작업을 수행합니다. 개체 목록을 살펴보고 좌표를 변경하라는 명령을 제공합니다. 목록에서 개체는 그려진 순서(Z 시퀀스)로 정렬됩니다. 즉, 각 개체에는 좌표를 변경하는 고유한 방법이 있지만 동일한 방식으로 구현됩니다. 모든 "자신의" 개체 목록을 살펴보고 각각에 대해 동일한 방법을 호출합니다. 따라서 주 양식 개체에서 이 메서드를 한 번 호출하면 절대적으로 모든 양식 개체에 대한 좌표 변경이 자동으로 시작됩니다. 양식 개체의 "자신의" 개체의 전체 목록을 처리한 후 차트를 다시 그리는 메서드가 호출됩니다. 변경된 모든 개체에 대해 한 번입니다.
...
이것은 창 이동 메커니즘의 표준 OOP 보기입니다. 하나 더 보여드리겠습니다. 이렇게 하려면 잠시 마음을 비우고 내 생각을 따르십시오.
이것으로 이야기의 끝...
우리는 옆에서 매트릭스를보고 헐떡였습니다! "예, 우리는 개체 시스템을 만들었습니다!"))
추신. 모든 것이 행렬 배열로 생성될 수 있다는 점에 유의하십시오. 그리고 어레이 매트릭스는 핵심입니다. 그리고 그 안에 있는 개체는 실제 개체입니다. 그리고 매개변수, 이벤트, 번들, 속성, 핸들러가 있습니다. 이러한 기본 요소로 Core에 구축할 수 있는 시스템은 셀 수 없이 많습니다.
재미있는 속편...
11. 패션의 첫 번째 매개 변수를 따르는 방법을 결정했습니다. 우리는 매트릭스 어딘가에 부동산 박람회가 있고 새로움에는 특정 공간이 있다는 것을 배웠습니다. 마찬가지로 세 가지 속성이 있습니다. "측정"이라고 합니다. 이러한 속성에 대한 값 선택은 무한하다고 가정하며 보너스로 "매개변수 시간"도 보너스로 제공합니다. 매개변수는 박람회에 와서 x, y, x_size, y_size 속성을 사용했습니다. 그들은 우리가 우주에서 우리 자신을 위한 껍질을 만들고 싶다고 말합니다. 글쎄, 그들은 다른 색상 (색상)을 캡처했습니다. 그들은 돌아와서 새 옷을 입기 시작했습니다. 그들은 지칠 때까지 자신을 위해 조각하고 조각한 공간 껍질을 조각했습니다. 어마어마하게 자랐다가 무너지더니.. 그러고는 색을 입혀서 진정을 했다. 그들은 다음에 무엇을 할지 고민하기 시작했습니다. 그리고 그들은 속성-시간 상자를 보았습니다. 그들이 생각하게하고 어떤 종류의 것을 시도합시다 ... 그들은 그것을 열고 스스로 조정했지만 값을 계산하지 않았고 순식간에 공허로 증발했습니다. 결국, 시간은 매우 조심해야 하는 매개변수입니다 ...
재미있는 속편...
11. 패션의 첫 번째 매개 변수를 따르는 방법을 결정했습니다. 우리는 매트릭스 어딘가에 부동산 박람회가 있고 새로움에는 특정 공간이 있다는 것을 배웠습니다. 마찬가지로 세 가지 속성이 있습니다. "측정"이라고 합니다. 이러한 속성에 대한 값 선택은 무한하다고 가정하며 보너스로 "매개변수 시간"도 보너스로 제공합니다. 매개변수는 박람회에 와서 x, y, x_size, y_size 속성을 사용했습니다. 그들은 우리가 우주에서 우리 자신을 위한 껍질을 만들고 싶다고 말합니다. 글쎄, 그들은 다른 색상 (색상)을 캡처했습니다. 그들은 돌아와서 새 옷을 입기 시작했습니다. 그들은 지칠 때까지 스스로를 위한 공간 껍질을 성형하고 성형했습니다. 어마어마하게 자랐다가 무너지더니.. 그러고는 색을 입혀서 진정을 했다. 그들은 다음에 무엇을 할지 고민하기 시작했습니다. 그리고 그들은 속성-시간 상자를 보았습니다. 그들이 생각하게하고 어떤 종류의 것을 시도합시다 ... 그들은 그것을 열고 스스로 조정했지만 값을 계산하지 않았고 순식간에 공허로 증발했습니다. 결국, 시간은 매우 조심해야 하는 매개변수입니다 ...
그리고 처음 10개는 심각했습니까?
예를 들어, 나는 웃지 않고는 읽을 수 없습니다.
...
이 모든 "객관성"은 두뇌를 많이 혼란스럽게합니다. 동의해야합니다 ... 조심해야합니다. Nikolai Semko가 천재와 정신분열증의 근접성에 대해 말한 것은 옳았습니다. 당신은 갈 수 있습니다". 더 잘 이해되지 않는 것들이 있습니다. 어떤 문은 우리의 의식에 대해 항상 닫혀 있어야 합니다. 그들이 한 영화에서 말했듯이 - "가장 위험한 기생충은 아이디어입니다. 일단 뇌에 들어가면 이미 도발하는 것이 불가능합니다." 내가 말한 매트릭스는 마음에 위험합니다. 그것에 빠져 영원히 길을 잃기 쉽습니다. 조심합시다.)))