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

 
Anatoli Kazharski:

ElementSetで、(1)プロパティと値、または(2)プロパティ、モディファイアと値を指定する必要があります。

はい、コントロールプロパティへのアクセスという点では万能です。

一般に、PropGet/Set は、継承されたインタフェースが初期状態では未知である場合に、テンプレートクラスを処理するための良いメカニズムです。


しかし、議論を最初の質問に戻したいのです。プログラマー向けに、コントロールの配色に関する「クイックスタート」を作るにはどうしたらいいでしょうか?

また、機能的なもの(SetBgColor や SetProp(Enum_Color, ) など)ではなく、より普遍的な属性のクラスを実装することは可能でしょうか?
これにより、すべてのコントローラが1つの汎用的な属性クラスにアクセスできるようになり、コーダーはどの色がどのコントローラで使用されているかを容易に理解することができます。

しかし、これはすべて、私の計画に関する推論です。移行を開始するときに、まだあまり変化がないことを除外しない。だから、上に書いたことは、もはやここで議論されているテーマとは関係ないかもしれない。)

納得のいくまで開発すべきです)より多くのコーダーが理解すればするほど、フィーチャー・クラスに入るための敷居も低くなります。
 
o_O:

原則的には賛成ですが、どのような色を持っていて、何が変えられるのかが明確になります。

では、「テーマ」は未使用のパラメーターの冗長性を意味するのでしょうか?

はい、すべてのバリエーションで、冗長です。しかし、その場合、前のテーマを再描画して値を変更することで、新しいテーマを作ることができるので便利です。Windowsのテーマと同じですね。

追伸

また、現在のテーマで使われている値とは異なる値をコーダーが大量に変更することについては懐疑的です。Delphiのプロジェクトで、最初に自分の好きな色でインターフェイスを塗ろうとすると、その後システムのテーマを変えても変わらない、というようなことを思い出します。

そして、なぜデザインスタイルをどこかで汚してしまうのか。既存のテーマからテーマクラスを継承し、その中の変更する必要がある値のみをやり直します。

 

こんなCSS 技術もあります

1) 既知のもので、よく知られているもの

2)身近で多目的な存在

3) タグ==コントロールが原則なので、我々のタスクに適している


を試してみてください、意図したとおりに動作するはずです。

 
o_O:

CSSの 技術がある


そして、そのままLESS / SCSS(SASS)へ。
 
Igor Volodin:

そして、そのままLESS / SCSS(SASS)へ。

Lassは良いものでしょうが、その機能は必要ありません。

私たちは、カスケード^選択的^ポイントごとにスタイルを構築し、再定義するという原則を純粋に受け止めています - 彼らがどのようにそれを行うか。

 

そして、さまざまな解像度に対応するレスポンシブデザインオプションを必ず入れてください。CSSのメディアクエリを参照

そして、ある部分はサイズが固定され、ある部分はどこまでも伸びていくかもしれません。

 

フォーラムの皆さん、やる気をなくさせるつもりは毛頭ありませんが、私の意見としては、今回議論されている技術は非常に複雑で、共同で分散した努力では実現できないものだと思います。それぞれの理解度、専門性、アプローチが異なるため、効果的に組み合わせることはできませんが...。また、私たちは距離や国によってさえも隔てられています。

私の結論は、この技術は、一人の開発者が長い時間をかけて 取り組んだとしても、実現可能だということです。1年以上かもしれませんね。しかし、この人は、この仕事にあまりにも多くの努力と魂を注ぎ込み、ただただ疲れ果ててしまったので、この技術をクラウドソーシングすることはないだろう...。彼のプロジェクト であり、自由に配布しない権利もある。(最初のうちはそうかもしれませんが、いつもそうとは限りません)。

この技術は、すでにMQLに実装されていると思います。

追伸:とはいえ、たとえそうであっても、もう一度実装してみてはいかがでしょうか。))

 
Igor Volodin:

なぜ役に立つのか

1.ビットマップ上のインターフェイスが高速である。そのため、システムインターフェースとほとんど見分けがつかないほど高速です。例えば、半透明のエレメントをグラデーションで実装しましたが、半透明のグラデーションを持つ他のオブジェクトのカラーミキシングやアルファチャンネルの計算を考慮して、それらが動いても、目に見える遅延なくスムーズにレンダリングされます。

2.インターフェイスはスケーラブルです。アプリケーションをより複雑にしても、大量のグラフオブジェクトの削除や作成が原因で動作が遅くなることはないでしょう。再描画のコストは最低限、絵を置き換えるだけですから、千分の一秒単位です。

3.例えば、独自のイベントプールを提供できるため、既製のコントロールを作成し、新しいコントロールを作成する機能を提供することができます。

OnMouseDown - LKMが押されました。

OnMouseUp - マウスボタンが押されました.

OnMouseHoverOn - マウスカーソルがオブジェクトに重なる。

OnMouseHoverOut - マウスカーソルをオブジェクトから遠ざける.

OnMouseClick - 押して、オブジェクトの境界内でクリックします。

OnMouseDblClick - オブジェクトの境界内でマウスをダブルクリックします.

OnDragStart - マウスの左ボタンが押された状態で、移動の開始時に1度だけ発生するイベント

OnDragMove - マウスの左ボタンで移動するときに発生するイベント.

OnDragEnd - LKMで移動した後に発生するイベント.

OnPut - オブジェクトが別のオブジェクトにキャストされます。

