재개발을 통해 일부 "A"를 개선하려는 충동이 있는 경우 치명적인 단점을 명시할 필요가 있습니다. 'A'의 진화적 발달 과정에서 불가피한 이유를 나열하고 설명하시오.
반면에 아무도 그것을 금지하지 않습니다. 나는 코드를 작성하고 작성하는 것을 좋아합니다 ... "A"를 다시 작성하지만 자신의 방식으로 새 것입니다
맥스, 안녕!
글쎄, 나는 내 관점 에서 표준 라이브러리 와 Anatoly 라이브러리에서 볼 수 있는 "결점"을 반복해서 설명했습니다.
내 생각에 두 라이브러리에는 하나의 중요한 단점이 있습니다. 인터페이스가 개별 차트 개체를 기반으로 구축된다는 것입니다. 즉, 인터페이스에 컨트롤이 많을수록 차트 자체에 개체가 더 많이 분리됩니다. 한편으로 이것은 그 자체로는 문제가 없어 보이지만 다른 한편으로 드래그되는 것은 단일 "요소가 있는 양식" 개체가 아니라 여러 요소가 다르기 때문에 대화상자를 드래그할 때 문제가 발생합니다. . 그리고 이를 위해서는 추가 리소스가 필요합니다.
Anatoly의 라이브러리는 매우 세련되지만 구성이 복잡하고 기본 프로그램에 통합하기 어렵습니다. 그리고 표준 라이브러리는 컨트롤 자체에 제한이 있지만 원래 아키텍처가 제 생각에는 매우 좋습니다.
사실, 최고의 솔루션은 Petr Konov가 하려고 하는 것입니다. GUI 코드 생성 기능이 있는 그래픽 인터페이스 디자이너지만 확장된 이벤트 모델만 사용하므로 메인 프로그램과 통합할 때 다음 단계로 올라갈 필요가 없습니다. 거대한 GUI 코드(MVVM의 아날로그와 같은 것), 물론 사용자가 스스로 확장할 수 있는 개체가 포함됩니다.
글쎄, 나는 내 관점 에서 표준 라이브러리 와 Anatoly 라이브러리에서 볼 수 있는 "결점"을 반복해서 설명했습니다.
내 생각에 두 라이브러리에는 하나의 중요한 단점이 있습니다. 인터페이스가 개별 차트 개체를 기반으로 구축된다는 것입니다. 즉, 인터페이스에 컨트롤이 많을수록 차트 자체에 개체가 더 많이 분리됩니다. 이는 한편으로는 그 자체로는 문제가 없어 보이지만, 다른 한편으로 드래그되는 것은 단일 "요소가 있는 양식" 개체가 아니라 여러 요소가 다르기 때문에 대화상자를 드래그할 때 문제가 발생합니다. . 그리고 이를 위해서는 추가 리소스가 필요합니다.
Anatoly의 라이브러리는 매우 세련되지만 구성이 복잡하고 기본 프로그램에 통합하기 어렵습니다. 그리고 표준 라이브러리는 컨트롤 자체에 제한이 있지만 원래 아키텍처가 제 생각에는 매우 좋습니다.
사실, 최고의 솔루션은 Petr Konov가 하려고 하는 것입니다. GUI 코드 생성 기능이 있는 그래픽 인터페이스 디자이너 지만 확장된 이벤트 모델만 사용하므로 메인 프로그램과 통합할 때 다음 단계로 올라갈 필요가 없습니다. 거대한 GUI 코드와 물론 사용자가 스스로 확장할 수 있는 개체 포함.
인용문은 아래에서 위로 읽어야 합니다. 아래(밑줄 친 부분)가 더 중요합니다. 일반적으로 결정합니다
모든 휴먼 인터페이스의 모든 현대적 발전과 함께 좌표 표현과 형식 요소가 선두에 있다는 것을 보는 것은 오히려 놀라운 일입니다. 동시에 모두가 Rest / Ajax와 함께 브라우저를 침착하게 사용하고 MVC가 무엇인지 알고 있지만 고문과 GUI 사이의 인터페이스에 대해서는 생각하지 않습니다.
모델이 설명되고 작업 방법에 대한 프로토콜이 있으면 GUI가 될 수 있으며 고문의 부러움이 없습니다. 조언자에게 창을 몰아 넣으라는 지시는 일종의 악-악-악입니다. Expert Advisors의 경우 주요 작업은 거래이며 다른 모든 것은 기본 코드에서 제거하고 선택 사항이어야 합니다.
인용문은 아래에서 위로 읽어야 합니다. 아래(밑줄 친 부분)가 더 중요합니다. 일반적으로 결정합니다
모든 휴먼 인터페이스의 모든 현대적 발전과 함께 좌표 표현과 형식 요소가 선두에 있다는 것을 보는 것은 오히려 놀라운 일입니다. 동시에 모두가 Rest / Ajax와 함께 브라우저를 침착하게 사용하고 MVC가 무엇인지 알고 있지만 고문과 GUI 사이의 인터페이스에 대해서는 생각하지 않습니다.
모델이 설명되고 작업 방법에 대한 프로토콜이 있으면 GUI가 될 수 있으며 고문의 부러움이 없습니다. 조언자에게 창을 몰아 넣으라는 지시는 일종의 악-악-악입니다. Expert Advisors의 경우 주요 작업은 거래이며 다른 모든 것은 기본 코드에서 제거하고 선택 사항이어야 합니다.
나는 여기에서 개발자들이 처음에 인터페이스의 기능이 필요할 수 있다는 사실에 대해 생각하지 않았다는 사실에서 진행할 가치가 있다고 생각합니다. 기억한다면 초기 단계에서는 mql에 OOP조차 없었고 주요 목적은 지표를 작성하는 것이었고 모든 것이 이에 맞게 조정되었습니다.
그리고 오늘날 우리는 메타쿼타가 이미 소켓과 데이터베이스, 그리고 프로그램 코어 자체의 수준에서 작동한다는 것을 관찰했습니다... 그리고 사용자와 프로그램 간의 상호 작용 메커니즘은 제쳐두고 남아 있습니다.
동시에 개발자 자신은 거의 10 년 전에 인터페이스 개발이 사용자와 응용 프로그램 간의 상호 작용에 매우 중요한 메커니즘이라고 말했으며 이 문제에 대한 표준 라이브러리 를 개발했지만 작업에 대한 적용 가능성을 보여주지 않았습니다. 그리고 사실 오늘날에도 많은 프로그래머가 그 존재를 모릅니다.
부족한 부분을 채워나가도록 노력하겠습니다. 다른 참가자가 요구하지 않더라도 약간의 경험은 계속 얻을 수 있습니다.
나는 당신의 라이브러리로 시작하여 감사합니다. 그런 다음 조금 빗질 한 다음 다시 빗질했습니다. , 이벤트에 스텁을 넣습니다. W 구조에서 아직 완전히 사라지지는 않았지만 거기에도 약간 남아 있습니다. 타사 요소 간의 이진 검색을 통해 왼쪽 및 오른쪽에서 각각 막대 계산을 추가했으며 더 크거나 작은 값을 선택할 수 있는 기능과 함께 이진 검색 자체를 양방향으로 추가했습니다. 나는 또한 모든 종류의 배열에서 빌드하는 기능을 추가했습니다(시계열/일반) 그리고 디자인을 변경해야 한다는 결론에 도달했습니다))))))
엄청난.
예, 라이브러리는 초보 프로그래머에게 보편적이어야 하거나, 고급 프로그래머를 위해 좁게 초점을 맞춰야 합니다.
나 자신도 다른 목적을 위해 여러 버전의 iCanvas를 가지고 있습니다.
따라서 나는 의도와 목표 목록의 공식화에 대해 이야기하거나 적어도 방향을 나타내기 시작했습니다. 그리고 이 목록을 편집 가능한 동안 첫 번째 게시물에 넣으세요.
GUI 메커니즘이 어떻게 작동하는지 먼저 이해하고 코드 작성을 시작해야 합니다. 요소의 구조와 동작, 다양한 상황에서의 반응을 알아야 합니다. 먼저 템플릿으로 제공한 다음 이벤트 모델, 상태 핸들러, 현상, 좌표, 바인딩 및 도면을 포함하여 준비된 기술 기반에 인스턴스를 만듭니다. 결국 캔버스에 원시 그래픽 라이브러리 가 생깁니다. 마크업 언어는 아직 멀었습니다. 에디터는 말할 것도 없다. 하지만 잠시만요.
당신이 무언가를 준비하고 더 높은 수준으로 올릴 수 있다고 생각한다면, 당신은 심각한 것을 개발한 적이 없습니다.
GUI 메커니즘이 어떻게 작동하는지 먼저 이해하고 코드 작성을 시작해야 합니다. 그들은 요소의 구조와 행동, 다양한 상황에서의 반응을 알아야 합니다. 먼저 템플릿으로 제공한 다음 이벤트 모델, 상태 핸들러, 현상, 좌표, 바인딩 및 도면을 포함하여 준비된 기술 기반에 인스턴스를 만듭니다. 결국 캔버스에 원시 그래픽 라이브러리가 생깁니다. 마크업 언어는 아직 멀었습니다. 에디터는 말할 것도 없다. 하지만 잠시만요.
당신이 무언가를 준비하고 더 높은 수준으로 올릴 수 있다고 생각한다면, 당신은 심각한 것을 개발한 적이 없습니다.
잠깐만요. 이것은 기본의 기초에 불과합니다. 그리고 내가 GUI를 끝낼 것이라는 사실은 거의 불가능합니다. 나는 처음에 그렇게 말했습니다. 대형 프로젝트 와 관련하여 - 귀하의 코드에서 이것을 말할 것입니다. 대형 프로젝트와 경쟁하기에는 라인이 충분하지 않습니다 .....
이제 문제는 이 트릭이 작동하지 않는 이유입니다.
class CB;
class CC;
class CBx{ public : CBx(){};};
class CBy{ public : CBy(){};};
TEMPL(T)
class CA : public T
{
public :
CA(){}
CB<T> *b;
CC<T> *c;
};
TEMPL(T)
class CB : public CA<T>
{
public :
CB(){}
};
TEMPL(T)
class CC : public CA<T>
{
public :
CC(){}
};
CB<CBy> cc;
간략하게 엔지니어링에 대해:
재개발을 통해 일부 "A"를 개선하려는 충동이 있는 경우 치명적인 단점을 명시할 필요가 있습니다. 'A'의 진화적 발달 과정에서 불가피한 이유를 나열하고 설명하시오.
반면에 아무도 그것을 금지하지 않습니다. 나는 코드를 작성하고 작성하는 것을 좋아합니다 ... "A"를 다시 작성하지만 자신의 방식으로 새 것입니다
맥스, 안녕!
글쎄, 나는 내 관점 에서 표준 라이브러리 와 Anatoly 라이브러리에서 볼 수 있는 "결점"을 반복해서 설명했습니다.
내 생각에 두 라이브러리에는 하나의 중요한 단점이 있습니다. 인터페이스가 개별 차트 개체를 기반으로 구축된다는 것입니다. 즉, 인터페이스에 컨트롤이 많을수록 차트 자체에 개체가 더 많이 분리됩니다. 한편으로 이것은 그 자체로는 문제가 없어 보이지만 다른 한편으로 드래그되는 것은 단일 "요소가 있는 양식" 개체가 아니라 여러 요소가 다르기 때문에 대화상자를 드래그할 때 문제가 발생합니다. . 그리고 이를 위해서는 추가 리소스가 필요합니다.
Anatoly의 라이브러리는 매우 세련되지만 구성이 복잡하고 기본 프로그램에 통합하기 어렵습니다. 그리고 표준 라이브러리는 컨트롤 자체에 제한이 있지만 원래 아키텍처가 제 생각에는 매우 좋습니다.
사실, 최고의 솔루션은 Petr Konov가 하려고 하는 것입니다. GUI 코드 생성 기능이 있는 그래픽 인터페이스 디자이너지만 확장된 이벤트 모델만 사용하므로 메인 프로그램과 통합할 때 다음 단계로 올라갈 필요가 없습니다. 거대한 GUI 코드(MVVM의 아날로그와 같은 것), 물론 사용자가 스스로 확장할 수 있는 개체가 포함됩니다.
맥스, 안녕!
글쎄, 나는 내 관점 에서 표준 라이브러리 와 Anatoly 라이브러리에서 볼 수 있는 "결점"을 반복해서 설명했습니다.
내 생각에 두 라이브러리에는 하나의 중요한 단점이 있습니다. 인터페이스가 개별 차트 개체를 기반으로 구축된다는 것입니다. 즉, 인터페이스에 컨트롤이 많을수록 차트 자체에 개체가 더 많이 분리됩니다. 이는 한편으로는 그 자체로는 문제가 없어 보이지만, 다른 한편으로 드래그되는 것은 단일 "요소가 있는 양식" 개체가 아니라 여러 요소가 다르기 때문에 대화상자를 드래그할 때 문제가 발생합니다. . 그리고 이를 위해서는 추가 리소스가 필요합니다.
Anatoly의 라이브러리는 매우 세련되지만 구성이 복잡하고 기본 프로그램에 통합하기 어렵습니다. 그리고 표준 라이브러리는 컨트롤 자체에 제한이 있지만 원래 아키텍처가 제 생각에는 매우 좋습니다.
사실, 최고의 솔루션은 Petr Konov가 하려고 하는 것입니다. GUI 코드 생성 기능이 있는 그래픽 인터페이스 디자이너 지만 확장된 이벤트 모델만 사용하므로 메인 프로그램과 통합할 때 다음 단계로 올라갈 필요가 없습니다. 거대한 GUI 코드와 물론 사용자가 스스로 확장할 수 있는 개체 포함.
인용문은 아래에서 위로 읽어야 합니다. 아래(밑줄 친 부분)가 더 중요합니다. 일반적으로 결정합니다
모든 휴먼 인터페이스의 모든 현대적 발전과 함께 좌표 표현과 형식 요소가 선두에 있다는 것을 보는 것은 오히려 놀라운 일입니다.
동시에 모두가 Rest / Ajax와 함께 브라우저를 침착하게 사용하고 MVC가 무엇인지 알고 있지만 고문과 GUI 사이의 인터페이스에 대해서는 생각하지 않습니다.
모델이 설명되고 작업 방법에 대한 프로토콜이 있으면 GUI가 될 수 있으며 고문의 부러움이 없습니다. 조언자에게 창을 몰아 넣으라는 지시는 일종의 악-악-악입니다. Expert Advisors의 경우 주요 작업은 거래이며 다른 모든 것은 기본 코드에서 제거하고 선택 사항이어야 합니다.
인용문은 아래에서 위로 읽어야 합니다. 아래(밑줄 친 부분)가 더 중요합니다. 일반적으로 결정합니다
모든 휴먼 인터페이스의 모든 현대적 발전과 함께 좌표 표현과 형식 요소가 선두에 있다는 것을 보는 것은 오히려 놀라운 일입니다.
동시에 모두가 Rest / Ajax와 함께 브라우저를 침착하게 사용하고 MVC가 무엇인지 알고 있지만 고문과 GUI 사이의 인터페이스에 대해서는 생각하지 않습니다.
모델이 설명되고 작업 방법에 대한 프로토콜이 있으면 GUI가 될 수 있으며 고문의 부러움이 없습니다. 조언자에게 창을 몰아 넣으라는 지시는 일종의 악-악-악입니다. Expert Advisors의 경우 주요 작업은 거래이며 다른 모든 것은 기본 코드에서 제거하고 선택 사항이어야 합니다.
나는 여기에서 개발자들이 처음에 인터페이스의 기능이 필요할 수 있다는 사실에 대해 생각하지 않았다는 사실에서 진행할 가치가 있다고 생각합니다. 기억한다면 초기 단계에서는 mql에 OOP조차 없었고 주요 목적은 지표를 작성하는 것이었고 모든 것이 이에 맞게 조정되었습니다.
그리고 오늘날 우리는 메타쿼타가 이미 소켓과 데이터베이스, 그리고 프로그램 코어 자체의 수준에서 작동한다는 것을 관찰했습니다... 그리고 사용자와 프로그램 간의 상호 작용 메커니즘은 제쳐두고 남아 있습니다.
동시에 개발자 자신은 거의 10 년 전에 인터페이스 개발이 사용자와 응용 프로그램 간의 상호 작용에 매우 중요한 메커니즘이라고 말했으며 이 문제에 대한 표준 라이브러리 를 개발했지만 작업에 대한 적용 가능성을 보여주지 않았습니다. 그리고 사실 오늘날에도 많은 프로그래머가 그 존재를 모릅니다.
부족한 부분을 채워나가도록 노력하겠습니다. 다른 참가자가 요구하지 않더라도 약간의 경험은 계속 얻을 수 있습니다.
나는 당신의 라이브러리로 시작하여 감사합니다. 그런 다음 조금 빗질 한 다음 다시 빗질했습니다. , 이벤트에 스텁을 넣습니다. W 구조에서 아직 완전히 사라지지는 않았지만 거기에도 약간 남아 있습니다. 타사 요소 간의 이진 검색을 통해 왼쪽 및 오른쪽에서 각각 막대 계산을 추가했으며 더 크거나 작은 값을 선택할 수 있는 기능과 함께 이진 검색 자체를 양방향으로 추가했습니다. 나는 또한 모든 종류의 배열에서 빌드하는 기능을 추가했습니다(시계열/일반) 그리고 디자인을 변경해야 한다는 결론에 도달했습니다))))))
엄청난.
예, 라이브러리는 초보 프로그래머에게 보편적이어야 하거나, 고급 프로그래머를 위해 좁게 초점을 맞춰야 합니다.
나 자신도 다른 목적을 위해 여러 버전의 iCanvas를 가지고 있습니다.
따라서 나는 의도와 목표 목록의 공식화에 대해 이야기하거나 적어도 방향을 나타내기 시작했습니다. 그리고 이 목록을 편집 가능한 동안 첫 번째 게시물에 넣으세요.
일반적으로 내가 뭔가 잘못하고 있거나 클래스(비어 있음)를 선언하기 위한 템플릿이 작동하고 싶지 않습니다. 코드가 특히 편리하지 않은 이유
어떻게 바꿀까 생각하다
여러분, 저를 가르쳐 주셨으니 제가 가르쳐 드리겠습니다.
잠깐만요. 이것은 기본의 기초에 불과합니다. 그리고 내가 GUI를 끝낼 것이라는 사실은 거의 불가능합니다. 나는 처음에 그렇게 말했습니다. 대형 프로젝트 와 관련하여 - 귀하의 코드에서 이것을 말할 것입니다. 대형 프로젝트와 경쟁하기에는 라인이 충분하지 않습니다 .....
이제 문제는 이 트릭이 작동하지 않는 이유입니다.
...
이제 문제는 이 트릭이 작동하지 않는 이유입니다.