キャンバスがカッコいい! - ページ 89

[Renat Akhtyamov]

Nikolai Semko #:
ポイントは、このようなものを実装する場合、必然的にスライダーの長さが壊滅的に不足することに遭遇するということです。

原則として、これは1つのスライダーではなく、1つのスライダーで実装され、その幅はボタンの端をドラッグすることで変更でき、その結果、スケールが変更されます。しかし、この方法は便利ではありますが、スライダーの長さの問題を解決するものではありません。

ええ、すでに遭遇しました;)

長いのを作った

このタンバリン・ダンスは、ただ単に

本当に、そして最も重要なのは、何から、なぜ価格が動くのかを見るためである。

これですべて明らかになった。）

もちろん、ターミナルでは美しく描かれているが、それは真実ではない！

予告編の正しいチャート

[Nikolai Semko]

Renat Akhtyamov #:

ああ、もう出くわしたよ。）

長い

このタンバリン・ダンスは、ただ単に

このタンバリン・ダンスはすべて、タンバリンが実際にどのように動くのか、そして最も重要なのは、何が価格を動かすのか、そしてその理由を知るためだった。

さて、これですべて明らかになった;)))))

こんな感じ：

この場合、マウスを1回クリックするだけで、全履歴のどの瞬間にも、どの縮尺でも移動できる。

[Renat Akhtyamov]

Nikolai Semko #:

こんな感じ：

とてもクールなものをお持ちですね ;)

[Nikolai Semko]

Renat Akhtyamov #:

あなたは本当にクールなものを得た;)

ありがとう、
WebAssemblyの本格的なものを（Rustで）作りたいんだ。

[Renat Akhtyamov]

Nikolai Semko #:

ありがとう。
WebAssembleyで（Rustで）本格的なものを作りたい。

そうだね。

メインは何も切り替える必要がないこと。

最小の時間枠はスケールされます。

そして、私は困惑しています - 同じ価格で異なるタイムフレームでシグナルが異なるのはなぜですか？

誰が森に行くのか、誰が森に行くのか...。

タイムフレームは本質的には必要ありません。

ティックが必要なのです。

[Nikolai Semko]

Renat Akhtyamov #:

ああ

何も切り替える必要はない。

最短の時間枠はスケーリングされる。

同じ価格で異なるタイムフレームでシグナルが異なるのはなぜですか？

誰が森に行き、誰が森に行くのか...。

タイムフレームは本質的には必要ない。

刻みが必要、それだけだ。

そう、現在のタイムフレームのモデルは非常に不便だ。上級TFの各バーには、異なる数の分バーが含まれている。この構造では、シニアTFがスムーズにジュニアTFに縮小された場合、チャートは一致しません。

私は自分なりに納得のいく解決策を見つけた。

M1からM2、M4、M8、M16、M32、M64、M128、M256、M1024、M2048、M4096、M8192のインデックスTFを形成する。

この場合、どのタイムフレームの各バーも同じ数の M1 を含むことが保証される。

すべてのTFは等しくスケーリングされ、非常に簡単なTFの再計算は、文字通り1つの数学的アクションです。さらに多くの利点があります。

なぜなら、より重要なのは時間密度ではなく、取引密度だからです。

なぜなら、重要なのは時間密度ではなく、取引密度だからです。

さらに進んで、ティックを使って取引密度を測ることもできる。

[Renat Akhtyamov]

Nikolai Semko #:
はい、現在のタイムフレームモデルは非常に不便です。シニアTFの各バーには、異なる数の分バーが含まれています。このような構造では、シニアTFがスムーズにジュニアTFに縮小された場合、チャートは一致しません。

私自身は納得のいく解決策を見つけました。

M1からM2、M4、M8、M16、M32、M64、M128、M256、M1024、M2048、M4096、M8192のインデックスTFを形成する。

この場合、どのタイムフレームの各バーにも、同量の M1 が含まれることが保証される。

すべてのTFは等しくスケーリングされ、文字通り1つの数学的操作で非常に簡単にTFの再計算ができます。その他にも多くの利点があります。

なぜなら、より重要なのは時間密度ではなく、取引密度だからです。

なぜなら、重要なのは時間密度ではなく、取引密度だからです。

さらに進んで、ティックを使って取引密度を測ることもできる。

ちょっと違うかな

スケーリングではなく、圧縮です。

TFが消える。

[Nikolai Semko]

Renat Akhtyamov #:

私はまだ正しくなかった

縮尺ではなく圧縮

TFmasが消える

私はM1しか使っていないので、この問題は存在しない。

おそらく、上級TFのアレイを形成する関連性の同期の問題でしょう。

あるいは、あなたのミス

[leon_17]

グラフィカル・リソースの概念と、グラフ内のグラフィカル・オブジェクトの概念との違いについて教えてください。

例えば、ObjectDelete()関数を使用してCanvasで作成されたグラフィカル・オブジェクトを削除 し、ループ内でCanvasクラスの同じインスタンスを使用して、異なる名前の Canvasオブジェクトを何度も作成するとします。また、ObjectDelete() を使用してグラフィカル オブジェクトを削除します。これは危険なのでしょうか？

ObjectDelete() とC.Destroy()の違いをまだよく理解していないのですが、理解したいのですが...。

[Nikolai Semko]

leon_17 グラフィカル・オブジェクトを削除 し、ループ内でCanvasクラスの同じインスタンスを使用して、異なる名前の Canvasオブジェクトを何度も作成するとします。そしてまたObjectDelete() を使ってグラフィカル・オブジェクトを削除する。何か問題があるのでしょうか？

ObjectDelete() とC.Destroy()の違いがまだよくわからないのですが、理解したいのですが...。

Canvasは、ピクセルの配列がバインドされたオブジェクトです。Resourceはこのピクセルの配列をバインドする責任があります（bool関数CCanvas::Create()を参照）
キャンバスを常に削除して再作成するのは悪い習慣です。
キャンバスは必要なときに作成し、プログラムの終了時など不要になったら削除するのが良い習慣です。

一度キャンバスオブジェクトを作成すれば、それをクリーンアップしたり、毎フレームピクセル配列を上書きしたり、キャンバスのサイズを変更したり、好きな場所に移動したりすることができます。