기고글 토론 "MQL5 Coobook: 지표 하위 창 컨트롤 - 버튼"

[MetaQuotes]

새로운 기고글 MQL5 Coobook: 지표 하위 창 컨트롤 - 버튼 가 게재되었습니다:

이 글에서는 버튼 컨트롤이 있는 사용자 인터페이스를 개발하는 예를 고려할 것입니다. 사용자에게 상호 작용에 대한 아이디어를 전달하기 위해 커서가 버튼 위에 있을 때 버튼의 색상이 변경됩니다. 버튼 위에 커서가 있으면 버튼 색상이 약간 어두워지고 버튼을 클릭하면 훨씬 더 어두워집니다. 또한 각 버튼에 툴팁을 추가하여 직관적인 인터페이스를 만듭니다.

이 글에서는 마우스 이동 이벤트, 마우스 왼쪽 버튼의 상태, 개체를 마우스 왼쪽 버튼으로 클릭 및 차트 속성 수정 이벤트와 같은 일부 이벤트도 다룹니다. 지표 하위 창의 전체 공간을 차지하는 버튼 패널을 만들 것입니다. 설명을 위해 버튼은 각 행에 4개의 버튼이 있는 3개의 행으로 정렬됩니다.

 

작성자: Anatoli Kazharski

[Vasiliy Sokolov]

초보자를 위한 좋은 글입니다. 그러나 더 복잡한 인터페이스에서는 이러한 접근 방식이 더 이상 허용되지 않습니다. 가장 먼저 눈에 띄는 것이 있습니다:

for(int i=0; i<BUTTON_COLUMNS; i++)
     {
      for(int j=0; j<BUTTON_ROWS; j++)
        {
            ...
      ...
...

즉, 엄격한 테이블 구조가 알고리즘에 꿰매어져 있으며이 구조는 거의 모든 함수에서 발견됩니다. 이제 하위 창에 테이블과 어떤 식 으로든 관련이없는 여러 그래픽 요소가 포함되어 있다고 가정 해 보겠습니다. 이 경우 자체 위치 지정 모델을 설명해야 하는데 이는 좋지 않습니다. 포지셔닝 모델은 하나의 보편적인 모델이어야 합니다. 즉, 이 경우 "테이블" 레이아웃은 이 모델의 특수한 경우여야 합니다.

[Anatoli Kazharski]

C-4:

초보자를 위한 좋은 글입니다. 그러나 더 복잡한 인터페이스에서는 이러한 접근 방식이 더 이상 허용되지 않습니다. 가장 먼저 눈에 띄는 것이 있습니다:

즉, 엄격한 테이블 구조가 알고리즘에 꿰매어져 있으며이 구조는 거의 모든 함수에서 발견됩니다. 이제 하위 창에 테이블과 어떤 식 으로든 관련이없는 여러 그래픽 요소가 포함되어 있다고 가정 해 보겠습니다. 이 경우 자체 위치 지정 모델을 설명해야 하는데 이는 좋지 않습니다. 포지셔닝 모델은 하나의 보편적인 모델이어야 합니다. 즉, 이 경우 '표' 레이아웃은 이 모델의 특수한 경우여야 합니다.

네, 맞습니다. 다음에는 좀 더 독창적 인 것을 생각해 보겠습니다. )

이 경우 특수한 경우에서 벗어나려면 1차원 배열과 하나의 루프를 사용하는 것으로 충분합니다.

[Andrey Khatimlianskii]

왜 OBJ_EDIT를 사용해야 하는지 이해가 되지 않습니다.

라이브러리에서 표준 버튼을 "부활"하는 것이 훨씬 더 유용했을 것입니다(마우스 아래에서도 빛나도록).

즉, 유용한 기사 인 것 같지만 왜 그런 방법을 선택했는지 이해가되지 않습니다.

추신 : 저자의 결실이 부럽습니다 ;)

[Anatoli Kazharski]

komposter:

...

테스터에서 시각화 중에 표시되므로 이미 OBJ_EDIT를 사용하는 데 익숙합니다.

이 경우 예제에는 어떤 객체든 사용할 수 있습니다. 결국 창의적인 과정이니까요. )

[Vasiliy Sokolov]

komposter:

왜 OBJ_EDIT를 사용해야 하는지 모르겠어요.

라이브러리에서 표준 버튼을 "부활"하는 것이 훨씬 더 유용 할 것입니다 (마우스 아래에서도 빛나도록).

즉, 유용한 기사 인 것 같지만 왜 그런 방법을 선택했는지 이해가되지 않습니다.

추신 : 저자의 결실이 부럽습니다 ;)

실제로 표준 버튼은 처음에는 프레임 색상을 지원하지 않기 때문에 매우 미끄러운 제어 요소이며 (왜 매우 이상하지만) 두 번째는 프레임 유형에 따라 BORDER_FLAT, BORDER_RAISED가 시각적으로 위치 밖에 명확하게 배치되어 있으며,이 외에도 누르는 상태에 따라 그늘이 바뀌고 ChartRedraw없이 디스플레이 변경이 매우 느리다고 말하는 것이 아닙니다. 실제로 Windows 3.11의 잘게 잘린 인터페이스를 제외한 버튼은 다른 요소에 비해 어떤 이점도 제공하지 않습니다. 예, 버튼이 눌렀는지 여부를 나타내는 특수 필드 OBJ_SELECTED가 있지만 실제로는 누름 플래그가 포함 된 자체 개체 OBJ_EDIT를 만드는 데 아무런 문제가 없습니다.

[Vasiliy Smirnov]

그리고 버튼은 전혀 버튼이 아닙니다).

[Vasiliy Sokolov]

komposter:

라이브러리에서 표준 버튼을 "애니메이션"하는 것이 훨씬 더 유용 할 것입니다 (마우스 아래에서도 빛나도록).

그리고 자신의 제품에 표준 그래픽 요소 라이브러리를 사용하는 전문 개발자가 한 명이라도 있을까요?

[Anatoli Kazharski]

zfs:
그리고 버튼은 사실 버튼이 아닙니다).

버튼은 누를 수 있는 모든 것을 의미합니다. ))

[Anatoli Kazharski]

C-4:
그리고 자신의 제품에 표준 그래픽 요소 라이브러리를 사용하는 전문 개발자가 있는지 궁금합니다.

시장에는 표준 라이브러리에 사용된 요소와 유사한 인터페이스를 가진 제품이 있다고 생각합니다.

[Sergey Pavlov]

자료를 준비할 때 이 기사를 읽으셨는지 궁금합니다.