記事"グラフィカルインタフェースX：リストとテーブルの高度な管理コードの最適化(ビルド7)"についてのディスカッション

新しいコメント
 

新しい記事 グラフィカルインタフェースX：リストとテーブルの高度な管理コードの最適化(ビルド7) はパブリッシュされました:

ライブラリコードの最適化が必要です。それは、より規則正しく、学習のために読みやすく理解しやすくなければありません。さらに、以前に作成したコントロール（リスト、テーブル、スクロールバー）の開発が続きます。

したがって、頻繁に繰り返されるコードを配置するための追加の継承中間クラスを作成し、コントロールが取り付けられたフォームポインタを操作するメソッドを作成することにしました。ライブラリスキームのフォームとコントロールの関係に関する部分は次のようになります。

 図3　ライブラリスキームのフォームとコントロールの関係に関する部分

図3　フォームとコントロールの関係に関するライブラリスキームの一部

作者: Anatoli Kazharski

 
MetaQuotes Software Corp.:

公開記事Graphical Interfaces X: 高度なリストとテーブル管理。コードの最適化（ビルド7）：

著者：Anatoli Kazharski

コンボボックスリストで同じことをするには何にアクセスすればよいのでしょうか？

   if(id==CHARTEVENT_CUSTOM+..){

         m_combobox_sm.Clear();

         m_combobox_sm.ItemsTotal(4);

         m_combobox_sm.VisibleItemsTotal(4);

         string items_text[4]={"FALSE","item 1/0","item 2/0","item 3/0"};

         for(int i=0; i<4; i++){m_combobox_sm.SetItemValue(i,items_text[i]);}

      }

 
Pavel Kolchin:

コンボ・ボックスのリストで同じことをするには、何にアクセスすればいいのだろう？

   if(id==CHARTEVENT_CUSTOM+..){

         m_combobox_sm.Clear();

         m_combobox_sm.ItemsTotal(4);

         m_combobox_sm.VisibleItemsTotal(4);

         string items_text[4]={"FALSE","item 1/0","item 2/0","item 3/0"};

         for(int i=0; i<4; i++){m_combobox_sm.SetItemValue(i,items_text[i]);}

      }

CComboBox クラスはリストとスクロール・バーへのポインターを返すメソッドを持っている。CComboBoxクラスはリストとスクロール・バーへのポインターを 返すメソッドを持っている。

   //--- (1) リストと (2) スクロールバーへのポインタを返す。
   CListView        *GetListViewPointer(void)                         { return(::GetPointer(m_listview));                }
   CScrollV         *GetScrollVPointer(void)                          { return(m_listview.GetScrollVPointer());          }
 
素晴らしい記事だ（今読んだところだ）。

現時点で2つの疑問がある：

1.ゼブラスタイルはすべてのテーブルのデフォルトになるのでしょうか？
他のスタイルはどうなりますか？個々の列を別の色で着色するのはどうでしょうか？可能でしょうか？

2.繰り返しメソッドは破棄されるのでしょうか、それとも1つのプログラムブロックに移動されるだけなのでしょうか（プログラム内で関数のユニバーサル化が行われているのでしょうか、それとも増殖し続けるのでしょうか）？

ありがとうございました。
 
Реter Konow:

1.ゼブラスタイルがすべてのテーブルのデフォルトとして設定されるようになりました。

2.他のスタイルはどうなりますか？個々の列を別の色で着色することはできますか？可能でしょうか？
3.繰り返しのメソッドは排除されるのですか、それとも単に1つのプログラムブロックに移動されるのですか（プログラムに関数のユニバーサル化があるのでしょうか、それとも増殖し続けるのでしょうか）？

1.ゼブラスタイルは有効なモードです。デフォルトでは無効になっています。必要であれば、2番目の色を指定して対応するメソッドを呼び出せば十分です。実際、記事に詳しく説明されています。

2.可能でしょう。

3.さらなるコード最適化の 一環として、考えてみます。

 
Anatoli Kazharski:

1.ゼブラスタイル有効モード。デフォルトでは無効。必要な場合は、2番目の色を指定して対応するメソッドを呼び出せば十分です。実は、この記事には詳しく書かれている。

2.可能でしょう。

3.今後のコード最適化の 一環として考えてみます。

3.正直なところ、あなたのプログラムに繰り返しメソッドが含まれていることに少し驚いています。もっと注意深く研究すればよかったのですが......。あなたは私のコードを「最適化されていない山」と考えるかもしれませんが、2回繰り返すメカニズムはありません。似たような関数もない。あなたにもそうしてほしい。)
 
Реter Konow:
3.正直なところ、あなたのプログラムに反復メソッドがあることに少々驚いている。もっと注意深く研究すればよかったのですが...。私のコードを "最適化されていない山 "だと思うかもしれないが、2回繰り返すメカニズムはない。似たような関数もない。あなたにもそうしてほしい。)

エレメントが複数のグラフィカル・オブジェクトで構成されていることがほとんどである今日では、共通の仮想メソッドなしではやっていけない。この部分の最適化とは、すべての要素が描画されるようになる開発段階を意味している。そうなれば、これらの標準的な仮想メソッドは、エレメントの基底クラスにおける単一の宣言と実装に減らすことができるのではないだろうか。

あなたのコードをここで議論するつもりはまったくない。プライベートなことなので、内緒にしておいてください。あなたのコードを見たことについての私の意見は変わっていない。

 
Anatoli Kazharski:

1.現在、要素が複数のグラフィカル・オブジェクトから組み立てられることがほとんどである場合、一般的な仮想メソッドなしでは不可能である。ここでの最適化とは、すべての要素が描画されるようになる開発段階を意味している。そうなれば、これらの標準的な仮想メソッドは、エレメントの基底クラスでの単一の宣言と実装に減らすことができるだろう。

