記事"グラフィカルインタフェース I: ライブラリストラクチャの準備(チャプター 1)"についてのディスカッション - ページ 3 12345 新しいコメント Anatoli Kazharski 2016.11.20 17:01 #21 AlexBar3073:...しかし、OOPの観点からは、提案された方法が最も実用的な実装の可能性が高い。:)言うは易く行うは難し。 AlexBar3073: ...例えば、グラフ上でフォームを移動させる機能を考えてみよう。この関数では、フォームのすべてのオブジェクトを列挙する必要があります。なぜか？なぜなら、作成されたすべての要素は、フォーム自体のコンテナ（配列）に配置されるからです。なぜ関数の中で、生成されたすべての要素を列挙する必要があるのでしょうか？コンテナの周りをループして、すべての要素の座標を変更すればいいのでは？...配列(m_objects)の型(CChartObject)に注意してください。この配列には、この要素(CElement)のすべてのグラフィカル・オブジェクトのポインタが格納されています。この場合、動的な型変換を使用することもできますが、そうすると、ポインタの型をさらにチェックする必要があるため、コードがさらに複雑になり、リソースの消費が激しくなります。Delete()や類似のメソッドに関しては、すべてのオブジェクトがCChartObject 型を持っているので、それらをループすることができる（まだ手をつけていないだけだが）。すべての要素が描画されるようになるライブラリー開発の第2段階への移行後は、すべてがもっと簡単になるだろうと私は慎重に考えている。つまり、要素は1つ、オブジェクトは1つ（bmp）になる。 Igor Volodin 2016.11.28 11:48 #22 Anatoli Kazharski:ポインター型の追加チェック。MQLでポインターの型をチェックするにはどうすればいいのでしょうか？私の資料によると、この言語にはそのための手段がありません。オブジェクトが特定のクラスのインスタンスであるかどうか、あるいは階層内のクラスの子孫であるかどうかをチェックしたいのです。例えば、私はMVCパターンを実装しており、編集可能なプロパティを持つ特定のモデル（共通の祖先を持つ）に対して、1つのビューオブジェクトをサブスクライブしています。このオブジェクトのプロパティテーブルを表示するためです。モデルに変更があった後、リスナー（ビュー）は再描画され、モデルオブジェクトが渡されます。ここで、モデルを（プロパティを返すことができる）モデル階層型の1つにキャストしなければなりません。しかし、正しい型のオブジェクトが到着したかどうかをチェックすることは不可能です。 理論的には、インターフェイスのアプリケーションを作成するサードパーティのプログラマが間違えて、このビューを別のモデル（編集可能なプロパティを持つ祖先を持たない別の階層のもの）に署名してしまう可能性があります。これは実行時に処理できず、アプリケーションはクラッシュします。Anatoli Kazharski: すべての要素が描画されるようになるライブラリ開発の第2段階に移行すれば、すべてがずっと簡単になると、私は慎重に考えています。つまり、1つの要素、1つのオブジェクト（bmp）になります。私は数年前にこの方法をとったばかりだ。まず、インターフェースのDOMモデル、プリミティブの描画、ビューの集約、イベント（popup、stop）の受け渡しなどを作った。すべてはMQLグラフ・オブジェクトに描画され、原理的にはうまくいった。しかし、オブジェクトの数が200を超えると、各オブジェクトの再描画にかかるオーバーヘッドのために動作が遅くなり始めた。そのため、キャンバスが登場するまで、さらに1年間、すべてが放棄された。そして、ビューの基本的な描画メソッドと更新ロジックを置き換えることで、他は何も変えることなく、すべてがすぐにキャンバスに移行された。現在では、画面上に数千のビューがあっても描画が遅れることはありません。なぜなら、すべての描画と比較はメモリ上で非常に高速に行われ、出力は画像だけ、つまりチャート上のオブジェクトから1つの要素だけだからです。しかし、この1年、自由な時間がなく、UIライブラリの開発は事実上ストップしている。 Igor Volodin 2016.11.28 12:32 #23 根拠のない話にならないように、1つのCanvas要素にUIをベースに構築されたインターフェースの例を挙げよう。 --- 2016.11.28 12:34 #24 Igor Volodin:根拠がないものにならないように、1つの要素にUIに基づいて構築されたインターフェースの例を挙げよう。+ 好きなもの ) Anatoli Kazharski 2016.11.28 12:34 #25 Igor Volodin:MQLでポインターの型をチェックするにはどうすればよいですか？私の資料によると、この言語にはそのための手段がありません。オブジェクトが特定のクラスのインスタンスであるかどうか、または階層内のクラスの子孫であるかどうかをチェックしたいのです。例えば、私はMVCパターンを実装しており、編集可能なプロパティを持つ特定のモデル（共通の祖先を持つ）に対して、1つのビューオブジェクトをサブスクライブしています。このオブジェクトのプロパティテーブルを表示するためです。モデルに変更があった後、リスナー（ビュー）は再描画され、モデルオブジェクトが渡されます。ここで、モデルを（プロパティを返すことができる）モデル階層型の1つにキャストしなければなりません。しかし、正しい型のオブジェクトが到着したかどうかをチェックすることは不可能です。 理論的には、インターフェイスのアプリケーションを作成するサードパーティのプログラマが間違えて、このビューを別のモデル（編集可能なプロパティを持つ祖先を持たない別の階層のもの）に署名してしまう可能性があります。これは実行時に処理できず、アプリケーションはクラッシュします。...dynamic_castを 使う？私がこのライブラリを開発し始めたとき、dynamic_castは まだ利用できませんでした。次のようなものです（ここからの 例）：class CFoo { };class CBar { };//+------------------------------------------------------------------+//| スクリプト番組開始機能|//+------------------------------------------------------------------+void OnStart() { void *vptr[2]; vptr[0]=new CFoo(); vptr[1]=new CBar();//--- for(int i=0;i<ArraySize(vptr);i++) { if(dynamic_cast<CFoo *>(vptr[i])!=NULL) Print("CFoo * object at index ",i); if(dynamic_cast<CBar *>(vptr[i])!=NULL) Print("CBar * object at index ",i); } CFoo *fptr=vptr[1]; // ポインタ変換エラー、vptr[1]はCFooオブジェクトではない }//+------------------------------------------------------------------+//---イゴール・ヴォロディン私は数年前、この方法に従いました。まずインターフェースのDOMモデルを作り、プリミティブの描画、ビューの集約、イベント（popup、stop）の受け渡しなどを行いました。すべてはMQLグラフオブジェクトに描画され、原理的にはうまくいきました。しかし、オブジェクトの数が200を超えると、各オブジェクトの再描画にかかるオーバーヘッドのために動作が遅くなり始めた。そのため、キャンバスが登場するまで、さらに1年間、すべてが放棄された。そして、ビューの基本的な描画メソッドと更新ロジックを置き換えることで、他は何も変えることなく、すべてがすぐにキャンバスに移行された。今では、画面上に数千のビューがあっても、描画が遅れることはありません。なぜなら、すべてがメモリ上で非常に迅速に描画され、比較されるからです。この1年間、暇がなくてUIライブラリーの開発が事実上ストップしていたのは事実だ。これはとても興味深いことです。独自の入力フィールドも実装したのですか？ Discussion of article "Graphical Errors, bugs, questions Need help to debug Anatoli Kazharski 2016.11.28 12:38 #26 Igor Volodin:根拠のない話にならないように、1つのBitmap要素にUIをベースに構築されたインターフェースの例を挙げよう。クールだね。例をありがとう。)Canvasでクラウドソース・プロジェクトを作るという トピックがありました。 Igor Volodin 2016.11.28 12:54 #27 Anatoli Kazharski:dynamic_castを 使うのでしょうか？私がこのライブラリーの開発を始めたときには、dynamic_castは まだなかったんだ。CFoo *foo = dynamic_cast<CFoo *>(&bar); // クリティカルな実行エラーは発生しない そうだったんですか。ありがとう。8月に追加されたことがわかった。NULLを返してクリティカル・エラーが起きないなら、それはもうとても良いことだ。作業できる )Anatoli Kazharski: 独自の入力フィールドも実装していますか？入力フィールドでは次のようにします： 編集可能フィールドのオブジェクトにフォーカスが当たると、必要な設定の編集可能フィールドのグラフィカルオブジェクトと現在の値がUIに挿入されます、 blur イベントでフィールドの値が保存されます（そしてシステムグラフオブジェクト-Editは削除されます）。そして、その値はbmp上にテキストで表示される。 Anatoli Kazharski 2016.11.28 13:09 #28 Igor Volodin:...入力フィールドでは、次のように行われます： 編集可能フィールドのオブジェクトのフォーカス イベントで、現在の値を持つ必要な構成の編集可能フィールドのグラフィカルオブジェクトがUIに挿入されます、 blur イベントでは 、フィールドの値が保存されます（システムグラフオブジェクト-Editは削除されます）。そして、その値はbmp上にテキストとして表示される。なるほど。明快な説明をありがとう。 これがベストな選択肢だと思いますが、すべてを1つのオブジェクトに描画するような方法で実現したいと思います。そうすれば、どんな環境でGUIを作っても 問題なく、完全な独立性と経験を得ることができる。例えば、キャンバスだけがあって、他には何もないとしよう。) Igor Volodin 2016.11.28 13:18 #29 Anatoli Kazharski:クールだね。例をありがとう。)あなたの推薦が役に立つトピックがここにあった：クラウドソーシングでキャンバスのプロジェクトを行うありがとう。インターフェイスに関するあなたの作業量を見ると、大きな賞賛を送りたい。私だったらできなかったでしょう。第一に宣伝、第二に一貫性。クラウドソーシング？リスキーだ。もちろん、安定した収入と自由な時間があれば、社会のために働くことは可能だ。しかし、MQL社会はそれをフリーではなく、商用製品に使うだろう。そしてGPLライセンスだけではそれを禁止することはできない。要するに、私には利益が見込めないのだ。 Igor Volodin 2016.11.28 13:20 #30 Anatoli Kazharski:でも最終的には、すべてを1つのオブジェクトに描画するような形で実現したいと思っています。そうすれば、どのような環境でグラフィック・インターフェイスを作るかは 関係なく、完全な独立性と経験を得ることができるだろう。例えば、キャンバスだけがあって、他には何もないとしよう。) Renateにシステムバッファを操作する関数を求めれば、すべてを描画することができる。 12345 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
...しかし、OOPの観点からは、提案された方法が最も実用的な実装の可能性が高い。:)
言うは易く行うは難し。
...
例えば、グラフ上でフォームを移動させる機能を考えてみよう。
この関数では、フォームのすべてのオブジェクトを列挙する必要があります。なぜか？なぜなら、作成されたすべての要素は、フォーム自体のコンテナ（配列）に配置されるからです。なぜ関数の中で、生成されたすべての要素を列挙する必要があるのでしょうか？コンテナの周りをループして、すべての要素の座標を変更すればいいのでは？
...
配列(m_objects)の型(CChartObject)に注意してください。この配列には、この要素(CElement)のすべてのグラフィカル・オブジェクトのポインタが格納されています。この場合、動的な型変換を使用することもできますが、そうすると、ポインタの型をさらにチェックする必要があるため、コードがさらに複雑になり、リソースの消費が激しくなります。
Delete()や類似のメソッドに関しては、すべてのオブジェクトがCChartObject 型を持っているので、それらをループすることができる（まだ手をつけていないだけだが）。
すべての要素が描画されるようになるライブラリー開発の第2段階への移行後は、すべてがもっと簡単になるだろうと私は慎重に考えている。つまり、要素は1つ、オブジェクトは1つ（bmp）になる。
ポインター型の追加チェック。
MQLでポインターの型をチェックするにはどうすればいいのでしょうか？
私の資料によると、この言語にはそのための手段がありません。オブジェクトが特定のクラスのインスタンスであるかどうか、あるいは階層内のクラスの子孫であるかどうかをチェックしたいのです。
例えば、私はMVCパターンを実装しており、編集可能なプロパティを持つ特定のモデル（共通の祖先を持つ）に対して、1つのビューオブジェクトをサブスクライブしています。このオブジェクトのプロパティテーブルを表示するためです。モデルに変更があった後、リスナー（ビュー）は再描画され、モデルオブジェクトが渡されます。
ここで、モデルを（プロパティを返すことができる）モデル階層型の1つにキャストしなければなりません。しかし、正しい型のオブジェクトが到着したかどうかをチェックすることは不可能です。
理論的には、インターフェイスのアプリケーションを作成するサードパーティのプログラマが間違えて、このビューを別のモデル（編集可能なプロパティを持つ祖先を持たない別の階層のもの）に署名してしまう可能性があります。これは実行時に処理できず、アプリケーションはクラッシュします。
すべての要素が描画されるようになるライブラリ開発の第2段階に移行すれば、すべてがずっと簡単になると、私は慎重に考えています。つまり、1つの要素、1つのオブジェクト（bmp）になります。
私は数年前にこの方法をとったばかりだ。まず、インターフェースのDOMモデル、プリミティブの描画、ビューの集約、イベント（popup、stop）の受け渡しなどを作った。すべてはMQLグラフ・オブジェクトに描画され、原理的にはうまくいった。しかし、オブジェクトの数が200を超えると、各オブジェクトの再描画にかかるオーバーヘッドのために動作が遅くなり始めた。そのため、キャンバスが登場するまで、さらに1年間、すべてが放棄された。そして、ビューの基本的な描画メソッドと更新ロジックを置き換えることで、他は何も変えることなく、すべてがすぐにキャンバスに移行された。現在では、画面上に数千のビューがあっても描画が遅れることはありません。なぜなら、すべての描画と比較はメモリ上で非常に高速に行われ、出力は画像だけ、つまりチャート上のオブジェクトから1つの要素だけだからです。
しかし、この1年、自由な時間がなく、UIライブラリの開発は事実上ストップしている。
根拠のない話にならないように、1つのCanvas要素にUIをベースに構築されたインターフェースの例を挙げよう。
根拠がないものにならないように、1つの要素にUIに基づいて構築されたインターフェースの例を挙げよう。
MQLでポインターの型をチェックするにはどうすればよいですか？
私の資料によると、この言語にはそのための手段がありません。オブジェクトが特定のクラスのインスタンスであるかどうか、または階層内のクラスの子孫であるかどうかをチェックしたいのです。
例えば、私はMVCパターンを実装しており、編集可能なプロパティを持つ特定のモデル（共通の祖先を持つ）に対して、1つのビューオブジェクトをサブスクライブしています。このオブジェクトのプロパティテーブルを表示するためです。モデルに変更があった後、リスナー（ビュー）は再描画され、モデルオブジェクトが渡されます。
ここで、モデルを（プロパティを返すことができる）モデル階層型の1つにキャストしなければなりません。しかし、正しい型のオブジェクトが到着したかどうかをチェックすることは不可能です。
理論的には、インターフェイスのアプリケーションを作成するサードパーティのプログラマが間違えて、このビューを別のモデル（編集可能なプロパティを持つ祖先を持たない別の階層のもの）に署名してしまう可能性があります。これは実行時に処理できず、アプリケーションはクラッシュします。
...
dynamic_castを 使う？私がこのライブラリを開発し始めたとき、dynamic_castは まだ利用できませんでした。
次のようなものです（ここからの 例）：
class CBar { };
//+------------------------------------------------------------------+
//| スクリプト番組開始機能|
//+------------------------------------------------------------------+
void OnStart()
{
void *vptr[2];
vptr[0]=new CFoo();
vptr[1]=new CBar();
//---
for(int i=0;i<ArraySize(vptr);i++)
{
if(dynamic_cast<CFoo *>(vptr[i])!=NULL)
Print("CFoo * object at index ",i);
if(dynamic_cast<CBar *>(vptr[i])!=NULL)
Print("CBar * object at index ",i);
}
CFoo *fptr=vptr[1]; // ポインタ変換エラー、vptr[1]はCFooオブジェクトではない
}
//+------------------------------------------------------------------+
//---
私は数年前、この方法に従いました。まずインターフェースのDOMモデルを作り、プリミティブの描画、ビューの集約、イベント（popup、stop）の受け渡しなどを行いました。すべてはMQLグラフオブジェクトに描画され、原理的にはうまくいきました。しかし、オブジェクトの数が200を超えると、各オブジェクトの再描画にかかるオーバーヘッドのために動作が遅くなり始めた。そのため、キャンバスが登場するまで、さらに1年間、すべてが放棄された。そして、ビューの基本的な描画メソッドと更新ロジックを置き換えることで、他は何も変えることなく、すべてがすぐにキャンバスに移行された。今では、画面上に数千のビューがあっても、描画が遅れることはありません。なぜなら、すべてがメモリ上で非常に迅速に描画され、比較されるからです。
この1年間、暇がなくてUIライブラリーの開発が事実上ストップしていたのは事実だ。
これはとても興味深いことです。独自の入力フィールドも実装したのですか？
根拠のない話にならないように、1つのBitmap要素にUIをベースに構築されたインターフェースの例を挙げよう。
クールだね。例をありがとう。)
Canvasでクラウドソース・プロジェクトを作るという トピックがありました。
dynamic_castを 使うのでしょうか？私がこのライブラリーの開発を始めたときには、dynamic_castは まだなかったんだ。
そうだったんですか。ありがとう。8月に追加されたことがわかった。NULLを返してクリティカル・エラーが起きないなら、それはもうとても良いことだ。作業できる )
独自の入力フィールドも実装していますか？
入力フィールドでは次のようにします：
編集可能フィールドのオブジェクトにフォーカスが当たると、必要な設定の編集可能フィールドのグラフィカルオブジェクトと現在の値がUIに挿入されます、
blur イベントでフィールドの値が保存されます（そしてシステムグラフオブジェクト-Editは削除されます）。そして、その値はbmp上にテキストで表示される。
Igor Volodin:
...
入力フィールドでは、次のように行われます：
編集可能フィールドのオブジェクトのフォーカス イベントで、現在の値を持つ必要な構成の編集可能フィールドのグラフィカルオブジェクトがUIに挿入されます、
blur イベントでは 、フィールドの値が保存されます（システムグラフオブジェクト-Editは削除されます）。そして、その値はbmp上にテキストとして表示される。
なるほど。明快な説明をありがとう。
これがベストな選択肢だと思いますが、すべてを1つのオブジェクトに描画するような方法で実現したいと思います。そうすれば、どんな環境でGUIを作っても 問題なく、完全な独立性と経験を得ることができる。例えば、キャンバスだけがあって、他には何もないとしよう。)
クールだね。例をありがとう。)
あなたの推薦が役に立つトピックがここにあった：クラウドソーシングでキャンバスのプロジェクトを行う
ありがとう。インターフェイスに関するあなたの作業量を見ると、大きな賞賛を送りたい。私だったらできなかったでしょう。第一に宣伝、第二に一貫性。
クラウドソーシング？リスキーだ。もちろん、安定した収入と自由な時間があれば、社会のために働くことは可能だ。しかし、MQL社会はそれをフリーではなく、商用製品に使うだろう。そしてGPLライセンスだけではそれを禁止することはできない。
要するに、私には利益が見込めないのだ。
でも最終的には、すべてを1つのオブジェクトに描画するような形で実現したいと思っています。そうすれば、どのような環境でグラフィック・インターフェイスを作るかは 関係なく、完全な独立性と経験を得ることができるだろう。例えば、キャンバスだけがあって、他には何もないとしよう。)