記事"グラフィカルインタフェース III： シンプルなボタンと多機能ボタン(チャプター 1)"についてのディスカッション
私の個人的な経験から言うと、ウィンドウを "ラバー "にする（つまりダイナミックにする）のは簡単なことではありません。オブジェクトのないシンプルな形のウィンドウの場合、伸縮可能にするのは簡単だが、ここではユーザーとウィンドウの間のインタラクションの概念全体が必要になる。標準的なウィンドウズ・ウィンドウには、少なくとも8つのハンドルがあり、それをつかむことで、ウィンドウの大きさをどの方向にも変えることができる。
私の経験から、それを実装する方法を知っていますし、同様のものはすでに出版予定のコントロールの1つに実装されています。その例は、このシリーズの次の記事で紹介する。
例えば「アラート」ウィンドウ。このようなウィンドウの動作を実装するのは簡単ではありません。
何が難しいと思いますか？このウィンドウには3列の表と「閉じる」ボタンしかない。ウィンドウを水平方向にリサイズすると、列の幅は現在のウィンドウ幅に比例して変化する。私としては、列の幅は固定にした方がいい。そして、ウィンドウ幅が変更されたら、水平スクロールバーを 表示させる。いずれにせよ、これらはすべて特定のインターフェイス要素のクラスの中にあり、そのような要素を作ってライブラリ・エンジンに接続することを妨げるものは何もない。
連載第18回 では、水平・垂直スクロールバーを持つテーブルの3つのクラスを公開します。現在の実装では、これらは「ゴムのような」ものではありませんが、もし本当に必要であれば、後でライブラリの第2バージョンでそのような機能を作るつもりです。
さて、多数の異なる種類のオブジェクトを含む通常のウィンドウに戻ろう。オブジェクトは互いにいろいろな種類の関係にあることに気づくだろう。つまり、ウィンドウのサイズを変更すると、それぞれの位置（またはサイズ）が異なって変化するのだ。例えば、ある絵はペンの後ろに移動し、他の絵はその場に留まる。入力フィールドの 長さが変わるものもあれば、逆に同じ大きさを保つものもある。したがって、このタスクは最も簡単に解決できるもののひとつであると言うのは、少し軽率だと思う）。
クラスにメソッドを追加することで解決でき、そのメソッドの助けを借りて、要素を配置したり、ウィンドウの大きさに応じてサイズを変更したりできる。現時点では、これらはすべて、ライブラリの最初のバージョンが公開された後に解決できる小さな課題である。
1.インターフェイスは、ウィンドウやオブジェクトの形や、様々なイベント（ユーザーのアクションに対する反応）に対する振る舞いを標準化します。グラフィカル・オブジェクトをそのパラメータや機能とリンクさせる標準的な方法、ウィンドウ、オブジェクト、イベントの明確な分類がある。この の標準化は、パネルには全く存在しない。
2- インターフェースは、ユーザーとアプリケーションのインタラクションの可能性が計り知れないほど大きい。
ユーザーが必要とするサイズや色を採用し、その外観を簡単に変更することができる。いわば、ユーザーの要求に "適応 "する。
3.そのグラフィカルな利点のおかげで、パネルで表示するよりもはるかに多くの情報をウィンドウに表示することができます。
インターフェース作成への第一歩は、間違いなく踏み出したことでしょう。ライブラリの中で、ウィンドウやコントロールのパラメータを標準化し、合理的な範囲内で特定のプロパティを上書きすることは他の人に任せています。次の段階は、ユーザーとインターフェースとのインタラクションの可能性を広げることです。そして、ここには多くの問題（ウィンドウサイズの変更など）があり、それを解決しなければ、あなたのライブラリは新しい世代の開発者のためのパネルの標準化の一形態にとどまる危険性があります。 さて、そして、インターフェースへの道のりの最後のステップ - アプリケーションによって処理される情報とウィンドウの相互作用のメソッドの作成 - ですが、パネルでできることよりもはるかに大量に。
異論があれば喜んで聞きます。:)
Реter Konow:
1.難しいのは、特定のウィンドウとその動作をコピーすることではなく、オブジェクトとウィンドウ・ハンドルの間のあらゆるタイプのリンクを実装できるような方法でウィンドウを管理するシステムを作ることなのだ。
2.これは非常に大きなチャンスを与えてくれますが、やはりOOPでは効果的な実装はできません。
3.多くのコードを書かなければならなくなる。
4.私の結果とあなたの結果を比較した場合、有利なのはあなたの方ではないでしょう）。
1.理解できないのですが、私たちが話しているあなたの実装とは何ですか？あなたの開発したものと本格的に比較する機会は、すでにあるし、連載の残りの記事が公開されるにつれてもっと増えるだろう。何と比較すればいいんだ？))
2.OOPは、これらすべてを効果的に管理する機会を与えてくれます。あるいは、なぜそう思うのか、あなたの考えを詳しく述べてください。できれば、この問題やこの問題を示す簡単なコードを使った具体例を挙げてください。
3.私は、このタスクやあのタスクの複雑さを恐れないし、そのためにどれだけのコードを書く必要があるかは問題ではない。
4.どんな利点があるのか理解できない。私はあなたより優位に立とうとは思っていません。))
リタグ・コナウ
しかし、多くのデベロッパーがマーケットプレイスで提供しているパネルとインターフェイスの間に存在する違いについて疑問を呈したい。見た目はクラシックなインターフェイスに似ているにもかかわらず（すべてではありませんが）、なぜ本格的なインターフェイスとして認識されていないのでしょうか？どのように違うのか？ウィンドウやコントロールの外見がクラシックインターフェースと似ているだけでは不十分なのはなぜか？どの時点でパネルがインターフェースとして「認識」されるのか？私の意見を述べよう：
...
あなたは間違いなくインターフェイスを作るための第一歩を踏み出した。あなたのライブラリでは、ウィンドウとコントロールのパラメータを標準化し、一方で合理的な範囲内で特定のプロパティをオーバーライドする可能性を残しています。次のステップは、ユーザーとのインタラクションの可能性を広げることです。そして、ここには多くのタスク（ウィンドウのサイズ変更など）があり、これがなければ、ライブラリは新しい世代の開発者のためのパネルの標準化という形でしか残らない危険性があります。
第一段階と第二段階に関しては、連載記事がすべて公開されるまで待つこと。現時点では、まだ10 記事しか掲載されていない。全部で25 記事になる予定だ。
リタグ・コナウ
さて、インターフェイスへの道のりの最後のステップは、ウィンドウがアプリケーションによって処理される情報と相互作用するためのメソッドを作成することですが、パネルが実現できるよりもはるかに大きなボリュームになります。
もし私の理解が正しければ、そのような例はすでにあります。これには、大量のデータを保存、検索、表示するためのテーブル・クラスが含まれます。
テーブルを配置したウィンドウを作成したとします。その表が大きすぎたとします（取引履歴の統計指標の表とします）。あなたはウィンドウに垂直スクロール バーを設置しました（または自動的に表示されました）。しかし、これでは十分ではありません。あなたは、ユーザーが必要なテーブルの一部だけを見ることができるように、ウィンドウのサイズを変更できるようにしたい。スクロールを使うと、必要以上のものが見えてしまいます。結論 - ウィンドウのサイズを変更する必要がある。ウィンドウの視野を重要なエリアのサイズに合わせるのだ。
アドバンテージについては、冗談だよ。:D
オブジェクトとウィンドウのマッピングを作成する作業を、より明確に定式化してみよう。
テーブルを配置したウィンドウを作成したとします。その表が大きすぎたとします（取引履歴の統計指標の表とします）。あなたはウィンドウに垂直スクロールバーを設置しました（または自動的に表示されました）。しかし、これでは十分ではありません。あなたは、ユーザーが必要なテーブルの一部だけを見ることができるように、ウィンドウのサイズを変更できるようにしたい。スクロールを使うと、必要以上のものが見えてしまいます。結論 - ウィンドウのサイズを変更する必要がある。ウィンドウの視野を重要なエリアのサイズに合わせるのだ。
ここで、テーブルの他に、ウィンドウに様々な重要な静的オブジェクト（ヘルプアイコン、設定アイコン、ウィンドウズームボタンなど）が含まれているとしよう。ウィンドウのサイズを変更するとき、（ウィンドウの右ハンドルを動かしてウィンドウを小さくする場合）これらのオブジェクトは、もちろん正しい方向に移動しない限り、ウィンドウの外側になければなりません。しかし、ウィンドウの左ハンドルを動かすと、これらのオブジェクトは静止したままになる。あるオブジェクトをウィンドウの右ハンドルにバインドしておけば、ウィンドウと一緒に動くだけだと言える。
しかし、いくつかのオブジェクトは、一度に複数の他のオブジェクトにバインドすることができ、それらすべてに対して異なるバインドをすることができる。例えば、各オブジェクトの座標を別々に計算して規定するのに疲れたとする。あなたはただ、すでに設定されている他のオブジェクトに、上下左右にスナップさせたいだけなのです。あるオブジェクトと別のオブジェクトのバインディングを作成し、最初のオブジェクトが動けば、2番目のオブジェクトもその後に動く。
上記はすべてかなり単純な作業です。これには何の問題もないだろう。つまり、プロジェクト開発のどの段階でも、このような機能を追加することは可能だろう。
リタグ・コナウ
残念ながら、コード片を示すことは無意味です。それに対するコメントは、このコードのサイズを数倍超えてしまうからです。あなたは単に私のプログラミング方法に慣れていないだけで、私のコードはあなたに何も説明せず、むしろあなたを行き止まりに導くでしょう。私が言えるのは、私が書いていることはすべて実装されており、完璧に機能しているということだけだ。近日中にスクリーンショットやビデオを掲載する予定です。
では、なぜOOPがあなたのプログラミング能力を制限するのかを説明する例はないのですか？OOPを使ってこのようなプロジェクトを実装するのは不可能だが、あなたの方法を使えば可能だという図式を描くだけでいい。それで十分だ。
そして、あなたのスクリーンショットやビデオをどうすればいいのでしょうか？MQLの 機能を使えば、どんな複雑なグラフィカル・インターフェースも実装できます。グラフィカル・インターフェースの例としては、オペレーティング・システムのグラフィカル・インターフェースに焦点を当てるのがよいでしょう。つまり、十分な品質で作られ（Windowsでも エラーや欠陥は発生します）、ビデオで見るだけでなく自分でテストできるものです。
もしあなたのライブラリーを販売するつもりなら、せめて無料のDEMO-サンプルをマーケットに掲載して、私たちがテストして結論を出せるようにしてください。そして、私たちがMQLアプリケーションでGUIを作成 するために、あなたのライブラリをどのように使用するかを理解できるような記事も書いてください。スクリーンショットやビデオだけでは評価には不十分です。;)
私のスクリーンショットとビデオは、上記の問題を解決するという私の言葉を証明するものに過ぎない。私はそれらをあなたに提供するつもりでした。
真実は、私（あなたではない）の記事がライブラリの詳細な説明とともに掲載されていること、そしてそれが実際にMQLコミュニティ全体に無料で提供されていることです。あなたとは違って、これが実際の証拠 です。
しかし、あなたはいくつかの写真やビデオを見せたいだけなので、他の議論を捏造しながら、何の話も始めていない。あなたがコードを公表すれば、話は続く。その間に、私はこのシリーズの他の記事を書き続けるつもりなので、後でもっと詳しく比較することができるだろう。
少なくともあと15 記事はある。だから、比較を始めるには早すぎるのだ。
注：私はプログラムの小ささを利点と見ている。
面白くない。おそらくコードと同じくらい多くの機能がある。すべてのコメントを削除するか、あるいは難読化すれば、さらに小さくなるだろう。
真実は、現時点では、私（あなたのものではない）の記事にはライブラリの詳細な説明が掲載されており、それは実際にMQLコミュニティ全体に無償で提供されている。あなたとは違って、これが実際の証拠 です。
私は何も書きたくなかった...。でも
- アナトリー、「真実」と「証拠」については、そこはかとなく控えめではない。
- 台詞を思い出してほしい：「あなたの記事を読むのがどれだけ大変か......」という著者の返事を思い出してほしい。アナトリー、労をねぎらうのは結構だが、一つ質問がある。上級者には面白くないし、初心者には理解できない。あなたが書いたものを選んで体系化する気がまったくないコードがたくさんあります。
- アナトリー、読者はあなたの記事について質問しているが、どうやらあなたはそれに満足していないようだ。しかも、彼の意見はあなたにまったく興味がなく、いらいらさせるものでさえある。では、何のために記事を書くのか？
- 著者がより良く変わるためには、批判が必要なのだ。
あなたには失礼だが、読者との距離を縮め、その場で半ギレで興奮しないことだ。
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
新しい記事 グラフィカルインタフェース III： シンプルなボタンと多機能ボタン(チャプター 1) はパブリッシュされました:
ボタンについて考えましょう。ここでは、簡単なボタン、拡張機能を持ったボタン（アイコンボタンとスプリットボタン）、また相互接続されたボタン（ボタングループとラジオボタン）を作成するためのいくつかのクラスの例を説明していきます。 そのうえ、それらの能力を拡大するためのコントロールのために既存クラスにいくつかの追加を導入します。
作者: Anatoli Kazharski