2.あなたのコードをここで議論するつもりはまったくありません。プライベートなことなので、自分の胸にしまっておいてください。あなたのコードを見たことについての私の意見は変わらない。

1.おそらく、あなたが「描画された」コントロールの技術を実装し始めたら、メソッドの重複をなくすことに成功するでしょう。しかし、あなた自身が気づいているように、あなたはそれが役に立つと思い込んで いる。つまり、おそらくそれはないでしょう......。私の意見は、これらのことは関係ないということです。

描画」されたコントロール・エレメントは、いくつかのオブジェクトから作られたエレメントと機能的には変わりませんが、その作成にはまったく別のテクノロジーが必要です。つまり、複数のオブジェクトから構成されるエレメントを作成するための技術とは異なる技術だ。

興味深いことに、描画された要素は複数のオブジェクトから構成されるが、これらのオブジェクトは、一方ではMTオブジェクトではない（単なる描画の詳細である）。

つまり、オブジェクトの数が少なくなることはない。MTオブジェクトから、エレメントの詳細（およびエレメント自体）がプログラムの内部オブジェクトになるだけである。そして、プログラムは（OnChartEvent()関数とは 異なり）それらを見て、定義し、動作する。

この技術は非常に複雑で、コードの高度な最適化を必要とする。


2.このメカニズム全体がどのように機能するのか全く理解できないまま、あなたは急いで意見を述べた。今までのコードのほんの一部しか見ていないのだから、変えることはできない。まあ、私はあなたのそのような意見に我慢しなければならないだろう。残念だ（笑)。


P.S議論はやめましょう。悪気はないんだ。:)

 
Реter Konow:

1.おそらく、「描画」コントロールの技術を導入すれば、メソッドの重複をなくすことができるだろう。しかし、あなた自身が気づいているように、あなたはそれが役に立つと思い込んで いる。つまり--おそらく、それはないでしょう......。私の意見は、これらのことは関係ないということです。

まだ実装してテストしていないので、そう推測しています。

描画」されたコントロール・エレメントは、いくつかのオブジェクトから作られたエレメントと機能的には変わりませんが、その作成にはまったく別のテクノロジーが必要です。つまり、複数のオブジェクトから構成される要素を作成するために使用される技術とは異なる技術である。

興味深いことに、描画された要素は複数のオブジェクトから構成されるが、これらのオブジェクトは、一方ではMTオブジェクトではない（単なる描画の詳細である）。

つまり、オブジェクトの数が少なくなることはない。MTオブジェクトから、要素の詳細（および要素自体）がプログラムの内部オブジェクトになるだけである。そして、プログラムは（OnChartEvent()関数とは 異なり）それらを見て、それらを定義し、それらを使って動作する。

あなたは当たり前のことを書いているので、あなたと議論することさえ面白くない。私は少し違う見方をしている。私は、ライブラリの開発の第2段階の次の記事のひとつで私の意見を述べるつもりだ。

 
Anatoli Kazharski:

私はまだ実装してテストしていないので、そう推測している。

あなたは当たり前のことを書いているので、あなたと議論しても面白くない。私は少し違う見方をしている。ライブラリーの開発第2段階の次の記事で、私の意見を述べるつもりだ。

まあ、なぜあなたにとってこれらのことが明白なのか、私にはわかりません。すでに導入されているのですか？

私たちが話した技術は、どのMQLの記事にも記載されていません。それとも私が間違っているのでしょうか？

重要なのは、外見的な最適化によって この技術に到達することは不可能だということだ。

土台を変える のは最も難しいプロセスだ。スキーム、相互接続、メカニズム......。すべてだ。そして、すべてを新たに修復する。

一般的に、敵がそれを経験することを望むことはできない（しかも、何度も経験しなければならない...）。 そして最終的に、コードは当初とはまったく異なるものになる。


H.Y.あなたの努力の末に、誰かが「あなたのコードは最適化されていないヒープだ」と言ったとしましょう。あなたは怒るだろうか？:)

 
Реter Konow:

まあ、なぜこういうことがあなたにとって明白なのかはわからないけどね。もう実装したのか？

私たちが話していた技術は、MQLのどの記事にも書かれていない。それとも私が間違っていて、リンクを教えてくれる？

私がまだ実装していないことがあるとすれば、それは私がそれについて考えておらず、どのように実装するかわからないということではない。まだ手をつけていないだけだ。あなたとは違って、私は自分のすることすべてを詳細に説明する。時間もかかる。

何かを実行するために記事を読む必要はない。既成の解決策がなければ、自分なりの方法を探す。しかし、あなたには記事を読む機会がある。そして、記事を読まずに、記事の中で説明されていることを質問せずに、手当たり次第に「シュート」を打ち続ける。

つまり、「土台を変える」必要があるのだ。

土台を変える のは最も難しいプロセスだ。スキーム、相互接続、メカニズム......。すべてだ。

そして最終的に、コードは当初とはまったく異なるものになる。

OOPの場合は違います。あなたは、この知識の領域で絶対的なギャップを持っているだけなのです。あなたが「一番難しいプロセス」と思っていることは、OOPを使えば簡単に解決できるのです。

H.I.あなたの努力の末に、誰かが「あなたのコードは最適化されていないヒープだ」と言ったとしましょう。あなたは怒るだろうか？:)

怒るのは私に限ったことではありません。英語のフォーラム参加者の一人が、このスキームを改善する方法を（実装なしで）提案していたのを覚えている。私はそれを使った。最も困難なプロセスは生じなかった。あなたのやり方では、実装の悪さを自慢したり、風車と戦ったりして、長い間自分を苦しめることになる。

123456789101112
新しいコメント