캔버스 멋지다! - 페이지 89

 
Nikolai Semko #:
요점은 이와 같은 것을 구현할 때 필연적으로 슬라이더 길이의 치명적인 부족이 발생한다는 것입니다.
일반적으로 이것은 하나의 슬라이더가 아닌 단일 슬라이더로 구현되며, 가장자리로 버튼을 드래그하여 너비를 변경하여 눈금을 변경할 수 있습니다. 그러나 이 방법은 더 편리하지만 슬라이더 길이 문제를 해결하지는 못합니다.

네, 이미 겪어봤어요 ;)

긴 것을 만들었습니다.

이 모든 탬버린 춤은 단지 목적을위한 것입니다.

가격이 실제로, 그리고 가장 중요한 것은 무엇으로부터, 왜 움직이는지를 보기 위한 것입니다.

이제 모든 것이 명확해졌습니다 ;))))

물론 터미널에 아름답게 그려져 있지만 사실이 아닙니다!

예고편에서 올바른 차트
파일:
777.png  15 kb
 
Renat Akhtyamov #:

네, 벌써 부딪혔어요 ;)

이 모든 탬버린 춤은 단지 목적을위한 것입니다.

실제로 어떻게 진행되는지, 그리고 가장 중요한 것은 가격이 올라가는 원인과 이유를 알아보기 위한 것입니다.

이제 모든 것이 명확해졌습니다 ;))))

제 생각에는 높이 좌표가 눈금을 담당하는 2 차원 슬라이더를 사용하는 것이 훨씬 더 편리하고 시각적입니다.
이와 같은 것입니다:

이 경우 마우스 클릭 한 번으로 전체 기록의 어느 순간에나 눈금과 함께 이동하면 됩니다.

 
Nikolai Semko #:

저에게는 스케일을 담당하는 높이 좌표가 있는 2차원 슬라이더가 훨씬 더 편리하고 시각적입니다.
이와 같은 방식입니다:

당신은 아주 멋진 것을 가지고 있습니다 ;)

 
Renat Akhtyamov #:

정말 멋지네요 ;)

고마워요,
웹어셈블리(Rust)에서 본격적인 것을 만들고 싶어요.

 
Nikolai Semko #:

고마워요,
웹어셈블리(Rust에서)에서 본격적인 것을 만들고 싶습니다.

네.

가장 중요한 것은 아무것도 전환할 필요가 없다는 것입니다.

최소 시간 프레임이 확장됩니다.

그리고 나는 당황합니다. 어떻게 같은 가격으로 다른 시간대에 신호가 다른가요?

누가 숲으로 가고, 누가 숲으로 가는가....

타임프레임은 본질적으로 필요하지도 않습니다.

틱이 필요하고 그게 전부입니다.

 
Renat Akhtyamov #:

아무것도 전환할 필요가 없습니다.

최소 기간이 조정됩니다.

같은 가격인데 어떻게 다른 차트주기에서 신호가 다른 건가요?

누가 숲으로 가고, 누가 나무로 가는가....

주기는 본질적으로 필요하지도 않습니다.

틱만 있으면 됩니다.

예, 현재의 시간대 모델은 매우 불편합니다. 시니어 TF의 각 막대에는 서로 다른 수의 분 막대가 포함되어 있습니다. 이 구조에서는 시니어 TF가 주니어 TF로 원활하게 축소되면 차트가 일치하지 않습니다.
저는 저에게 적합한 해결책을 찾았습니다.
M1에서 다음 인덱스 TF를 형성합니다 M2, M4, M8, M16, M32, M64, M128, M256, M1024, M2048 , M4096, M8192.
이 경우 모든 시간대의 각 막대에는 동일한 수의 M1이 포함되도록 보장됩니다.
모든 TF는 동일하게 스케일링되며 말 그대로 한 번의 수학적 작업으로 매우 쉽게 TF를 재계산할 수 있습니다. 그리고 더 많은 장점이 있습니다.
더 중요한 것은 시간 밀도가 아니라 거래 밀도이기 때문에 시니어 TF의 각 막대가 다른 시간 밀도를 가질 수 있다는 사실은 저를 괴롭히지 않습니다.
거래 밀도를 측정하기 위해 분 막대의 수를 사용하는 것은 상당히 허용됩니다.
여기서 더 나아가 틱을 사용하여 거래 밀도를 측정할 수도 있습니다.
 
