동일한 차트에 두 개의 애플리케이션, 패널, 지표가 있다고 가정해 보겠습니다. 각자 자신의 캔버스에 그려야 합니까, 아니면 둘 다 공통 캔버스에 그려야 합니까?
두 경우 모두 질문이 있습니다.
나는 이제 단순히 특정 캔버스를 처리하는 것을 제안합니다. 모든 요소와 함께. 어쨌든, 우리는 캔버스로 실행 중인 인스턴스의 수를 제어할 수 없을 것입니다(그렇지 않으면 캔버스에서 "다중 창 인터페이스"에 대한 OS 기능을 탐구할 것입니다. 언젠가 올 수도 있지만 지금은 아닙니다)
결과적으로 캔버스 사이에 "창 이벤트"를 보내는 수준에서 캔버스 간에 상호 작용을 수행하지 않는 것이 좋습니다.
또한 하나의 공통 캔버스 내용에 대해 여러 ex5가 어떻게 데이터를 교환 할지 지금은 상상할 수 없습니다.
근본적인 질문이 있습니다.
동일한 차트에 두 개의 애플리케이션, 패널, 지표가 있다고 가정해 보겠습니다. 각자 자신의 캔버스에 그려야 합니까, 아니면 둘 다 공통 캔버스에 그려야 합니까?
두 경우 모두 질문이 있습니다.
나는 이제 단순히 특정 캔버스를 처리하는 것을 제안합니다. 모든 요소와 함께.
어쨌든, 우리는 캔버스로 실행 중인 인스턴스의 수를 제어할 수 없을 것입니다(그렇지 않으면 캔버스에서 "다중 창 인터페이스"에 대한 OS 기능을 탐구할 것입니다. 언젠가 올 수도 있지만 지금은 아닙니다)
결과적으로 캔버스 사이에 "창 이벤트"를 보내는 수준에서 캔버스 간에 상호 작용을 수행하지 않는 것이 좋습니다.
또한 하나의 공통 캔버스 내용에 대해 여러 ex5가 어떻게 데이터를 교환 할지 지금은 상상할 수 없습니다.
키보드를 사용하면 모든 것이 다소간 명확해집니다. 키 누르기 이벤트가 있으며 이 키에 대한 코드가 있습니다. 그 밖에 무엇을 원하십니까?
불행히도 코드의 완전성은 없습니다. 이제 차트 이벤트 는 A 와
이 문제에 대해서는 이미 SD에도 썼습니다.
그건 그렇고, 저 같은 경우 OnMouseDown 이벤트를 도입하면 일반적인 DND 측면에서 삶을 크게 단순화할 것입니다.
Sparam의 CHART_MOUSE_MOVE 이벤트는 버튼과 키보드의 상태를 보냅니다. = 왼쪽, 오른쪽, ctrl, shift, alt.
즉, 우리는 지금 DND를 구현하고 있습니다.
즉, 우리는 지금 DND를 구현하고 있습니다.
예, 알고 있습니다. 최근 작업에서 구현했기 때문입니다. 따라서 이제 DND는 f * ny를 통해서만 구현할 수 있습니다.
첫째, 일반 드래그의 경우 차트의 일부 속성을 잘라내고 켜야 합니다. 그렇지 않으면 차트가 캔버스와 함께 드래그됩니다. 물론 거의 모든 경우에 차트를 꺼야 합니다.
둘째, MouseMove는 예를 들어 Click과 같은 개체에 바인딩되지 않으므로 마우스 아래에 두 개체가 있으면 둘 다 경쟁합니다. 그건 그렇고 표준 라이브러리 에 있습니다.
어떤 객체를 끌어올 것인지 선택하는 내부 논리 가 없는 경우에도 마찬가지입니다.
따라서 MoseDown 이벤트의 두 번째 문제는 효과적으로 해결된 것 같습니다.
그리고, 세 번째 포인트가 있습니다. MouseMove 스팸 이벤트. 강제로 켜야 하고 켜면 차트의 모든 코드로 보내지게 되며 메시지의 수로 인해 제동이 잘 될 수 있으므로 사용하지 않을 방법이 있으면 사용하지 않는 것이 좋다. 그것.
그리고, 세 번째 포인트가 있습니다. MouseMove 스팸 이벤트. 강제로 켜야 하고 켜면 차트의 모든 코드로 보내지게 되며 메시지의 수로 인해 제동이 잘 될 수 있으므로 사용하지 않을 방법이 있으면 사용하지 않는 것이 좋다. 그것.
예, 알고 있습니다. 최근 작업에서 구현했기 때문입니다. 따라서 이제 DND는 f * ny를 통해서만 구현할 수 있습니다.
첫째, 일반 드래그의 경우 차트의 일부 속성을 잘라내고 켜야 합니다. 그렇지 않으면 차트가 캔버스와 함께 드래그됩니다. 물론 거의 모든 경우에 차트를 꺼야 합니다.
둘째, MouseMove는 예를 들어 Click과 같은 개체에 바인딩되지 않으므로 마우스 아래에 두 개체가 있으면 둘 다 경쟁합니다. 그건 그렇고 표준 라이브러리 에 있습니다.
어떤 객체를 끌어올 것인지 선택하는 내부 논리 가 없는 경우에도 마찬가지입니다.
따라서 MoseDown 이벤트의 두 번째 문제는 효과적으로 해결된 것 같습니다.
그리고, 세 번째 포인트가 있습니다. MouseMove 스팸 이벤트. 강제로 켜야 하고 켜면 차트의 모든 코드로 보내지게 되며 메시지의 수로 인해 제동이 잘 될 수 있으므로 사용하지 않을 방법이 있으면 사용하지 않는 것이 좋다. 그것.
우리가 캔버스에 들어가면 우리는 우리 자신에 있다는 것을 이해합니다. 더 이상 고급 이벤트가 없습니다. 수락할 수 있는 MT 시설 없음
마우스 움직임과 버튼 상태만 있는 경우. 나는 그것을 f * 노래라고 부르지 않을 것입니다)). 낮은 이벤트 수준입니다.
브레이크가 있는 경우 육안으로 볼 수 없습니다. 내 패널에서 한 번에 MouseMove는 다음을 포함하여 수만 개의 요소로 전송되었습니다. 보이지 않는 경우 더 똑똑한 메일링을 만들었지만 시각적으로 이것은 속도를 추가하지 않았습니다.
11,000개의 물체는 빠른 속도로 날씨를 만들지 않습니다.
11,000개의 물체는 날씨를 빠르게 만들지 않습니다.
우리가 캔버스에 들어가면 우리는 우리 자신에 있다는 것을 이해합니다. 더 이상 고급 이벤트가 없습니다. 수락할 수 있는 MT 시설 없음
마우스 움직임과 버튼 상태만 있는 경우. 나는 그것을 f * 노래라고 부르지 않을 것입니다)). 낮은 이벤트 수준입니다.
다른 코드와의 상호 작용 수준도 있습니다. 예를 들어, 적어도 하나의 지표의 여러 인스턴스 사이에서. 그것이 내가 말하는 것입니다.
예, 모든 것이 명확합니다.
다른 코드와의 상호 작용 수준도 있습니다. 예를 들어, 적어도 하나의 지표의 여러 인스턴스 사이에서. 그것이 내가 말하는 것입니다.
솔직히, 나는 당신이 쓰고 있는 가능한 상호 작용이 무엇인지 전혀 모릅니다.
표시기의 여러 인스턴스가 동일한 캔버스에 표시됩니까? 글쎄, 나는 모른다. 빌어먹을 소름 끼치는.