グラフィックライブラリーをゼロから作成する - ページ 2 123456789...15 新しいコメント Alexandr Andreev 2020.03.07 21:40 #11 Алексей Барбашин: 一からやるのは勿体無いと思っています。 非常に賢い人たちが、多くの時間と知識を費やして、同じ標準ライブラリや アナトーリ・ライブラリを作って いるのです。 人々は時間と知識を投資してきたのですから、それを使わないのは愚かなことです。 両方の良いところをとって、新しいものを作ればいいんです。 他人の失敗から学ばなければならない。自分たちで作る) FORだけ! Nikolai Semko 2020.03.08 04:06 #12 図書館の最終的な目標は明確ではありません。他のライブラリのどのような欠点を解決、または拡張する必要があるのか？それとも、根本的に新しいツールになるべきでしょうか？GUI指向のものであるべきか、ユーザー指向のものであるべきか。例えば、私のiCanvasライブラリは、ユーザーグラフィックの使い勝手の向上、コーディング時のコードの短縮と直感的な操作、非同期関数の回避によるスピードアップ、XUスクリーン座標だけでなく価格時間座標 系へのリンクなど、CCanvasライブラリを論理的に継承するものでした。 Georgiy Merts 2020.03.08 04:58 #13 Nikolai Semko: 図書館の最終的な目標は明確ではありません。 そしてこれは、私が見る限り、すべてのグラフィックス・ライブラリに 共通する問題です。 フォーラムで提供されるすべてのプロジェクトは、ユーザーの収入を増やすか、同じ収入を得るための効率を上げるか、2つの問題のいずれかを解決する必要があります。 このような問題を解決するための例をわざわざ示すプロジェクトオーナーは、一人もいなかったと記憶しています。 最も印象的な例は、「Canvasはかっこいい」スレッドで思い出したのですが、単純に魅惑的で美しいグラフィックの提示です...。しかし、それがどのようにユーザー（少なくとも作者）の収入を増やすのか、あるいはそれを得る効果を高めるのか、私には理解できなかった。 アナトリーの図書館も同様です。素晴らしい構成で、よく考えられているが作者本人ですら、このライブラリの機能をすべて使っているわけではないはずです。ユーザーに関しては、もう忘れてもいいと思うんです。 また、ピーター・コノフ氏のプロジェクトもその一例です。OOPを理解できない（したくない）人にとっては、良い機能を持った、かなり実用的なソリューションですが繰り返しになりますが、収益を生み出す効率の向上を示す例は一つもありません。 私が思うに、これらのプロジェクトの多くは、むしろ作者の驕りを助長するために必要なものなのです。一般的には、必要なものである。しかし、「最終目標」を期待してはいけない。私のTSリーグ（あらゆる種類の単純な専門家の集まりに過ぎない）にモニター、利益、グレイル...を期待しているようなものです。とはいえ、さまざまなシンボルにさまざまなTSの原理が働いていることを示す指標に過ぎないのですが。 Alexandr Andreev 2020.03.08 06:00 #14 Georgiy Merts: そしてこれは、私が見る限り、すべてのグラフィックス・ライブラリに共通する問題です。 フォーラムで提供されるすべてのプロジェクトは、ユーザーの収入を増やすか、同じ収入を得るための効率を上げるか、2つの問題のいずれかを解決する必要があります。 少なくともあるプロジェクトの著者は、これらの課題の解決方法を示す例をわざわざ示した覚えはない。 実は、ここはプログラマーズ・フォーラムの一角なのです・・・・。ここに金銭感覚を求めるのはやめたほうがいい)))私自身は、このような問題はこのフォーラムとは別に解決したいと考えています。 ニコライ・セムコ 図書館の最終的な目標は明確ではありません。 他のライブラリのどのような欠点を解決し、または可能性を拡大する必要がありますか？それとも、根本的に新しいツールになるべきでしょうか？GUI指向のものであるべきか、ユーザー指向のものであるべきか。 例えば、私のiCanvasライブラリは、カスタムグラフィックの使い勝手を良くするため、コーディング時のコードを短く直感的にするため、非同期関数を避けて速度を上げるため、XUスクリーン座標だけでなく価格時間座標 系にリンクするため、Ccanvasライブラリを論理的に継承したものです。 私はあなたに感謝し、あなたのライブラリから始まり、私はそれを少し洗練し、さらにいくつかの)))) 最終的には、行の関数を書き換え、またKanvasソースからの広い行関数、偽関数を削除し、イベントにスタブを置くなどすべてを変更しました。他の要素にバイナリサーチによる左右のバーの計算を追加し、さらにバイナリサーチ自体に大小を選択できる機能を追加しています。また、あらゆる種類の配列（時系列/共通）からビルドする機能を追加し、コンストラクトを変更する必要があるという結論に達しました)))) Alexandr Andreev 2020.03.08 06:30 #15 一周回ってきた。 ヒエラルキーが理解できる もう一度制御を作り直さなければならないのですが、まだ別に入れたい座標があるのです。円形に並べたい。コトロールは座標から行くので、より真に迫り、システムも大幅に簡素化されると思うのですが。もちろん、私の主張は間違っているかもしれませんが......今のところ、素朴な解決策に思えます。 そしてコトロール......これはスタイルの基本要素に他ならず、理論的には座標の後にあるべきものなのです。 ロジック - スタイルなしで要素を持つことはできますが、座標なしで持つことはできません。 Georgiy Merts 2020.03.08 06:47 #16 Alexandr Andreev: 実はこれ、プログラマーズ・フォーラムの一コーナーなんです・・・・・。ここに金銭感覚を求めるのはやめたほうがいい)))私自身は、このような問題はこのフォーラムとは別に対処したい。 とても面白い。 隣で「タダ働きする人はいない」と熱いバトルが繰り広げられているスレッドがあるのですが、「金銭感覚を探しても無駄」とおっしゃいますね ? Alexandr Andreev 2020.03.08 07:09 #17 Georgiy Merts: とても面白い。 タダ働きする人はいない」という熱いバトルが繰り広げられている話題の横で、「金銭感覚を探すな」と言うのですか。 もらった図書館の著作権も主張しないし...。その財務的な要素は言うに及ばず。 ただ、どうすればいいのか、正しく知りたかっただけなんです。 ちょっとしたニーズがあれば、スクラップでコードを集めることだってできる。 理想は、この正しいもののミニバージョンを作りたいのですが。最小限のコードと最大限の有用性のために。 Алексей Барбашин 2020.03.08 07:46 #18 Nikolai Semko: 図書館の最終的な目標は明確では ありません。 他の図書館のどのような欠点を解決し、あるいは拡大する必要があるのか？それとも、根本的に新しいツールになるべきでしょうか？GUI指向のものであるべきか、ユーザー指向のものであるべきか。 例えば、私の iCanvas ライブラリは、カスタム グラフィックスの使い勝手を良くするため、コーディング時のコードをより短く直感的にするため、非同期関数を避けて速度を上げるため、そして単なる XU スクリーン座標ではなく価格時間座標 系にリンクするために CCanvas ライブラリを論理的に継続したものです。 ニコライさん、ようこそ。 最終的な目標は、現時点ですでにあるツールの欠点を解決しようとすることです。 プロジェクトとの接続のしやすさを向上させるための標準ライブラリの開発継続と、チャートオブジェクトを残してキャンバスに移行するグラフィックコンポーネントの改良が主な内容になると思います。 しかし、全体として、結果がどうなるかは憶測で決めないようにしましょう。 Maxim Kuznetsov 2020.03.08 10:12 #19 Алексей Барбашин: ニコライさん、ようこそ。 最終的な目標は、現時点ですでにあるツールの欠点を解決しようとすることです。 おそらく、プロジェクトとの接続のしやすさを向上させるための標準ライブラリの開発と、チャートオブジェクトとキャンバスへの移行を残したグラフィックコンポーネントの改良を継続することになるのでしょう。 しかし、一般的に、何が起こるかわからないと困惑するのはやめましょう。 エンジニアリングについて簡単に説明すると: もし、ある「A」をリエンジニアリングで改善したいという気持ちがあるのなら、その重大な欠点を特定する必要があります。それらを列挙し、「A」の進化の過程でそれらを排除することが不可能である理由を説明するだけでよい。 一方で、誰もそれを禁じてはいない。コードを書くのが好きな人は、書いてみてください...。A "を自分流に書き換えても、新しいものになる Алексей Барбашин 2020.03.08 10:24 #20 Alexandr Andreev: 一周回ってきた。 ヒエラルキーが理解できる もう一度制御を作り直さなければならないのですが、まだ別に入れたい座標があるのです。円形に並べたい。コトロールは座標から行くので、より真に迫り、システムも大幅に簡素化されると思うのですが。 もちろん、私の主張は間違っているかもしれませんが......今のところ、素朴な解決策に思えます。 そしてコトロール......これはスタイルの基本要素に他ならず、理論的には座標の後にあるべきものなのです。 論理 - スタイルのない要素を持つことはできますが、座標のない要素を持つことはできません。 反論するまでもなく、事実です ))) スタイルやテーマなど、最初に想定しておけば、後からねじ込むことも可能です。実際には、これらすべてが基本コントロールで発生するはずなので、機能性の向上もこのクラスで行くことになります。 座標については、チャートからの相対座標を計算する絶対座標と、親からの相対座標を計算するローカル座標の2種類がありますね。 例えば、フォームをレンダリングする場合、チャートへの配置は絶対座標で処理される。 ボタンをフォームに配置する場合、それが配置されているコンテナに対して、つまりフォームに対して相対的に配置する必要がある。 マウス移動イベントを受信すると、ハンドラでチャートに対するカーソル位置の絶対座標を取得します。カーソルがフォームや要素に当たっているかどうかを確認する場合、カーソルの絶対座標と要素の現在位置を、その位置関係を考慮しながら比較する必要があります。つまり、フォームの場合は単純に現在の座標とサイズとの比較になりますが、ボタンの場合は座標系におけるボタンの絶対位置を計算することになります。つまり、比較のためのX座標は以下のように計算されます。X = (Parent==null)?X():(X()+Parent.X()), X() は項目の X 位置を返すクラス関数です。ただし、親の存在自体のチェックは、この関数自体の中で行うことができる。その結果、ある要素が親を持つ場合、その座標は親の座標に親自身の座標 を足したものが返される。実際には，入れ子の数は任意であり，各要素はグラフに対してではなく，その上にある要素に対して相対的に位置決めされるので，絶対座標は再帰的に計算することができる。 123456789...15 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
一からやるのは勿体無いと思っています。
非常に賢い人たちが、多くの時間と知識を費やして、同じ標準ライブラリや アナトーリ・ライブラリを作って いるのです。
人々は時間と知識を投資してきたのですから、それを使わないのは愚かなことです。
両方の良いところをとって、新しいものを作ればいいんです。
他人の失敗から学ばなければならない。自分たちで作る)
FORだけ!
図書館の最終的な目標は明確ではありません。
そしてこれは、私が見る限り、すべてのグラフィックス・ライブラリに 共通する問題です。
フォーラムで提供されるすべてのプロジェクトは、ユーザーの収入を増やすか、同じ収入を得るための効率を上げるか、2つの問題のいずれかを解決する必要があります。
このような問題を解決するための例をわざわざ示すプロジェクトオーナーは、一人もいなかったと記憶しています。
最も印象的な例は、「Canvasはかっこいい」スレッドで思い出したのですが、単純に魅惑的で美しいグラフィックの提示です...。しかし、それがどのようにユーザー（少なくとも作者）の収入を増やすのか、あるいはそれを得る効果を高めるのか、私には理解できなかった。
アナトリーの図書館も同様です。素晴らしい構成で、よく考えられているが作者本人ですら、このライブラリの機能をすべて使っているわけではないはずです。ユーザーに関しては、もう忘れてもいいと思うんです。
また、ピーター・コノフ氏のプロジェクトもその一例です。OOPを理解できない（したくない）人にとっては、良い機能を持った、かなり実用的なソリューションですが繰り返しになりますが、収益を生み出す効率の向上を示す例は一つもありません。
私が思うに、これらのプロジェクトの多くは、むしろ作者の驕りを助長するために必要なものなのです。一般的には、必要なものである。しかし、「最終目標」を期待してはいけない。私のTSリーグ（あらゆる種類の単純な専門家の集まりに過ぎない）にモニター、利益、グレイル...を期待しているようなものです。とはいえ、さまざまなシンボルにさまざまなTSの原理が働いていることを示す指標に過ぎないのですが。
そしてこれは、私が見る限り、すべてのグラフィックス・ライブラリに共通する問題です。
フォーラムで提供されるすべてのプロジェクトは、ユーザーの収入を増やすか、同じ収入を得るための効率を上げるか、2つの問題のいずれかを解決する必要があります。
少なくともあるプロジェクトの著者は、これらの課題の解決方法を示す例をわざわざ示した覚えはない。
実は、ここはプログラマーズ・フォーラムの一角なのです・・・・。ここに金銭感覚を求めるのはやめたほうがいい)))私自身は、このような問題はこのフォーラムとは別に解決したいと考えています。
図書館の最終的な目標は明確ではありません。
私はあなたに感謝し、あなたのライブラリから始まり、私はそれを少し洗練し、さらにいくつかの)))) 最終的には、行の関数を書き換え、またKanvasソースからの広い行関数、偽関数を削除し、イベントにスタブを置くなどすべてを変更しました。他の要素にバイナリサーチによる左右のバーの計算を追加し、さらにバイナリサーチ自体に大小を選択できる機能を追加しています。また、あらゆる種類の配列（時系列/共通）からビルドする機能を追加し、コンストラクトを変更する必要があるという結論に達しました))))
一周回ってきた。
ヒエラルキーが理解できる
もう一度制御を作り直さなければならないのですが、まだ別に入れたい座標があるのです。円形に並べたい。コトロールは座標から行くので、より真に迫り、システムも大幅に簡素化されると思うのですが。もちろん、私の主張は間違っているかもしれませんが......今のところ、素朴な解決策に思えます。
そしてコトロール......これはスタイルの基本要素に他ならず、理論的には座標の後にあるべきものなのです。
ロジック - スタイルなしで要素を持つことはできますが、座標なしで持つことはできません。
実はこれ、プログラマーズ・フォーラムの一コーナーなんです・・・・・。ここに金銭感覚を求めるのはやめたほうがいい)))私自身は、このような問題はこのフォーラムとは別に対処したい。
とても面白い。
隣で「タダ働きする人はいない」と熱いバトルが繰り広げられているスレッドがあるのですが、「金銭感覚を探しても無駄」とおっしゃいますね ?
とても面白い。
タダ働きする人はいない」という熱いバトルが繰り広げられている話題の横で、「金銭感覚を探すな」と言うのですか。
もらった図書館の著作権も主張しないし...。その財務的な要素は言うに及ばず。
ただ、どうすればいいのか、正しく知りたかっただけなんです。
ちょっとしたニーズがあれば、スクラップでコードを集めることだってできる。
理想は、この正しいもののミニバージョンを作りたいのですが。最小限のコードと最大限の有用性のために。
図書館の最終的な目標は明確では ありません。
ニコライさん、ようこそ。
最終的な目標は、現時点ですでにあるツールの欠点を解決しようとすることです。
プロジェクトとの接続のしやすさを向上させるための標準ライブラリの開発継続と、チャートオブジェクトを残してキャンバスに移行するグラフィックコンポーネントの改良が主な内容になると思います。
しかし、全体として、結果がどうなるかは憶測で決めないようにしましょう。
ニコライさん、ようこそ。
最終的な目標は、現時点ですでにあるツールの欠点を解決しようとすることです。
おそらく、プロジェクトとの接続のしやすさを向上させるための標準ライブラリの開発と、チャートオブジェクトとキャンバスへの移行を残したグラフィックコンポーネントの改良を継続することになるのでしょう。
しかし、一般的に、何が起こるかわからないと困惑するのはやめましょう。
エンジニアリングについて簡単に説明すると:
もし、ある「A」をリエンジニアリングで改善したいという気持ちがあるのなら、その重大な欠点を特定する必要があります。それらを列挙し、「A」の進化の過程でそれらを排除することが不可能である理由を説明するだけでよい。
一方で、誰もそれを禁じてはいない。コードを書くのが好きな人は、書いてみてください...。A "を自分流に書き換えても、新しいものになる
一周回ってきた。
ヒエラルキーが理解できる
もう一度制御を作り直さなければならないのですが、まだ別に入れたい座標があるのです。円形に並べたい。コトロールは座標から行くので、より真に迫り、システムも大幅に簡素化されると思うのですが。 もちろん、私の主張は間違っているかもしれませんが......今のところ、素朴な解決策に思えます。
そしてコトロール......これはスタイルの基本要素に他ならず、理論的には座標の後にあるべきものなのです。
論理 - スタイルのない要素を持つことはできますが、座標のない要素を持つことはできません。
反論するまでもなく、事実です )))
スタイルやテーマなど、最初に想定しておけば、後からねじ込むことも可能です。実際には、これらすべてが基本コントロールで発生するはずなので、機能性の向上もこのクラスで行くことになります。
座標については、チャートからの相対座標を計算する絶対座標と、親からの相対座標を計算するローカル座標の2種類がありますね。
例えば、フォームをレンダリングする場合、チャートへの配置は絶対座標で処理される。 ボタンをフォームに配置する場合、それが配置されているコンテナに対して、つまりフォームに対して相対的に配置する必要がある。
マウス移動イベントを受信すると、ハンドラでチャートに対するカーソル位置の絶対座標を取得します。カーソルがフォームや要素に当たっているかどうかを確認する場合、カーソルの絶対座標と要素の現在位置を、その位置関係を考慮しながら比較する必要があります。つまり、フォームの場合は単純に現在の座標とサイズとの比較になりますが、ボタンの場合は座標系におけるボタンの絶対位置を計算することになります。つまり、比較のためのX座標は以下のように計算されます。X = (Parent==null)?X():(X()+Parent.X()), X() は項目の X 位置を返すクラス関数です。ただし、親の存在自体のチェックは、この関数自体の中で行うことができる。その結果、ある要素が親を持つ場合、その座標は親の座標に親自身の座標 を足したものが返される。実際には，入れ子の数は任意であり，各要素はグラフに対してではなく，その上にある要素に対して相対的に位置決めされるので，絶対座標は再帰的に計算することができる。