Nikolai Semko #:
예, 현재 시간대 모델은 매우 불편합니다. 시니어 TF의 각 막대에는 다른 수의 분 막대가 포함되어 있습니다. 이러한 구조에서는 시니어 TF가 주니어 TF로 원활하게 축소되면 차트가 일치하지 않습니다.
저는 저에게 적합한 해결책을 찾았습니다.
M1에서 M2, M4, M8, M16, M32, M64, M128, M256, M1024, M2048 , M4096, M8192 인덱스 TF를 형성합니다.
이 경우 모든 기간의 각 막대는 동일한 양의 M1을 포함하도록 보장됩니다.
모든 TF는 동일하게 스케일링되며 말 그대로 한 번의 수학적 작업으로 매우 쉽게 TF를 재계산할 수 있습니다. 다른 많은 장점도 있습니다.
더 중요한 것은 시간 밀도가 아니라 거래 밀도이기 때문에 시니어 TF의 각 막대가 다른 시간 밀도를 가질 수 있다는 사실은 저를 괴롭히지 않습니다.
거래 밀도를 측정하기 위해 분 막대의 수를 사용하는 것은 상당히 허용됩니다.
여기서 더 나아가 틱을 사용하여 거래 밀도를 측정할 수도 있습니다.

잘 모르겠습니다.

확장되지 않고 압축됩니다.

TF가 사라집니다.
 
Renat Akhtyamov #:

나는 옳지 않았다

확장되지 않고 압축됩니다.

TF마가 사라짐
저는 M1만 사용하기 때문에 이 문제는 저에게는 존재하지 않습니다.
MQ도 M1에서 모두 형성 (계산)되었기 때문에 상위 TF의 배열 형성 관련성의 동기화 문제 일 가능성이 큽니다.
또는 귀하의 실수
 

그래픽 리소스의 개념과 그래프의 그래픽 객체 개념과 어떻게 다른지 이해하도록 도와주세요.

예를 들어 캔버스로 만든 그래픽 객체를 ObjectDelete() 함수를 사용하여 삭제한 다음 루프에서 이름이 다르지만 동일한 캔버스 클래스 인스턴스를 사용하여 캔버스 객체를 계속 생성하는 경우... 그리고 다시 ObjectDelete()를 사용하여 그래픽 객체를 삭제합니다. 이것이 전혀 위험합니까?

아직 ObjectDelete() 와 C.Destroy()의 차이점을 잘 이해하지 못하지만 이해하고 싶습니다....

 
leon_17 그래픽 객체를 ObjectDelete() 함수를 사용하여 삭제한 다음 루프에서 이름이 다르지만 동일한 캔버스 클래스 인스턴스를 사용하여 캔버스 객체를 계속 생성하는 경우... 그리고 다시 ObjectDelete()를 사용하여 그래픽 객체를 삭제합니다. 뭔가 문제가 있는 걸까요?

ObjectDelete() 와 C.Destroy()의 차이점을 아직 잘 이해하지 못하지만 이해하고 싶습니다....

캔버스는 픽셀 배열이 바인딩된 객체입니다. 리소스는 이 픽셀 배열을 바인딩하는 역할을 합니다(bool 함수 CCanvas::Create() 참조)
캔버스를 항상 삭제하고 다시 만드는 것은 나쁜 습관입니다.
캔버스가 필요할 때 만들고, 프로그램이 끝날 때처럼 더 이상 필요하지 않을 때 삭제하는 것은 좋은 습관입니다.

캔버스 개체를 만든 후에는 정리하고, 매 프레임마다 픽셀 배열을 덮어쓰고, 캔버스 크기를 조정하고, 원하는 곳으로 이동할 수 있습니다.