OOPの専門家に質問です。 - ページ 52 1...4546474849505152535455 新しいコメント Реter Konow 2019.10.27 14:05 #511 私は、OOPとKernelのハイブリッドという新しいプリズムを通して、プログラムに記述されたオブジェクトシステムを眺め、脳みそが破裂しそうになった。まず、自分のGUIシステムを改めて見直してみました。これらのオブジェクト-パラメータ、オブジェクト-ステート、オブジェクト-イベントとハンドラのすべてを通じて。 GUIも技術も慣れ親しんでいるので、すべてがクリアに見えるのですが、システムが非常に複雑なんです。パラメータ、マッピング、ハンドラの塊。私は、このようなシステムは、それ自体では発生し得ないという結論に達しました。そして、自然淘汰はここでは何の力も持たない。 その理由はこうです。 各パラメータは、n 個の派生パラメータを持つことができる。例えば：Xを変化させると、そのXの値から任意のタイミングで無限に派生するパラメータを生成できる。 各派生パラメータは、ハンドラと他のパラメータへのリンクを持つ必要があります。単体で存在するパラメータはありません。リンクは必須です。 カップリングは様々であり、その結果、フィルター、修正器、変換器など様々なハンドラーが登場する。 システムにとって重要だと考えられる事象は、無限にある。それぞれ、プロパティ、リンク、ハンドラを持っています。そのバリエーションは数え切れないほどです。 このように、コンセプトがなければ、システムは生まれないのです。(最も可能性が高い)。 地球上の生命がどのように誕生したかは、あくまでも不明ですが...。 Реter Konow 2019.10.27 15:00 #512 もうひとつの例をご紹介しましょう。 グラフ上のコントロールを持つウィンドウを移動させるシステムを考える。 カーソル "オブジェクトからxとyの2つのパラメータを取る。そこから、xとyの現在と過去の値の差を格納する2つの派生パラメータオブジェクトを作成します。(パラメータ・オブジェクトは単なる変数ではなく、独自のプロパティを持つオブジェクトです）。 パラメータオブジェクトのハンドラオブジェクトを作成し、(1)ウィンドウハンドルイベントでx、yの値を処理し、現在と過去の値の差を取得し、ハンドラのプロパティに書き込み、(2)同じイベントで派生パラメータにその差を書き込むようにします。 派生パラメータオブジェクトと各ウィンドウオブジェクトのx,yパラメータオブジェクトの間にリンクオブジェクトを作成し、値の受け渡しに使用します。 このオブジェクトは、各ウィンドウオブジェクトのオブジェクトパラメータxとyから値を受け取り、バインダーに応じた値を追加する必要があります。 このように、このシステムでは、ウィンドウのハンドルがカーソルに掴まれたタイミングで、ウィンドウやそのオブジェクトの座標を変更することができます。これを全て動かすには、チャート上のMTオブジェクトの位置を変更するObjectSetInteger ハンドラ関数と関連付ける必要があります。 オブジェクトパラメータ、オブジェクトハンドラなど、特殊なシステムブロックを連携させ、1つのGUI機能だけを実装したものです。 このようなシステムをKernelで構築することは、すべてをObject化せずに普通のコードを書くより、少しも簡単ではない（いや、難しいかもしれない）。でも、どんどん掘っていきますよ...。 ウィンドウを移動させるためには、ウィンドウハンドルとカーソルの動きをロックするイベントオブジェクトを「細工」する必要があることを書き加えるのを忘れていました。そして、このイベントオブジェクトをカーソルx,y値のオブジェクトハンドラ（派生パラメータに差分を書き込む）に接続し、このイベントのシグナルでのみ動作するようにするのです。 そして、すべてのイベントオブジェクトに対して、オブジェクトハンドラを作成し、それにバインドする必要があります。 各オブジェクトハンドラは独自のプロパティを持ち、その値はパラメータやイベントを扱う際にそのハンドラによって使用される。ですから、テンプレートがないと、全部作るのは面倒です（笑)。 Artyom Trishkin 2019.10.27 15:54 #513 Реter Konow: もうひとつの例をご紹介しましょう。 グラフ上のコントロールを持つウィンドウを移動させるシステムを考える。 カーソル "オブジェクトからxとyの2つのパラメータを取る。そこから、xとyの現在と過去の値の差を格納する2つの派生パラメータオブジェクトを作成します。(パラメータ・オブジェクトは単なる変数ではなく、独自のプロパティを持つオブジェクトです）。 パラメータオブジェクトのハンドラオブジェクトを作成し、(1)ウィンドウハンドルイベントでx、yの値を処理し、現在と過去の値の差を取得し、ハンドラのプロパティに書き込み、(2)同じイベントで派生パラメータにその差を書き込むようにします。 派生パラメータオブジェクトと各ウィンドウオブジェクトのx,yパラメータオブジェクトの間にリンクオブジェクトを作成し、値の受け渡しに使用します。 このオブジェクトは、各ウィンドウオブジェクトのオブジェクトパラメータxとyから値を受け取り、バインダーに応じた値を追加する必要があります。 このように、このシステムでは、ウィンドウのハンドルがカーソルに掴まれたタイミングで、ウィンドウやそのオブジェクトの座標を変更することができます。これを全て動かすには、チャート上のMTオブジェクトの位置を変更するObjectSetIntegerハンドラ関数と関連付ける必要があります。 オブジェクトパラメータ、オブジェクトハンドラなど、特殊なシステムブロックを連携させ、1つのGUI機能だけを実装したものです。 このようなシステムをKernelで構築することは、すべてをObject化せずに普通のコードを書くより、少しも簡単ではない（いや、難しいかもしれない）。でも、どんどん掘っていきますよ...。 ウィンドウを移動させるためには、ウィンドウハンドルとカーソルの動きをロックするイベントオブジェクトを「細工」する必要があることを書き加えるのを忘れていました。そして、このイベントオブジェクトをカーソルx,y値のオブジェクトハンドラ（派生パラメータに差分を書き込む）に接続し、このイベントのシグナルでのみ動作するようにするのです。 そして、すべてのイベントオブジェクトに対して、オブジェクトハンドラを作成し、それにバインドする必要があります。 各オブジェクトハンドラは独自のプロパティを持ち、その値はパラメータやイベントを扱う際にそのハンドラによって使用される。 したがって、テンプレートがないと、これだけのものを作るのに手こずることになります)。 難しい。不当に難しい。 フォームのメインオブジェクトは、このフォームの他のオブジェクトが横たわる、座標を受け取る唯一のオブジェクトです。いずれかの座標を変更すると、フォームのメインオブジェクトの位置が変更されます。そのフォーム内の他のオブジェクトは、フォーム内の位置を決定する相対座標を渡されるだけです。すべてのオブジェクトは、フォームの中で独自の順序を持っており、その順序で再配置されます。各オブジェクトは、その中に含まれるもののリストを持っています。コンテンツのリストを参照することで、各コンテンツをオフセットして指令することができます。このように、フォームオブジェクトにシフトのコマンドを与えることで、フォームのすべての内容をシフトさせるコマンドを自動的に発行することができます。つまり、フォームだけがオフセットされ、それ以外は自動的にオフセットされるのです。各フォームオブジェクトに単独でオフセットコマンドを与える必要はない。 これを1つのオブジェクトに対してだけ行うのです。他のすべての人がそれを繰り返すでしょう。どんなに複雑なフォームオブジェクトであっても、1つのオフセットコマンドがそのフォームのすべてのコンテンツに雪崩を打って渡されることになります。 全ては一度きり。そして、すべてが連鎖的に行われることになる。 Реter Konow 2019.10.28 04:57 #514 Artyom Trishkin: 複雑である。不当に複雑。 フォームのメインオブジェクトは、そのフォームの他のオブジェクトが横たわり、座標を受け取る唯一のものです。いずれかの座標を変更すると、フォームのメインオブジェクトの位置が変更されます。フォーム内の他のオブジェクトは、フォーム内の位置を決定する相対座標を渡されるだけです。すべてのオブジェクトは、フォームの中で独自の順序を持っており、その順序で再配置されます。各オブジェクトは、その中に含まれるもののリストを持っています。コンテンツのリストを参照することで、各コンテンツをオフセットして指令することができます。このように、フォームオブジェクトにシフトのコマンドを与えることで、フォームのすべての内容をシフトするコマンドを自動的に発行することができるのです。つまり、フォームだけがオフセットされ、それ以外は自動的にオフセットされるのです。各フォームオブジェクトに単独でオフセットコマンドを与える必要はない。 これを1つのオブジェクトに対してだけ行うのです。他のすべての人がそれを繰り返すでしょう。どんなに複雑なフォームオブジェクトでも、オフセットコマンド1つでそのフォームの中身全体に雪崩を打って渡される。 全ては一度きり。そして、すべてが連鎖的に行われることになる。 そうなんです。 カーソルのx,yの差を含む派生パラメータとフォームオブジェクト（チェーン内にある）の間のバインディングは、各フォームオブジェクトのx,yパラメータへのシリアル接続を実行できるハンドラを中央に持ちます。つまり、逐次接続ハンドラを介してパラメータをバインドすることで、各フォームオブジェクトのバインドを、差分x,yの値を渡す派生パラメータで置き換えることができます。という思いもありました。 私のGUIでは、ウィンドウの移動は関数内で次のように実装しています。 (1) ウィンドウハンドルクリックイベント用イベントチェッカー (2) カーソル移動イベント (3) 現在のカーソル座標と過去のカーソル座標の差分を算出する。 (4) ウィンドウオブジェクトを循環させ、カーソル位置の差分を調整することで座標を変更する。 (5)ObjectSetInteger を呼び出し、ウィンドウフォーム（キャンバス）の МТ-object をチャートに沿って与えられた距離だけ移動させます。 従って、関数内の実装は正しい。オブジェクトハンドラ、オブジェクトパラメータ、オブジェクトバインディングによる実装は、このような背景から不格好に見えます。でも、掘り下げてみると...。 Artyom Trishkin 2019.10.28 06:40 #515 Реter Konow: これは正しい。 カーソルのx,yの差を含む派生パラメータとフォームオブジェクト（チェーンにある）の間のマッピングは、各フォームオブジェクトのx,yパラメータへのシリアル接続を実行できるハンドラを真ん中に持っています。つまり、逐次接続ハンドラを介してパラメータをバインドすることで、各フォームオブジェクトのバインドを、差分x,yの値を渡す派生パラメータで置き換えることができます。という思いもありました。 私のGUIでは、ウィンドウの移動は関数内で次のように実装しています。 (1) ウィンドウハンドルクリックイベント用イベントチェッカー (2) カーソル移動イベント (3) 現在のカーソル座標と過去のカーソル座標の差分を算出する。 (4) ウィンドウオブジェクトを循環させ、カーソル位置の差分を調整することで座標を変更する。 (5)ObjectSetInteger を呼び出し、ウィンドウフォーム（キャンバス）の МТ-object をチャートに沿って与えられた距離だけ移動させます。 従って、関数内の実装は正しい。オブジェクトハンドラ、オブジェクトパラメータ、オブジェクトバインディングによる実装は、このような背景から不格好に見えます。でも、掘り下げてみると...。 はい、これらのハンドラをオブジェクトとは別に作る必要がないためです。カーソル座標を返すクラスは静的にすることができます。プログラム中のどのクラスでも利用可能で、座標の取得とそれに対する応答はすべてのオブジェクトで実装されるべきです。しかし、これらのハンドラを呼び出すのは、メインフォームオブジェクトだけである。そして、他のすべてのフォームオブジェクトについては、新しい座標を指定して再描画すれば十分です。フォームオブジェクトの内部には、そのすべてのオブジェクトのリストが存在します。フォームオブジェクトは、その座標の変更を定義しています。その座標に新しい値を設定し、オブジェクトのリストを調べて、そのリスト内の各オブジェクトの座標を設定するメソッドを呼び出します。同時に、後続のオブジェクトも座標が変わると同じことをします。オブジェクトのリストを調べて、座標を変更するように命令するのです。リスト内のオブジェクトは、描画された順に並べられます（Z-sequence）。つまり、各オブジェクトは独自の座標変更方法を持っていますが、その実装方法は同じで、すべての「フレンドリー」オブジェクトのリストを調べ、それぞれのオブジェクトに対して同じメソッドを呼び出すのです。したがって、このメソッドをメインフォームオブジェクトに対して一度だけ呼び出すことで、フォーム内のすべてのオブジェクトの座標変更を自動的に開始させることができます。 フォームオブジェクトの「フレンドリー」オブジェクトのリストが処理されると、そのチャート再描画メソッドを呼び出しますが、これはすべての変更オブジェクトに対して同じです。 Реter Konow 2019.10.28 12:16 #516 Artyom Trishkin: ... これは、ウィンドウの移動機構に関する標準的なOOPの見解である。違うものをお見せします。そのためには、ちょっと心を澄ませて、ただ私の思いに従ってください。 配列行列を想像してください。寸法は不定です。もしかしたら、無限かもしれないし、そうでないかもしれない。そんなことはどうでもいいんです。 行列はゼロで初期化される。ゼロは空虚を表す。つまり、行列は空である。 マトリックスの虚無の中に、虚無ではない何かが現れている。ゼロを値で置き換えたものです。何でもいいんです。 空の行列にこの値を見て、「これはパラメータだ」と言うのです。つまり、値そのものではなく、その値が出現したセルを指す。 セルにはタイトルが付けられ、パラメータと呼ばれる、つまり、値を含む「容量」が表示されます。 このパラメータは、すぐにその定義を私たちに要求してきます。まるで「私はパラメータで、人格があるんだ！」と言っているようです。私の物件はどこだ！」と。そして、パラメータにそのプロパティを追加するしかない。プロパティもまた、それ自身の値を持つパラメータである。それを横に並べると、パラメータとそのプロパティという連鎖ができる。Object-parameterを作りました！」と言うのです。 次に、「他のパラメータはどこだ！」とパラメータが言う。なぜ私だけが..."そして、「先住者」が退屈しないように、マトリックスの空白にもう少しパラメータを作るのです。もちろん、新しいパラメータはそれぞれ個性を主張し、その担い手として特性を要求する。こうしてパラメータの連鎖が生まれ、その中に「先住者」とそのプロパティが存在する。私たちは「パラメータオブジェクトを作りました！」と言います。 今、行列の空虚の中に、いくつかのパラメータとその特性の連鎖がある。しかし、それぞれが自分の存在の無意味さを「叫ぶ」のである。それぞれが孤独である。そして、「飽きない」ようにパラメータを連動させることにしました。そのために、他のパラメータとのバインディングとなる特別なパラメータを作成します。また、プロパティのチェーンで構成されています。さて、先住パラメータは、パラメータチェインによって互いにリンクされています。みんなハッピーですParameter Bindings Objectsを作りました！」と言うのです。 しかし、その後、パラメータ・プライマリは、バインディングを通じて互いに通信し、値を転送したいことが判明した。バインディングは、値（パラメータ言語）の転送は行うが、翻訳を行う機能は備えていない。そして、孤独であるがゆえに、パラメータは自分たちの言語しか理解できない。つまり、パラメータ間には「言葉の壁」があり、それを解決することが求められているのである。 パラメータ通信」の問題を解決するためには、マッピングが足りず、翻訳が必要だったのです。つまり、パラメータ間で渡される値は、各パラメータの特性を考慮した上で変換する必要があるのです。1～10の範囲の値を理解している人もいれば、（-5）～（-105）の値を理解している人もいます。あるものは分数で、あるものは累乗で操作する。したがって、「トランスレータ」、すなわちパラメータの特性を考慮した値ハンドラが必要であると結論づけられる。専用のHandlerオブジェクトを作成し、パラメータマッピングに挿入します。バリューハンドラーオブジェクトは、受け渡しするパラメータのプロパティと、自身のプロパティを使用して、パラメータ間で渡された値を「変換」します。私たちは、「Handlerオブジェクトを作りました！」と言います。 これでパラメーターが自由にコミュニケーションできるようになった！」。 長男のパラメータは、通信して通信して、飽きられたんです。疲れている。そして、2人は特別な時だけ、つまりどちらかが信じられないような価値を得た時だけ、コミュニケーションをとることにした。しかし、結果的には、子供のように執拗に値を見続ける必要がありました。長男のパラメーターは、自分たちが心配しないように、異常な変動を知らせる「モニタリングシステム」を考えてほしいというものでした。そこで、反応すべき値の型を作り、それに専用のハンドラを追加した結果、「イベントオブジェクト」が出来上がりました。これを各パラメーターに接続し、イベントオブジェクトからの信号で相互に通信を開始しました。そこで、"Object-events "を作成しました。 これで物語は終わりです...。 外からマトリックスを見て、思わず息をのみましたよ。"オブジェクトシステムを作りました！") ZS.すべてはアレイ・マトリクスで作成できることに注目してください。そして、そのアレイマトリクスがCoreです。そして、その中にある実体、つまり実体のあるもの。そして、パラメータ、イベント、バインディング、プロパティ、ハンドラ。これらのベースとなるものから、カーネルで構築できるシステムは数え切れないほどある。 Реter Konow 2019.10.28 12:59 #517 モックの続き... 11.長男のパラメーターは、なぜかファッションを追うことにした。彼らは、行列のどこかにプロパティのフェアがあり、ノベルティの中にある空間があることを突き止めたのです。 3つの性質があるそうです。"Dimensions "と呼ばれています。これらのプロパティは無限の値を持つとされており、おまけにもう一つの「パラメータ時間」を与えてくれる。パラメータは見本市に来て、x,y,x_size,y_sizeのプロパティを取った。宇宙で砲弾を作りたいと言っています。そして、カラーも撮った。彼らは戻ってくると、新しい物件のドレスアップに取り掛かった。彼らは、飽きるまで空間的なエンベロープをモデリングし続けた。そして、自分たちに色をつけて、リラックスさせるのです。次はどうしようかと考え始めた。 そして、タイムプロパティボックスを見たのである。どんなものか見てみよう・・・。それを開いて、自分たちにくっつけて、でも価値観は計算しないで、一瞬で空っぽに蒸発させてしまったのです。やはり、時間というパラメータは慎重にならざるを得ない...。 Koldun Zloy 2019.10.29 03:47 #518 Реter Konow: モックの続き... 11.長男のパラメーターは、なぜかファッションを追うことにした。彼らは、行列のどこかにプロパティのフェアがあり、ノベルティの中にある空間があることを突き止めたのです。3つの性質があるそうです。"Dimensions "と呼ばれています。これらのプロパティは無限の値を持つとされており、おまけにもう一つの「パラメータ時間」を与えてくれる。パラメータは見本市に来て、x,y,x_size,y_sizeのプロパティを取った。宇宙で砲弾を作りたいと言っています。そして、カラーも撮った。彼らは戻ってくると、新しい物件のドレスアップに取り掛かった。彼らは、飽きるまで空間的なエンベロープをモデリングし続けた。そして、自分たちに色をつけて、リラックスさせるのです。 次はどうしようかと考え始めた。そして、タイムプロパティボックスを見たのである。どんなものか見てみよう・・・。それを開いて、自分たちにくっつけて、でも価値観は計算しないで、一瞬で空っぽに蒸発させてしまったのです。やはり、時間というパラメータは、かなり気をつけないと...。 最初の10人は本気じゃなかった？ 私、笑わずに読めません。 Реter Konow 2019.10.29 15:10 #519 Artyom Trishkin: ... この "客観性 "は非常に分かりにくいですね......そうでしょ？気をつけなければならないのは、その点です。天才と精神分裂病の近さについては、ニコライ・セムコの言うとおりだった。発狂」することもあり得るのです。理解しないほうがいいこともある。私たちの意識に対して、常に閉ざされていなければならない扉があります。ある映画で、「最も危険な寄生虫はアイデアである」という言葉がありました。一度脳に入り込んだら、取り出すことは不可能です。" 私が言っていたマトリックスは、マインドにとって危険なものです。それに没頭して、いつまでも迷ってしまいがちです。気をつけよう))) Реter Konow 2019.10.29 15:39 #520 マトリックスでシステムを表現することで、その構造について新しい視点が得られますが、システムを作りやすくするヒントは見出せませんでした。自己啓発」はもちろんのこと。そうやってシステムを見るのはめちゃくちゃ面白いけど、それ以上ではないんです。自己啓発はおろか、その気配すら感じられない。ですから、神業は神様に任せましょう。標準的なOOPのアプローチでも、私のアプローチでも、システムの自己開発はできないのです。 1...4546474849505152535455 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
私は、OOPとKernelのハイブリッドという新しいプリズムを通して、プログラムに記述されたオブジェクトシステムを眺め、脳みそが破裂しそうになった。まず、自分のGUIシステムを改めて見直してみました。これらのオブジェクト-パラメータ、オブジェクト-ステート、オブジェクト-イベントとハンドラのすべてを通じて。 GUIも技術も慣れ親しんでいるので、すべてがクリアに見えるのですが、システムが非常に複雑なんです。パラメータ、マッピング、ハンドラの塊。私は、このようなシステムは、それ自体では発生し得ないという結論に達しました。そして、自然淘汰はここでは何の力も持たない。
その理由はこうです。
各パラメータは、n 個の派生パラメータを持つことができる。例えば：Xを変化させると、そのXの値から任意のタイミングで無限に派生するパラメータを生成できる。
各派生パラメータは、ハンドラと他のパラメータへのリンクを持つ必要があります。単体で存在するパラメータはありません。リンクは必須です。
カップリングは様々であり、その結果、フィルター、修正器、変換器など様々なハンドラーが登場する。
システムにとって重要だと考えられる事象は、無限にある。それぞれ、プロパティ、リンク、ハンドラを持っています。そのバリエーションは数え切れないほどです。
このように、コンセプトがなければ、システムは生まれないのです。(最も可能性が高い)。
地球上の生命がどのように誕生したかは、あくまでも不明ですが...。
もうひとつの例をご紹介しましょう。
グラフ上のコントロールを持つウィンドウを移動させるシステムを考える。
このように、このシステムでは、ウィンドウのハンドルがカーソルに掴まれたタイミングで、ウィンドウやそのオブジェクトの座標を変更することができます。これを全て動かすには、チャート上のMTオブジェクトの位置を変更するObjectSetInteger ハンドラ関数と関連付ける必要があります。
オブジェクトパラメータ、オブジェクトハンドラなど、特殊なシステムブロックを連携させ、1つのGUI機能だけを実装したものです。
このようなシステムをKernelで構築することは、すべてをObject化せずに普通のコードを書くより、少しも簡単ではない（いや、難しいかもしれない）。でも、どんどん掘っていきますよ...。
ウィンドウを移動させるためには、ウィンドウハンドルとカーソルの動きをロックするイベントオブジェクトを「細工」する必要があることを書き加えるのを忘れていました。そして、このイベントオブジェクトをカーソルx,y値のオブジェクトハンドラ（派生パラメータに差分を書き込む）に接続し、このイベントのシグナルでのみ動作するようにするのです。
そして、すべてのイベントオブジェクトに対して、オブジェクトハンドラを作成し、それにバインドする必要があります。
各オブジェクトハンドラは独自のプロパティを持ち、その値はパラメータやイベントを扱う際にそのハンドラによって使用される。ですから、テンプレートがないと、全部作るのは面倒です（笑)。
もうひとつの例をご紹介しましょう。
グラフ上のコントロールを持つウィンドウを移動させるシステムを考える。
このように、このシステムでは、ウィンドウのハンドルがカーソルに掴まれたタイミングで、ウィンドウやそのオブジェクトの座標を変更することができます。これを全て動かすには、チャート上のMTオブジェクトの位置を変更するObjectSetIntegerハンドラ関数と関連付ける必要があります。
オブジェクトパラメータ、オブジェクトハンドラなど、特殊なシステムブロックを連携させ、1つのGUI機能だけを実装したものです。
このようなシステムをKernelで構築することは、すべてをObject化せずに普通のコードを書くより、少しも簡単ではない（いや、難しいかもしれない）。でも、どんどん掘っていきますよ...。
ウィンドウを移動させるためには、ウィンドウハンドルとカーソルの動きをロックするイベントオブジェクトを「細工」する必要があることを書き加えるのを忘れていました。そして、このイベントオブジェクトをカーソルx,y値のオブジェクトハンドラ（派生パラメータに差分を書き込む）に接続し、このイベントのシグナルでのみ動作するようにするのです。
そして、すべてのイベントオブジェクトに対して、オブジェクトハンドラを作成し、それにバインドする必要があります。
各オブジェクトハンドラは独自のプロパティを持ち、その値はパラメータやイベントを扱う際にそのハンドラによって使用される。 したがって、テンプレートがないと、これだけのものを作るのに手こずることになります)。
複雑である。不当に複雑。
そうなんです。
カーソルのx,yの差を含む派生パラメータとフォームオブジェクト（チェーン内にある）の間のバインディングは、各フォームオブジェクトのx,yパラメータへのシリアル接続を実行できるハンドラを中央に持ちます。つまり、逐次接続ハンドラを介してパラメータをバインドすることで、各フォームオブジェクトのバインドを、差分x,yの値を渡す派生パラメータで置き換えることができます。という思いもありました。
私のGUIでは、ウィンドウの移動は関数内で次のように実装しています。
(1) ウィンドウハンドルクリックイベント用イベントチェッカー
(2) カーソル移動イベント
(3) 現在のカーソル座標と過去のカーソル座標の差分を算出する。
(4) ウィンドウオブジェクトを循環させ、カーソル位置の差分を調整することで座標を変更する。
(5)ObjectSetInteger を呼び出し、ウィンドウフォーム（キャンバス）の МТ-object をチャートに沿って与えられた距離だけ移動させます。
従って、関数内の実装は正しい。オブジェクトハンドラ、オブジェクトパラメータ、オブジェクトバインディングによる実装は、このような背景から不格好に見えます。でも、掘り下げてみると...。
これは正しい。
カーソルのx,yの差を含む派生パラメータとフォームオブジェクト（チェーンにある）の間のマッピングは、各フォームオブジェクトのx,yパラメータへのシリアル接続を実行できるハンドラを真ん中に持っています。つまり、逐次接続ハンドラを介してパラメータをバインドすることで、各フォームオブジェクトのバインドを、差分x,yの値を渡す派生パラメータで置き換えることができます。という思いもありました。
私のGUIでは、ウィンドウの移動は関数内で次のように実装しています。
(1) ウィンドウハンドルクリックイベント用イベントチェッカー
(2) カーソル移動イベント
(3) 現在のカーソル座標と過去のカーソル座標の差分を算出する。
(4) ウィンドウオブジェクトを循環させ、カーソル位置の差分を調整することで座標を変更する。
(5)ObjectSetInteger を呼び出し、ウィンドウフォーム（キャンバス）の МТ-object をチャートに沿って与えられた距離だけ移動させます。
従って、関数内の実装は正しい。オブジェクトハンドラ、オブジェクトパラメータ、オブジェクトバインディングによる実装は、このような背景から不格好に見えます。でも、掘り下げてみると...。
はい、これらのハンドラをオブジェクトとは別に作る必要がないためです。カーソル座標を返すクラスは静的にすることができます。プログラム中のどのクラスでも利用可能で、座標の取得とそれに対する応答はすべてのオブジェクトで実装されるべきです。しかし、これらのハンドラを呼び出すのは、メインフォームオブジェクトだけである。そして、他のすべてのフォームオブジェクトについては、新しい座標を指定して再描画すれば十分です。フォームオブジェクトの内部には、そのすべてのオブジェクトのリストが存在します。フォームオブジェクトは、その座標の変更を定義しています。その座標に新しい値を設定し、オブジェクトのリストを調べて、そのリスト内の各オブジェクトの座標を設定するメソッドを呼び出します。同時に、後続のオブジェクトも座標が変わると同じことをします。オブジェクトのリストを調べて、座標を変更するように命令するのです。リスト内のオブジェクトは、描画された順に並べられます（Z-sequence）。つまり、各オブジェクトは独自の座標変更方法を持っていますが、その実装方法は同じで、すべての「フレンドリー」オブジェクトのリストを調べ、それぞれのオブジェクトに対して同じメソッドを呼び出すのです。したがって、このメソッドをメインフォームオブジェクトに対して一度だけ呼び出すことで、フォーム内のすべてのオブジェクトの座標変更を自動的に開始させることができます。 フォームオブジェクトの「フレンドリー」オブジェクトのリストが処理されると、そのチャート再描画メソッドを呼び出しますが、これはすべての変更オブジェクトに対して同じです。
...
これは、ウィンドウの移動機構に関する標準的なOOPの見解である。違うものをお見せします。そのためには、ちょっと心を澄ませて、ただ私の思いに従ってください。
これで物語は終わりです...。
外からマトリックスを見て、思わず息をのみましたよ。"オブジェクトシステムを作りました！")
ZS.すべてはアレイ・マトリクスで作成できることに注目してください。そして、そのアレイマトリクスがCoreです。そして、その中にある実体、つまり実体のあるもの。そして、パラメータ、イベント、バインディング、プロパティ、ハンドラ。これらのベースとなるものから、カーネルで構築できるシステムは数え切れないほどある。
モックの続き...
11.長男のパラメーターは、なぜかファッションを追うことにした。彼らは、行列のどこかにプロパティのフェアがあり、ノベルティの中にある空間があることを突き止めたのです。 3つの性質があるそうです。"Dimensions "と呼ばれています。これらのプロパティは無限の値を持つとされており、おまけにもう一つの「パラメータ時間」を与えてくれる。パラメータは見本市に来て、x,y,x_size,y_sizeのプロパティを取った。宇宙で砲弾を作りたいと言っています。そして、カラーも撮った。彼らは戻ってくると、新しい物件のドレスアップに取り掛かった。彼らは、飽きるまで空間的なエンベロープをモデリングし続けた。そして、自分たちに色をつけて、リラックスさせるのです。次はどうしようかと考え始めた。 そして、タイムプロパティボックスを見たのである。どんなものか見てみよう・・・。それを開いて、自分たちにくっつけて、でも価値観は計算しないで、一瞬で空っぽに蒸発させてしまったのです。やはり、時間というパラメータは慎重にならざるを得ない...。
モックの続き...
11.長男のパラメーターは、なぜかファッションを追うことにした。彼らは、行列のどこかにプロパティのフェアがあり、ノベルティの中にある空間があることを突き止めたのです。3つの性質があるそうです。"Dimensions "と呼ばれています。これらのプロパティは無限の値を持つとされており、おまけにもう一つの「パラメータ時間」を与えてくれる。パラメータは見本市に来て、x,y,x_size,y_sizeのプロパティを取った。宇宙で砲弾を作りたいと言っています。そして、カラーも撮った。彼らは戻ってくると、新しい物件のドレスアップに取り掛かった。彼らは、飽きるまで空間的なエンベロープをモデリングし続けた。そして、自分たちに色をつけて、リラックスさせるのです。 次はどうしようかと考え始めた。そして、タイムプロパティボックスを見たのである。どんなものか見てみよう・・・。それを開いて、自分たちにくっつけて、でも価値観は計算しないで、一瞬で空っぽに蒸発させてしまったのです。やはり、時間というパラメータは、かなり気をつけないと...。
最初の10人は本気じゃなかった？
私、笑わずに読めません。
...
この "客観性 "は非常に分かりにくいですね......そうでしょ？気をつけなければならないのは、その点です。天才と精神分裂病の近さについては、ニコライ・セムコの言うとおりだった。発狂」することもあり得るのです。理解しないほうがいいこともある。私たちの意識に対して、常に閉ざされていなければならない扉があります。ある映画で、「最も危険な寄生虫はアイデアである」という言葉がありました。一度脳に入り込んだら、取り出すことは不可能です。" 私が言っていたマトリックスは、マインドにとって危険なものです。それに没頭して、いつまでも迷ってしまいがちです。気をつけよう)))