OnGet - オブジェクトが別のオブジェクトにダンプされます。

OnFocus - オブジェクトにフォーカスが当たった

OnBlur - オブジェクトがフォーカスを失う

OnResize - オブジェクトのサイズが変更されました。

OnParentResize - 親オブジェクトのサイズが変更されました。

OnKeyPress - キーが押された

OnChange - フィールドの値が変更されました。

など

以下は少し誇張していますね。

ビットマップの描画速度は、そのサイズに依存します。パーツの再描画時にウィンドウを表すビットマップ全体を再描画すると、レスポンスが遅くなります(検証済み)。当然、ビットマップの領域のみを再描画させるという解決策になります。

しかし、ウィンドウを表すビットマップパターンの一部だけを再描画するためには、ビットマップのデジタルマスクをメモリ(配列)に格納する必要があります。次に、このマスクの中を移動して、その中から目的のパターンを 見つけます。ただし、窓が多い場合があることを考慮してください。ここで、すべてのウィンドウのマスクを保存するために必要なメモリ量を評価します。どのウィンドウを覚えていて、どのウィンドウをいつ「忘れる」かを選択する優先順位を考えることができます。しかし、それは簡単なことではありません。

再描画は配列の値を書き換えることであり、1000000個の値(ウィンドウ画像とビットマップのおおよそのピクセル数)を書き換える必要がある場合、「1000分の1秒」ではなく「秒」になることを理解する必要があるのです。したがって、ウィンドウを完全に描画するのは一度だけにして、メモリに保存し、イベント時に、各オブジェクトを個別に再描画する必要があります。そうすれば、スピードは非常に速くなります。

どうやら、個別のオブジェクトだけを実装しているようですが、ウィンドウを作成して、そこに要素のインタラクティブ性を実装してみてください。 私の言っていることが理解できると思います。

引用されたイベントについては、プログラムへの実装は描画制御の 技術とは無関係であり、どのようなインターフェースにも存在するはずです。

 
Реter Konow:

...

オブジェクト単体で実装しているようですが、ウィンドウを作ってそこにエレメントのインタラクティブ性を実装してみてください。 私の言っていることがわかると思います。

...

この記事(リンク)から読み、そこにあるGIFアニメーションの 例も見てください。
Обсуждение статьи "Графические интерфейсы I: Подготовка структуры библиотеки (Глава 1)"
Обсуждение статьи "Графические интерфейсы I: Подготовка структуры библиотеки (Глава 1)"
  • www.mql5.com
Включение в проект классов для хранения указателей и обработки событий.
 
Реter Konow:

を若干誇張していますね。

ビットマップの描画速度は、そのサイズに依存します。ウィンドウを表すビットマップ全体を再描画すると、レスポンスが悪くなります(テスト済み)。当然のことながら、再塗装する部分の面積だけを確保することです。

しかし、ウィンドウを表すビットマップ描画の一部だけを再描画するためには、そのビットマップのデジタルマスクをメモリ上に(配列で)格納しておく必要があるのです。次に、このマスクの中を移動して、その中から欲しい部分を 探します。ただし、窓が多い場合があることを考慮してください。ここで、すべてのウィンドウのマスクを保存するために必要なメモリ量を評価します。どのウィンドウを覚えていて、どのウィンドウをいつ「忘れる」かを選択する優先順位を考えることができます。しかし、これは簡単なことではありません。

再描画は配列の値を書き換えることであり、1000000個の値(ウィンドウ画像とビットマップのおおよそのピクセル数)を書き換える場合は、「1000分の1秒」ではなく「秒」になることを理解する必要があるのです。したがって、ウィンドウを完全に描画するのは一度だけにして、メモリに保存し、イベント時に、各オブジェクトを個別に再描画する必要があります。そうすれば、スピードは非常に速くなります。

おそらく、単体のオブジェクトしか実装していないと思いますが、ウィンドウを作成して、そこに要素のインタラクティブ性を実装してみてください。 私の言っていることが理解できると思います。

引用されたイベントについては、プログラムへの実装は描画制御の技術とは関係なく、どのようなインターフェースにも存在しなければならないものです。

少し説明したいことがあります。

まず、ウィンドウを構成するすべての要素をデジタルマスクとして作成します。次に、ResourceCreate()でビットマップを作成します。チャート上の窓を手に入れる。

そして、このウィンドウのインターフェース上にマウスを移動させ、例えばポインティングイベント(_Object_Pointed)を捕捉するのです。

ここでは、オブジェクト・インタラクティビティの実装について、悪い方と良い方の2つのアプローチについて説明します。

1.もし、ウィンドウのデジタルマスクが最初に作成された後に配列に保存されて いなければ、そのウィンドウの描画の詳細を変更するために、完全に再作成する必要があります。つまり、再デジタル化する必要があるのです。ResourceCreate()に渡すために、すべてのウィンドウパターンのピクセルカラー値で配列を初期化 する必要があるため、これ自体に時間がかかるのです。ウィンドウが大きく、詳細な情報が含まれているほど、時間がかかります(約250ミリ秒〜2秒)。そうして、あらゆる要素のあらゆる事象について。このオプションは欠陥が多すぎる。

2.数値マスクが配列に格納されている場合、そのウィンドウの特定の部分に関連する値のみを再初期化する必要があります。配列の中からその部分を探し出し、その値を書き換えます。次に、 - ResourceCreate()に配列を送り、すぐにその結果を取得します。

それが、実は技術のすべてなんです。ほとんど))