전술한 내용을 기반으로 구조 요소는 특정 대화 상자 컨트롤이며 고유한 속성을 포함하고 중첩된 컨트롤을 포함할 수 있음을 이해할 수 있습니다. 이러한 범용 컨트롤의 속성 집합은 개발자의 상상력에 의해서만 제한됩니다.
물론 구조로 올라갈 수는 없지만 다차원 배열 에서 컨트롤의 속성을 설명할 수 있지만 일부 속성이 저장된 인덱스를 명확하게 기억해야 하기 때문에 처음에는 비용 효율적이지 않습니다. 그리고 배열은 이기종 데이터 유형을 포함할 수 없습니다. 절차적 프로그래밍에서 제어 요소를 구조를 통해서만 기술할 수 있음이 밝혀졌습니다. 즉, 구조 요소는 특정 제어 요소, 즉 고유한 속성을 가진 특정 대화 상자 개체입니다.
표준 라이브러리에서 Include에는 키-값 인터페이스를 구현하는 CHashMap 클래스가 포함된 Generic 폴더가 있습니다. 하나의 개체는 모든 유형의 값 집합을 가질 수 있습니다. 맵 트리는 실행에 시간 복잡도가 있지만 매우 빠르게 작동합니다. 속성을 설명하는 데 적합할 수도 있습니다. 일반적으로 시도해야 합니다. 또는 이 라이브러리에서 작업에 더 적합한 다른 유형의 클래스를 사용하십시오.
Библиотека содержит классы и интерфейсы для определения шаблонных коллекций, которые, в свою очередь, дают пользователю возможность создавать строго типизированные коллекции. Они обеспечивают большее удобство и высокую производительность работы с данными, чем обычные типизированные коллекции.
원칙적으로 유형을 일반화할 수 있습니다. 대부분의 객체 속성이 int 유형이면 나쁜 일이 일어나지 않는다는 결론에 도달했습니다. 다른 모든 축약형(그래프 객체의 속성에는 double이 거의 없음)은 단순화를 위해 생략했습니다. 기억의 "과잉 지출"은 너무 미미하여 그것에 대해 생각하는 것이 의미가 없습니다. 물론 전문성을 높이기 위해 그런 신성모독은 함부로 할 수 없다.)) 하지만, 지금은 21세기와 불을 위협하지 않는다.))
나는 개체의 이름을 번호로 만들고 개체 속성의 일반 행에 넣습니다.
다른 데이터 유형이 필요한 유일한 곳은 컨트롤의 매개변수였습니다. 거기에서 매개변수의 속성을 저장하는 두 번째 코어를 만들었으며 값 자체는 문자열 유형으로 되어 있어 무엇이든 쉽게(더 정확하게는 매개변수 속성에 기록된 것으로) 캐스팅할 수 있습니다.
추신. "컨트롤의 매개변수"는 요소에 의해 제어되는 매개변수를 의미합니다.
모든 컨트롤과 모든 속성을 포함하는 전역 배열의 깊이 차원은 컨트롤의 다른 모든 속성의 합과 같습니다. 즉, 요소에 일부 속성이 필요하지 않더라도 배열이 항상 균일하기 때문에 이러한 셀은 여전히 이 배열에 있습니다.
그러나 놀라운 것은 여전히 어레이 자체의 균일성입니다. 이와 관련하여 구조의 사용이 정당화되는 것 이상입니다. 이 경우 각 속성은 결합을 포함하여 고유한 유형으로 설명될 수 있기 때문입니다.
구조를 사용하면 속성 저장이 정말 간단해집니다. 한 가지 유형으로 제한하거나 무언가를 거부할 필요가 없습니다. 문자열에서 다른 데이터 유형 으로의 변환을 처리할 필요가 없습니다... 구조는 처음에 이러한 모든 제한을 제거합니다.
속성 및 좌표 자체 외에도 이 전역 배열은 요소 종속 시스템도 저장해야 합니다. 캡션 개체가 도면에서 변경된 경우 버튼도 제목 필드에 있기 때문에 다시 그려집니다. 즉, "중간" 제어 요소가 변경된 경우 해당 요소에 있는 모든 것을 다시 그려야 합니다. Piotr, 개체 종속성 구조를 어떻게 저장합니까?
Peter, 그것은 다음과 같이 밝혀졌습니다. 핵심은 요소 속성의 전역 행렬, 요소 값의 전역 행렬, 전역 종속성 행렬, 그림의 전역 행렬 ...
속성을 더 추가해야 하는 경우 행렬의 차원이 증가합니다.
셀에는 이름이 없기 때문에 속성 액세스는 인덱스에 의해 엄격하게 수행됩니다.
적어도 필드 이름에 대한 구조에서는 주소 지정이 가능합니다.
피터, 너... 거인...
예를 들어 다음과 같이 표시됩니다(단순화됨).
class CControl : public CObject
{
public :
int ПозицияХ;
int ПозицияY;
int Длина;
int Ширина;
color ЦветОсновы;
color ЦветБордюра;
int ТолщинаБордюра;
}
사실상의 "클래스"는 전역 배열의 특정 문자열이며 더 "인간적인" 얼굴에서만 나타납니다. 클래스는 인덱스가 아니라 이름으로 액세스할 수 있는 이해 가능한 속성 집합을 사용하여 고유한 데이터 개체를 생성하도록 설계되었습니다. 클래스는 제네릭 형식 생성자일 뿐입니다.
따라서 거의 모든 컨트롤에 있는 가장 일반적인 속성을 포함하는 기본 컨트롤을 만듭니다.
이를 기반으로 특수 개체를 만들 수 있습니다.
class CButton : public CControl
{
public :
string Заголовок;
int Image[];
}
즉, 각 후속 컨트롤 유형은 기본 유형에 필요한 속성을 추가하기만 하면 됩니다.
그리고 앞서 쓴 것처럼 주요 속성은 기본 컨트롤러에 저장되어 있으므로 CControl이라는 데이터 유형 을 확인할 때 커서의 "적중"을 컨트롤로 우회하는 작업이 수행됩니다. 원하는 개체를 찾으면 프로그램은 루프에서 프로그램이 원하는 배열 줄에 있는 것처럼 프로그램의 지점이 이미 개체 자체에 있기 때문에 이 개체의 속성에 즉시 액세스할 수 있습니다.
전술한 내용을 기반으로 구조 요소는 특정 대화 상자 컨트롤이며 고유한 속성을 포함하고 중첩된 컨트롤을 포함할 수 있음을 이해할 수 있습니다. 이러한 범용 컨트롤의 속성 집합은 개발자의 상상력에 의해서만 제한됩니다.
물론 구조로 올라갈 수는 없지만 다차원 배열 에서 컨트롤의 속성을 설명할 수 있지만 일부 속성이 저장된 인덱스를 명확하게 기억해야 하기 때문에 처음에는 비용 효율적이지 않습니다. 그리고 배열은 이기종 데이터 유형을 포함할 수 없습니다. 절차적 프로그래밍에서 제어 요소를 구조를 통해서만 기술할 수 있음이 밝혀졌습니다. 즉, 구조 요소는 특정 제어 요소, 즉 고유한 속성을 가진 특정 대화 상자 개체입니다.
표준 라이브러리에서 Include에는 키-값 인터페이스를 구현하는 CHashMap 클래스가 포함된 Generic 폴더가 있습니다.
하나의 개체는 모든 유형의 값 집합을 가질 수 있습니다. 맵 트리는 실행에 시간 복잡도가 있지만 매우 빠르게 작동합니다.
속성을 설명하는 데 적합할 수도 있습니다. 일반적으로 시도해야 합니다.
또는 이 라이브러리에서 작업에 더 적합한 다른 유형의 클래스를 사용하십시오.
다시 읽어보니.. 이 배열에 정보를 저장하기 위해 픽셀 배열과 동일한 배열을 저장할 것을 제안합니다(귀하의 경우 "어떤 함수 번호"가 처리에 사용되어야 하는지). ?
그러면 인터페이스를 일정에 바인딩하기 위해 역 쓰레기가 발생합니다. 예를 들어 타임스탬프와 가격에 엄격하게 연결된 버튼을 만듭니다.
여기에 모든 테이블, 탭, 메뉴 및 휘파람과 함께 비행 중에 작성된 별도의 GUI가 있습니다. C# 또는 BASIC에서도 가능합니다. 그리고 차트 내부 - 이것은 외부 응용 프로그램에 대한 중요한 문제입니다.
그렇다면 인터페이스를 차트에 바인딩하는 이유는 무엇입니까?
결국 해당 기능에서 동일한 타임 스탬프 및 가격과 같은 모든 데이터를 직접 수신할 수 있습니다.
다시 읽어보니.. 이 배열에 정보를 저장하기 위해 픽셀 배열과 동일한 배열을 저장할 것을 제안합니다(귀하의 경우 "어떤 함수 번호"가 처리에 사용되어야 하는지). ?
라고 묻는다면 나는 그런 제안을 하지 않았다. 나는 아무 것도 제안하지 않았습니다.)) 나는 단지 내 견해를 조금 설명했습니다. 동의하지 않을 수 있습니다.
원칙적으로 유형을 일반화할 수 있습니다. 대부분의 객체 속성이 int 유형이면 나쁜 일이 일어나지 않는다는 결론에 도달했습니다. 다른 모든 축약형(그래프 객체의 속성에는 double이 거의 없음)은 단순화를 위해 생략했습니다. 기억의 "과잉 지출"은 너무 미미하여 그것에 대해 생각하는 것이 의미가 없습니다. 물론 전문성을 높이기 위해 그런 신성모독은 함부로 할 수 없다.)) 하지만, 지금은 21세기와 불을 위협하지 않는다.))
나는 개체의 이름을 번호로 만들고 개체 속성의 일반 행에 넣습니다.
다른 데이터 유형이 필요한 유일한 곳은 컨트롤의 매개변수였습니다. 거기에서 매개변수의 속성을 저장하는 두 번째 코어를 만들었으며 값 자체는 문자열 유형으로 되어 있어 무엇이든 쉽게(더 정확하게는 매개변수 속성에 기록된 것으로) 캐스팅할 수 있습니다.
추신. "컨트롤의 매개변수"는 요소에 의해 제어되는 매개변수를 의미합니다.모든 컨트롤과 모든 속성을 포함하는 전역 배열의 깊이 차원은 컨트롤의 다른 모든 속성의 합과 같습니다. 즉, 요소에 일부 속성이 필요하지 않더라도 배열이 항상 균일하기 때문에 이러한 셀은 여전히 이 배열에 있습니다.
그러나 놀라운 것은 여전히 어레이 자체의 균일성입니다. 이와 관련하여 구조의 사용이 정당화되는 것 이상입니다. 이 경우 각 속성은 결합을 포함하여 고유한 유형으로 설명될 수 있기 때문입니다.
구조를 사용하면 속성 저장이 정말 간단해집니다. 한 가지 유형으로 제한하거나 무언가를 거부할 필요가 없습니다. 문자열에서 다른 데이터 유형 으로의 변환을 처리할 필요가 없습니다... 구조는 처음에 이러한 모든 제한을 제거합니다.
속성 및 좌표 자체 외에도 이 전역 배열은 요소 종속 시스템도 저장해야 합니다. 캡션 개체가 도면에서 변경된 경우 버튼도 제목 필드에 있기 때문에 다시 그려집니다. 즉, "중간" 제어 요소가 변경된 경우 해당 요소에 있는 모든 것을 다시 그려야 합니다. Piotr, 개체 종속성 구조를 어떻게 저장합니까?모든 컨트롤과 모든 속성을 포함하는 전역 배열의 깊이 차원은 컨트롤의 다른 모든 속성의 합과 같습니다. 즉, 요소에 일부 속성이 필요하지 않더라도 배열이 항상 균일하기 때문에 이러한 셀은 여전히 이 배열에 있습니다.
그러나 놀라운 것은 여전히 어레이 자체의 균일성입니다. 이와 관련하여 구조의 사용이 정당화되는 것 이상입니다. 이 경우 각 속성은 결합을 포함하여 고유한 유형으로 설명될 수 있기 때문입니다.
구조를 사용하면 속성 저장이 정말 간단해집니다. 한 가지 유형으로 제한하거나 무언가를 거부할 필요가 없습니다. 문자열에서 다른 데이터 유형 으로의 변환을 처리할 필요가 없습니다... 구조는 처음에 이러한 모든 제한을 제거합니다.
...Peter, 개체 종속성 구조를 어떻게 저장합니까?
그렇다면 인터페이스를 차트에 바인딩하는 이유는 무엇입니까?
결국 해당 기능에서 동일한 타임 스탬프 및 가격과 같은 모든 데이터를 직접 수신할 수 있습니다.
응용 프로그램 인터페이스(사용자가 작동하는 것)가 단일 창으로 제한되지 않는다는 사실입니다.
우리는 거래에 대해 이야기하고 있습니까?
음, 외부 수단을 통해 차트(및 해당 바인딩)에 대화형 요소를 배치하는 것은 거의 해결할 수 없으며 이것이 거의 가장 중요하고 중요한 것입니다.
반복합니다: 외부 대화 상자/양식은 그리기 쉽습니다. 그리고 차트 내부에는 터미널의 특성과 특정 차트가 없는 요소가 거의 없습니다.
핵심은 매트릭스입니다. 여기에는 개체의 모든 속성이 포함됩니다.
행렬은 루프의 중첩이고 중첩 루프는 시간입니다. IMHO, 비꼬는 것이 아니라 논리적인 추론일 뿐입니다.
Peter, 그것은 다음과 같이 밝혀졌습니다. 핵심은 요소 속성의 전역 행렬, 요소 값의 전역 행렬, 전역 종속성 행렬, 그림의 전역 행렬 ...
속성을 더 추가해야 하는 경우 행렬의 차원이 증가합니다.
셀에는 이름이 없기 때문에 속성 액세스는 인덱스에 의해 엄격하게 수행됩니다.
적어도 필드 이름에 대한 구조에서는 주소 지정이 가능합니다.
피터, 너... 거인...
예를 들어 다음과 같이 표시됩니다(단순화됨).
사실상의 "클래스"는 전역 배열의 특정 문자열이며 더 "인간적인" 얼굴에서만 나타납니다. 클래스는 인덱스가 아니라 이름으로 액세스할 수 있는 이해 가능한 속성 집합을 사용하여 고유한 데이터 개체를 생성하도록 설계되었습니다. 클래스는 제네릭 형식 생성자일 뿐입니다.
따라서 거의 모든 컨트롤에 있는 가장 일반적인 속성을 포함하는 기본 컨트롤을 만듭니다.
이를 기반으로 특수 개체를 만들 수 있습니다.
즉, 각 후속 컨트롤 유형은 기본 유형에 필요한 속성을 추가하기만 하면 됩니다.
그리고 앞서 쓴 것처럼 주요 속성은 기본 컨트롤러에 저장되어 있으므로 CControl이라는 데이터 유형 을 확인할 때 커서의 "적중"을 컨트롤로 우회하는 작업이 수행됩니다. 원하는 개체를 찾으면 프로그램은 루프에서 프로그램이 원하는 배열 줄에 있는 것처럼 프로그램의 지점이 이미 개체 자체에 있기 때문에 이 개체의 속성에 즉시 액세스할 수 있습니다.