記事"グラフィカルインターフェイスX：マルチラインテキストボックスでのテキスト選択(ビルド13)"についてのディスカッション
かっこいい！バッファからのペーストはどうなっていますか？
servicedkの開発者には、 まだそのような要望を連絡して いません。
おそらく、バッファから挿入するだけでなく、バッファに送信することも必要で、そのような必要が生じた場合、入力フィールド間でテキストを転送することができます。
おそらく、Ctrl + X (切り取り)、Ctrl + C (コピー)、Ctrl + V (貼り付け) を押したときに発生するシステムイベントを処理する機能が必要でしょう。
これは興味津々だろう:)
次の記事で、新しく描かれたエレメントを見せてくれるのでしょうか？それはとても気になります:)
1.すべての要素は最終的に描画要素になります。開発の第2段階として、1要素＝1オブジェクト（描画用キャンバス）になります。
2.はい、すでに描画されているすべての要素と同じように、このCCanvas クラスを使います。単純な図形を描くためのメソッドがすでに用意されている。もし存在しなければ、自分で実装しなければならない良いクラスだ。すでに描画されているライブラリの要素では、矩形や塗りつぶし付き矩形のような図形だけでなく、ピクセル単位の描画や線、テキスト出力のためのメソッドが使われている。
...
OOPのアプローチは、あなたが説明するよりもずっとシンプルだ。すでに説明したライブラリ・スキームの変更は最小限だ。最終的には、すべてが今よりもさらに便利でずっと良くなるだろう。
内部で生まれ変わることのないシステム開発のこのレシピは、私にはまったく未知のものだ。それはちょうど聖杯のようなもので、あると信じたいが、ありそうもない......。
もちろん、エレメントを描くのはそれほど難しいことではない。グラデーションを除けば）ほとんどのものは矩形から描画できるが、別のイベント・モデルを作らなければならない。OnChartEvent()関数は、描画された要素パターンへのクリック・イベントの固定をもはや提供しない。また、優先順位付けのためのZorderも役に立ちません。ずっと前に、オブジェクト・マップの作成についてお話しし、その利点を挙げましたが、その後、あなたはこの解決策を拒否しました。
描画された要素はより多くのプロパティを持ち、それらとの相互作用はより複雑であることは間違いない。この技術では、システムはより全体的で、メカニズムはより普遍的であるべきだ。例えば、すべてのインターフェイス要素に共通のメモリがあり、すべてのプロパティの値が格納されている必要がある。これは、異なる構造体やクラスの中に多くの別々の配列や変数を作るよりも効率的な解決策である。すべてのOOP規約（たとえば、あるオブジェクトのあるプロパティの値を取得する必要がある他のクラスの変数にアクセスするためにオブジェクトを参照する）は、作業を単純化するのではなく、遅くし、複雑にするだけである。OOPにはもうひとつ欠点がある。それは、あなたのように他人のクラスを使う利点がないことを、私は後悔していない。他人が作ったブロックを自分の開発で使う開発者は、自分ですべてを作った開発者よりも自分の開発のことをよく知らないし、さらに、自分の開発の改善の可能性が制限されるのは、自分の開発のことをよく知らないからだけでなく、他人のブロックを再設計することもないからだ。
以上、あくまでも私見であり、これで終わりにする。
このライブラリーのさらなる発展を、私は興味深く見守りたいと思う。
もちろん、要素を描画することはそれほど難しいことではない。ほとんどのものは矩形から描画できる（グラデーションを除く）が、別のイベント・モデルを作成しなければならない。OnChartEvent()関数は 、描画された要素の詳細に対するクリック・イベントの固定をもはや提供しない。 また、優先順位付けのためのZorderも役に立ちません。ずっと前に、私はオブジェクト・マップの作成についてお話しし、その利点を挙げましたが、その後、あなたはこの解決策を拒否しました。
あなたはいつものように間違っている。現在のモデルでも、あなたが言ったような問題はありません（下のGIFアニメーションを参照）。テーブルが描かれ、それとのインタラクションは、既存の要素の中で最も複雑とまでは言わないまでも、最も複雑なものの一つだ。また、これはまだ最終バージョンではありません。おそらくすでに次の記事で、このテーブルのための最終的なコードがあるでしょう。
//---
同じことをどのように実装したのか教えてください。
//---
...描かれた要素がより多くの特性を持ち、それらとの相互作用がより複雑であることは間違いない。この技術では、システムはより全体的で、メカニズムはより普遍的であるべきです。例えば、すべてのインターフェイス要素に共通のメモリがあり、すべてのプロパティの値が格納されている必要があります。これは、異なる構造体やクラスの中にたくさんの別々の配列や変数を作るよりも効率的だ。
描画された要素とのやりとりがずっと楽になる。徐々に、すべてが可能な限り普遍的になっていくだろう。もちろん、写真を見るだけでなく、注意深く読めば、このシリーズの記事から記事へと、このプロセスは顕著になるはずだ。共有メモリを作ることもできるし、私がやったように、あるクラスから各要素のプロパティに簡単にアクセスできるようにすることもできる。こうあるべきで、その逆はダメだと断言することはできない。誰も誰かに何かを負っているわけではない。あなたの開発では、あなたの都合のいいようにすればいい。私は、あれやこれやの勘定で自分の意見を持つことを好む。私の個人的な練習や人生経験からわかるように、他人の言うことの多くは間違っている。同時に、この数字から自分を排除することもしない。しかし、私は間違っていることを恐れないし、もし間違っていたら、間違いを正す方法を探すだけだ。
...すべてのOOPの慣例（例えば、あるオブジェクトのあるプロパティの値を取得する必要がある他のクラスの変数にアクセスするための参照オブジェクト）は、作業を単純化するのではなく、遅くし、複雑にするだけ です。
あなたの場合はそう だが、私の場合は違う。)
リタグ・コナウ
OOPにはもうひとつ欠点があります。それは、あなたのように他人のクラスを使う利点がないことです。他人が作ったブロックを自分の開発に使っている開発者は、自分ですべてを作った開発者よりも自分の開発についてよく分かっていない。さらに、自分の開発についてよく分かっていないだけでなく、他人のブロックを再設計することもないため、自分の開発を改善する可能性が制限される。
このような場合は、ゼロから自分で始めることだ。自分でOSを書き、MQL言語で取引端末を書き、グラフィカル・インターフェースを作成するための独自のライブラリを開発する。すべてやり終えたら、胸を張ってかかとをたたいてください。)))
//---
追伸： 私にとっての課題は
- プログラミングを練習すること。
- 満足のいく品質のグラフィカル・インターフェースを作成するためのライブラリを自分のために書くこと。
- この開発をMQLコミュニティと共有すること。
- 少なくとも開発の人件費を部分的に相殺すること。プロジェクトをサポートしてくれたMQに感謝する。
とてもうまくいったと思う。少なくとも、この結果を気に入っているのは私だけではないはずだ。:)
アナトリー、私は自分の意見を述べただけで、あなたとまた激しい論争をするつもりはない。
私のテーブルは未完成ですが、あなたが示した例も同じように機能します。テーブルはインタラクティブで、セルに絵があり、チェックボックスがあり、列の幅も変化する。もちろん、まだすべてが完璧に機能しているわけではないが......。外観も少し違います。列やカラムの追加はまだ実装されていない。ここで紹介するとまたPR禁止になるのでやめておきます。
私が話しているのは、私が苦労の過程で得た経験についてであり、それを分かち合うという事実は、敵対的なものとして受け止められるべきではない。結局のところ、あなたと一緒にここにいる他の誰が、これらすべての問題について対等な立場で議論することができるでしょうか？
幸運を祈る。
アナトリー、私は自分の意見を述べただけで、あなたとまた激しい論争をする気はない。
わかったよ。)
私のテーブルは未完成ですが、あなたが示した例も同じように機能します。テーブルはインタラクティブで、セルに絵があり、チェックボックスがあり、列の幅も変わる。もちろん、まだすべてが完璧に機能しているわけではありませんが......。外観も少し違います。列やカラムの追加はまだ実装されていない。ここでは紹介しません、でないとまたPR禁止になります。
このトピックに関する記事を読み、さらにソースコードに掲載されているソリューションを簡単に、そしてシンプルにあなたのスキームに適応させて使う絶好の機会がある。
その結果をブログで発表することもできる。私はあなたの出版物に従っています。;)
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
新しい記事 グラフィカルインターフェイスX：マルチラインテキストボックスでのテキスト選択(ビルド13) はパブリッシュされました:
本稿では、他のテキストエディタと同様に、さまざまなキーの組み合わせによってテキストを選択して選択したテキストを削除する機能を実装します。さらに、引き続きコードを最適化し、ライブラリの進化の第2段階の最終プロセスではすべてのコントロールが別々の画像（キャンバス）としてレンダリングされるため、これに向かってクラスを準備します。
このグラフィカルインタフェース作成ライブラリの概略は現在以下の通りに見えます。
作者: Anatoli Kazharski