Canvasでクラウドソーシングのプロジェクトを作る - ページ 31

[Реter Konow]

Реter Konow:
言い換えれば、ある部分は私がやって、ある部分はあなたがやっても、最終的には1つのEAに1つのインターフェースができることになります。これによって、2つのパーツを1つのEAにまとめることができなくなるわけではありません。

とはいえ、別の道を歩むことも可能です。私はコンストラクタを公開し、あなたは私の助けを借りて、必要なGUIを設計してください。そして、コアをプリントアウトしてエンジンに挿入し、Expert Advisorにプラグインすることになります。すぐにマークアップ言語でのグラフィックの書き方を覚え、自分で修正できるようになるので、なおさらです。

[Реter Konow]

とにかく、そういうことです。ここでは、コンストラクタを公開し、その上でGUIをデザイン する方法を伝授する予定です。まだドキュメントがないので、興味のある方はチュートリアルをご期待ください。

トレーニングの内容は以下の通りです。

1.機能的なguiを作る。

2. スタイリング

3.カーネルとエンジンのファイルをプリントアウトしてアプリケーションに差し込む（非常にシンプル - インラインのようなもの）。

4.API機能でgui要素をアプリケーションに接続（APIファイルは自動的に作成されます）。

このスレッドでの公開をお待ちください。

[Алексей Барбашин]

Реter Konow:
とにかく、そういうことです。ビルダーを公開し、その上で設計する方法をこちらのguiで教えます。まだドキュメントがないので、興味のある方はチュートリアルをご覧になってみてください。

トレーニングの内容は以下の通りです。

1.機能的なguiを作る。

2.スタイルデザイン。

3.カーネルとエンジンのファイルを印刷してアプリケーションに接続します（非常にシンプル - インラインのようなもの）。

4.API機能でgui要素をアプリケーションに接続（APIファイルは自動的に作成されます）。

この支店での出版を期待する。

了解です!

[Алексей Барбашин]

---:

録画はしていませんが、一例を送ります。

ドロップダウン・リストが600個あります。

マウスを動かす - イベントと色の変更ごとに、CCanvas全体が再描画されます。

ビットマップのプロパティで最終的なサイズを確認できます - 1500x600 px（あなたの800x500と250msの遅れと比較して）。これは90万画素に相当し、すべて瞬時に再描画されます。 秒単位は論外です。

各リストは、まずそれぞれのキャンバスに独自のサイズで描画され（オーバーフローしないように）、その後、全体的に掘り下げられていきます。つまり、マウスイベント1回あたり600回のResourceCreateを呼び出して いることになります。
つまり、反応速度でわかるように、アニメを見せるにはコマ数が十分なのです。

MTの開発者は、遅延のない満足のいくツールを提供してくれました（ResourceCreate bitmapsのことです）。

この例をオープンソースで見ることは可能でしょうか？

[Dmitry Fedoseev]

Алексей Барбашин:

プロジェクトがクローズドモードになってしまったのは悲しいですね(

どこにも行ってませんよ。

[Dmitry Fedoseev]

Алексей Барбашин:

この例をオープンソースで見ることは可能でしょうか？

kanvasの何がわからないのでしょうか？

1. 他のグラフィックオブジェクトと同様に、イベントに反応する。つまり、マウスの座標を移動しながら追跡したり、マウスや キーボードのクリック イベントに反応したりすることができるのです。

2. 各画素の色を独立して変更することができる。

他に必要なものはありますか？そして、ある程度の頭脳と、無意味に多くの時間を浪費する意志が必要です。

[Алексей Тарабанов]

こんにちは。

[Алексей Барбашин]

Dmitry Fedoseev:

カンヴァスでの作業でわからないことは？

1. 他のグラフィックオブジェクトと同様に、イベントに反応する。つまり、マウスの座標を移動しながら追跡したり、マウスや キーボードのクリック イベントに反応したりすることができます。

2. 各画素の色を独立して変更することができる。

他に必要なものはありますか？次に必要なのは、頭脳と時間を浪費する気持ちです。

まあ、カンヴァス自体はイベントには反応しないんですけどね。しかも、画素ごとに変えられるというのは、明快です。

キャンバスの断片的な再描画の実装に興味を持ちました。

しかし、ごく一部、つまり1つのコントロールだけ再描画すればよい場合でも、キャンバスのフル再描画に落ち着く人が多いようです。

[Dmitry Fedoseev]

Алексей Барбашин:

まあ、カンヴァス自体はイベントには反応しないんですけどね。しかも、画素ごとに変えられるというのは、明快です。

キャンバスの断片的な再描画の実装に興味を持ちました。

しかし、多くの人は、たとえ小さな部分、つまり1つのコントロールを塗り替えるだけであっても、キャンバスの完全な再描画に落ち着いているようです。

キャンバスそのものはイベントに反応しませんが、それだけで存在するわけではありません。

断片的な再描画-それはやり始めることに意義があり、そのような目標があれば明確になる。コントロールの 配列があり、各コントロールは定義された境界を持つべきだと思います。コントロールを再描画する必要がある場合、すべてのコントロールを調べ、他に何がこの領域に該当するかを確認し、そのコントロールのみを再描画する必要があります。せめてこんな感じで。

[Алексей Барбашин]

Dmitry Fedoseev:

カンヴァスそのものは反応しないが、それだけで存在するわけでもない。

断片的な再描画......やり始めることに意義があり、そのような目標があれば明確になるはずです。コントロールの配列があり、各コントロールは定義された境界を持つべきだと思います。コントロールを再描画する必要がある場合、すべてのコントロールを調べて、他にこの領域に該当するものがないか確認し、そのコントロールだけを再描画する必要があるのです。せめて、このように。

まさにその通りに作りました。基本的に標準ライブラリは、イベントの転送の瞬間やその他諸々が非常によくできているので、それをベースにしました。アナトリーは、さまざまな要素のクラスごとにグループ分けをしていますが、スタンダードでは、すべてを1つの基本オブジェクトに還元しています。

その結果、WndObjectは、あらゆるコントロールの最も一般的なプロパティ（サイズ、位置、背景色、ボーダー色、ボーダー厚、テキスト、画像、などなど）の完全な記述を含んでいます。さらに、同じクラスには親コントロールへの参照も含まれています。つまり、コントロールに親が指定されていない場合は、グラフィック上に独自のカンバスオブジェクトを作成し、それ以外の場合は親のカンバスに描画されます。その位置（スタンドアロン、スレーブ）に応じて、アイテムの位置の座標も計算されます。さらに、同じオブジェクトは、そのアイテムが占める親領域の元の記述を含む配列を持つ。このアイデア自体は次のとおりです。要素自体が変更された場合、再描画される前に、ピクセル領域が親ピクセルの行列で満たされ、そのときだけコントロールの新しい状態が適用されます。この方法では、再描画が配列内のすべての要素をバイパスし、入れ子要素で再帰的に行われるので、毎回 canvas 全体を再描画する必要がありません。特定のコントロールの描画と更新については、コントロール全体を作成する際に親の上（または白紙キャンバス）に描画する関数と、与えられたコントロールのみの表示を更新する関数を提案します。つまり、こんな感じです。

イベントモデルでまだ「迷子」：どのレイヤーを変更した後に再描画が必要なのか。

ニコライの例では、キャンバス全体の再描画は非常に高速に行われるため、細部にまでこだわる必要はなく、常に一度に再描画すれば十分なので、原理的にはローカルエリアのデータをわざわざ保存する必要はないことが示されています。