Canvasでクラウドソーシングのプロジェクトを作る - ページ 41 1...343536373839404142434445 新しいコメント Nikolai Semko 2020.01.27 16:36 #401 Реter Konow:ニコライ 君の意見はいつも面白いね。グラフィックのプロジェクトが完成したので、それをみんなにプレゼントしたいんだ。まだ時間があるので、誰でもエンジンとデザイナーをテストすることができます。続いて、まったく別の展開になります。Alexeyは、マトリックスを標準的なOOP形式に変換するのを手伝ってくれることになりました。私は気にしないのですが、率直に言って-とても疑問です。正確には、ほとんど不可能であることは確かなのですが。同等のアナログができるまで1年はかかるだろう。私の見解では、プロジェクトを編集し、発展させる機会を人々に与えることは、理にかなっていると思います。私が急に止めると、他の人が続けてしまう可能性があります。要は、すべてコミュニティの役に立つようにすることです)。 もう、ページをめくって前に進むしかないのでしょう。 しかし、当然ながら誰もあなたのプロジェクトを 開発することはないでしょう。現実的でなければならない。 Реter Konow 2020.01.27 16:37 #402 Nikolai Semko: もう、ページをめくって前に進むしかないのでしょう。良い経験を積むことができました。 しかし、当然ながら誰もあなたのプロジェクトを開発することはありません。現実的でなければならない。 開発はしないが、応用はする。 Алексей Барбашин 2020.01.27 18:29 #403 Nikolai Semko: ピョートルさんの作品は、マーキングの言語というより、リクエストの言語のように見えますね。 また、ご存知のように、MQL5は最近、SQLite データベースと連携できるようになりました。 データベースとは、テーブルとテーブル間のリレーションシップの集合体である。 そして、クエリー言語（SQL - Structured QueryLanguage）がこれらのテーブルを操作している（作成、変更、クエリーおよびアクセス、削除）。 アドバイスは一切しない。あなたが誰のアドバイスも必要としないタイプであることは、もうわかっています。 ただ、考えるための情報です。 それに、すでに標準化され開発されているフォーマットに対してソリューションを出すのはコストがかかります。 今、私はJavaとデータベース（MySQL）の相互作用について勉強しています。Javaはこのために特別なツールを作らなければならなかった（JPA、Hibernate、DAO Design Pattern）。このトピックは、あなたと非常に近いところにあります。これらのツールは基本的にクラスであり、JavaからSQLへの変換器です。 私の考えでは、OOPとSQLで成功した後に、最初から始める方が良いと思います。また、マークアップ言語であるXMLも便利かも しれませんね。 きっと重宝しますよ!クロスプラットフォームのソリューションは、WPFの宣言的な記述で実行され、アンドロイドのactiviti、Xamarin、最終的にはWebページ - すべてXMLを使用して います。 "Javaはこのために特別なツールを作らなければならなかった" - あらゆるアドオンやツールは、アクセス、ネイティブアクセス、あるいはデータベースからのデータの読み取りやデータの追加を、エンド開発者からクエリを呼び出さずに行うオブジェクトバインディングを容易にするために作られます。もちろん、すべてがクエリで動作しますが、ただ、すべてがアドオンの中に深く隠されているのです。 そして、ピーターとなら、彼の意志さえあれば、すべてがうまくいく。今のところ、彼は自分のモデルを「押し付けよう」とする頑固な癖が抜けているんです。一方、私は、彼をマトリックスから抽象化し、一般的な推論に移そうとしています。彼が自分の母型に固執している限り、理性的な推論は難しい。でも、今のところ順調に進んでいますよ。 ニコライさん、ときどきこの議論に参加してくださいね。 Реter Konow 2020.01.27 20:19 #404 Алексей Барбашин: ... そして、ピーターにその意志があれば、すべてがうまくいくのです。今のところ、彼は自分のモデルを「押しつけ」ようとする癖がある。私は、彼をマトリックスから抽象化し、一般的な推論に移ろうとしているのです。彼が自分の母型に固執している限り、理性的な推論は難しい。でも、今のところ順調に進んでいますよ。 ... もう何かを押し付けるつもりはない）。ただ、それをどう授業に反映させたらいいのか、さっぱりわからないんです。今はデバッグに完全に集中しています。公開したらすぐに、あなたや他の人たちがもっとよくわかるようになりますよ。そうすれば、何らかのスキームが生まれるかもしれませんね。このスレッドではまだ集団主義が実を結ぶのかもしれません)。 Nikolai Semko 2020.01.27 23:22 #405 Алексей Барбашин: ニコライさん、ときどき会話に加わってくださいね。 構わないのですが、正直なところ、どうしたらいいのかもわからないんです。何度も言っていることですがピーターは自分の道を進めばいいんです。 彼は自給自足の人間であり、自分のボスであるため、後援を必要としない。時々、彼が庇護を必要としているように感じることがありますが、それは単なる錯覚であり、トリックであり、一種の誘惑です :)) Алексей Барбашин 2020.01.28 05:57 #406 Nikolai Semko: 構わないのですが、正直なところ、どうしたらいいのかもわからないんです。すべては、すでに何度も言われていることです。ピーターは自分の道を進めばいいんです。 彼は自給自足で、監督を必要としない、自分自身がボスだから だ。時々、彼が庇護を必要としているような気がするけれど、それはただの錯覚で、一種の誘い文句なんだ :)) ニコライ、ピーターを別の人格形成の道に導く試みは残す価値があると思いますか？ 追伸：昨日、サイトがダウンしたのは私だけでしょうか？ Реter Konow 2020.01.28 06:35 #407 Алексей Барбашин:ニコライ、ピーターを別の方法で人格形成に導く試みは残す価値があると思うか？ 別の方法でディレクションすることです。そのコードは私のよりも書き直しが簡単です）。CElementという 基底クラスをひとつ作り、そこからすべてのタイプの要素を継承させるという考え方がある。要素間のリンクの論理を考えるならその通りですが、要素の構造を考えるなら、基本クラスはCRec, CImage, CTextであるべきです。つまり、分類基準の選択次第ですべてが決まるのです。元素の物理的な構造による分類と、元素の種類による分類がある。分類には多くのバリエーションがあり、それぞれ異なるクラスライブラリ構造を提供します。一つの基準を選び、それに沿って行動することが必要です。 Алексей Барбашин 2020.01.28 07:22 #408 Реter Konow: それは、プロジェクトを別の方向に向けることです。そのコードは私のよりも書き直しが簡単です）。 ベースクラスCElementを1つ作り、そこからすべてのタイプの要素を子孫とすることです。 要素関係の論理を考えるならば、これは正しいのですが、要素の構造を考えるならば、基本クラスはCRec, CImage, CTextであるべきです。 つまり、分類基準の選択次第ですべてが決まるのです。 元素の物理的な構造による分類と、元素の種類による分類があります。分類には多くのバリエーションがあり、それぞれ異なるクラスライブラリ構造を提供します。一つの基準を選び、それに沿って行動することが必要です。 インターフェースやコントロールの先人たちの経験を見たほうがいいと思うんです。車輪の再発明や物事を複雑にしすぎることに意味があるとは思えません。多くのものが先に発明されているので、それをmqlに移植すればいいだけです。 私は、これらやこれらの制御の共通点をただ聞いたわけではありません。 Peterさん、次のコントロールの写真を載せてください。アイコンとキャプション付きのボタン、アイコンとキャプション付きのテキストラベル、チェックボックス、ラジオボタン、コンボボックス、パネル、入力フィールド です。 Реter Konow 2020.01.28 07:32 #409 Алексей Барбашин: この件に関しては、インターフェースやコントロールデザインの先達の経験を見た方が良いと思います。車輪の再発明や物事を複雑にしすぎることに意味はありません。多くのものが先に発明されており、それをmqlに移植すればいいだけです。 私は、これらやこれらの制御の共通点をただ聞いたわけではありません。 Peterさん、次のコントロールの画像をここに置いてください。アイコンとラベルの付いたボタン、アイコンとラベルの付いたテキストラベル、チェックボックス、ラジオボタン、コンボボックス、パネル、入力フィールド です。 先祖代々の経験があるが、どれが有効だろうか？例えば、スタッフライブラリーやアナトリー・ライブラリーには、すぐに使えるクラス編成が用意されていますが、これらはあくまでライブラリーです。つまり、要素は適切な関数を呼び出すことで生成される。マークアップ言語があるので、GUIを別ファイルで書くことができるんです。これはまったく別の技術です。それを考慮しなければ、普通のライブラリを作ればいいわけで、そのうちの2つはMQLですでに持っています。もう一台は必要ありません。キャンバス上にあるかないかではなく、その上にいかに簡単にインターフェイスを作れるかが重要なのです。写真は掲載予定です。 Алексей Барбашин 2020.01.28 07:49 #410 Реter Konow: 先人体験はあるけれど、どれにしようかな？例えば、スタッフライブラリーやアナトリアライブラリーは、既成の授業体系を提供していますが、これらは図書館です。つまり、要素は適切な関数を呼び出すことで生成される。マークアップ言語があるので、GUIを別ファイルで書くことができるんです。これはまったく別の技術です。それを考慮しなければ、普通のライブラリを作ればいいわけで、そのうちの2つがMQLにはすでにあるのです。もう一台は必要ありません。キャンバス上にあるかないかではなく、その上にいかに簡単にインターフェイスを作れるかが重要なのです。 写真を掲載します。 その両方についてです。何の上で描かれているのか、そこからどれだけ簡単にインターフェースを構築できるのか、ということです。 事実上、すべてが図書館である。例えば、ダイアログボックスのコンストラクタを作成しましたが、 何を基にしているのでしょうか？ 同じライブラリコントロールを基にしています。つまり、ユーザーがフォームに何かをドロップできるようにするためには、まさにこれらのコントロールを提供しなければならない、つまり、ユーザーはフォームから何かを選び出すことができるのです。のライブラリーを使用しています。だから、そう呼ばれているんです。そして、それを元にマークアップ・ファイルを生成し、ユーザーがmqlで使えるようにするのですが、最初はユーザーが利用可能なリストからコントロールを選択するという事実が残されています。同じ図書館でも、「横から見た」だけなんです。 1...343536373839404142434445 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ニコライ 君の意見はいつも面白いね。グラフィックのプロジェクトが完成したので、それをみんなにプレゼントしたいんだ。まだ時間があるので、誰でもエンジンとデザイナーをテストすることができます。続いて、まったく別の展開になります。
Alexeyは、マトリックスを標準的なOOP形式に変換するのを手伝ってくれることになりました。私は気にしないのですが、率直に言って-とても疑問です。正確には、ほとんど不可能であることは確かなのですが。同等のアナログができるまで1年はかかるだろう。私の見解では、プロジェクトを編集し、発展させる機会を人々に与えることは、理にかなっていると思います。私が急に止めると、他の人が続けてしまう可能性があります。
要は、すべてコミュニティの役に立つようにすることです)。
もう、ページをめくって前に進むしかないのでしょう。
しかし、当然ながら誰もあなたのプロジェクトを 開発することはないでしょう。現実的でなければならない。
もう、ページをめくって前に進むしかないのでしょう。良い経験を積むことができました。
しかし、当然ながら誰もあなたのプロジェクトを開発することはありません。現実的でなければならない。
開発はしないが、応用はする。
ピョートルさんの作品は、マーキングの言語というより、リクエストの言語のように見えますね。
また、ご存知のように、MQL5は最近、SQLite データベースと連携できるようになりました。
データベースとは、テーブルとテーブル間のリレーションシップの集合体である。
そして、クエリー言語（SQL - Structured QueryLanguage）がこれらのテーブルを操作している（作成、変更、クエリーおよびアクセス、削除）。
アドバイスは一切しない。あなたが誰のアドバイスも必要としないタイプであることは、もうわかっています。
ただ、考えるための情報です。
それに、すでに標準化され開発されているフォーマットに対してソリューションを出すのはコストがかかります。
今、私はJavaとデータベース（MySQL）の相互作用について勉強しています。Javaはこのために特別なツールを作らなければならなかった（JPA、Hibernate、DAO Design Pattern）。このトピックは、あなたと非常に近いところにあります。これらのツールは基本的にクラスであり、JavaからSQLへの変換器です。
私の考えでは、OOPとSQLで成功した後に、最初から始める方が良いと思います。また、マークアップ言語であるXMLも便利かも しれませんね。
きっと重宝しますよ!クロスプラットフォームのソリューションは、WPFの宣言的な記述で実行され、アンドロイドのactiviti、Xamarin、最終的にはWebページ - すべてXMLを使用して います。
"Javaはこのために特別なツールを作らなければならなかった" - あらゆるアドオンやツールは、アクセス、ネイティブアクセス、あるいはデータベースからのデータの読み取りやデータの追加を、エンド開発者からクエリを呼び出さずに行うオブジェクトバインディングを容易にするために作られます。もちろん、すべてがクエリで動作しますが、ただ、すべてがアドオンの中に深く隠されているのです。
そして、ピーターとなら、彼の意志さえあれば、すべてがうまくいく。今のところ、彼は自分のモデルを「押し付けよう」とする頑固な癖が抜けているんです。一方、私は、彼をマトリックスから抽象化し、一般的な推論に移そうとしています。彼が自分の母型に固執している限り、理性的な推論は難しい。でも、今のところ順調に進んでいますよ。
ニコライさん、ときどきこの議論に参加してくださいね。
...
そして、ピーターにその意志があれば、すべてがうまくいくのです。今のところ、彼は自分のモデルを「押しつけ」ようとする癖がある。私は、彼をマトリックスから抽象化し、一般的な推論に移ろうとしているのです。彼が自分の母型に固執している限り、理性的な推論は難しい。でも、今のところ順調に進んでいますよ。
...
ニコライさん、ときどき会話に加わってくださいね。
構わないのですが、正直なところ、どうしたらいいのかもわからないんです。何度も言っていることですがピーターは自分の道を進めばいいんです。
彼は自給自足の人間であり、自分のボスであるため、後援を必要としない。時々、彼が庇護を必要としているように感じることがありますが、それは単なる錯覚であり、トリックであり、一種の誘惑です :))
構わないのですが、正直なところ、どうしたらいいのかもわからないんです。すべては、すでに何度も言われていることです。ピーターは自分の道を進めばいいんです。
彼は自給自足で、監督を必要としない、自分自身がボスだから だ。時々、彼が庇護を必要としているような気がするけれど、それはただの錯覚で、一種の誘い文句なんだ :))
ニコライ、ピーターを別の人格形成の道に導く試みは残す価値があると思いますか？
追伸：昨日、サイトがダウンしたのは私だけでしょうか？
ニコライ、ピーターを別の方法で人格形成に導く試みは残す価値があると思うか？
それは、プロジェクトを別の方向に向けることです。そのコードは私のよりも書き直しが簡単です）。
インターフェースやコントロールの先人たちの経験を見たほうがいいと思うんです。車輪の再発明や物事を複雑にしすぎることに意味があるとは思えません。多くのものが先に発明されているので、それをmqlに移植すればいいだけです。
私は、これらやこれらの制御の共通点をただ聞いたわけではありません。
Peterさん、次のコントロールの写真を載せてください。アイコンとキャプション付きのボタン、アイコンとキャプション付きのテキストラベル、チェックボックス、ラジオボタン、コンボボックス、パネル、入力フィールド です。
この件に関しては、インターフェースやコントロールデザインの先達の経験を見た方が良いと思います。車輪の再発明や物事を複雑にしすぎることに意味はありません。多くのものが先に発明されており、それをmqlに移植すればいいだけです。
私は、これらやこれらの制御の共通点をただ聞いたわけではありません。
Peterさん、次のコントロールの画像をここに置いてください。アイコンとラベルの付いたボタン、アイコンとラベルの付いたテキストラベル、チェックボックス、ラジオボタン、コンボボックス、パネル、入力フィールド です。
先人体験はあるけれど、どれにしようかな？例えば、スタッフライブラリーやアナトリアライブラリーは、既成の授業体系を提供していますが、これらは図書館です。つまり、要素は適切な関数を呼び出すことで生成される。マークアップ言語があるので、GUIを別ファイルで書くことができるんです。これはまったく別の技術です。それを考慮しなければ、普通のライブラリを作ればいいわけで、そのうちの2つがMQLにはすでにあるのです。もう一台は必要ありません。キャンバス上にあるかないかではなく、その上にいかに簡単にインターフェイスを作れるかが重要なのです。
その両方についてです。何の上で描かれているのか、そこからどれだけ簡単にインターフェースを構築できるのか、ということです。
事実上、すべてが図書館である。例えば、ダイアログボックスのコンストラクタを作成しましたが、 何を基にしているのでしょうか？ 同じライブラリコントロールを基にしています。つまり、ユーザーがフォームに何かをドロップできるようにするためには、まさにこれらのコントロールを提供しなければならない、つまり、ユーザーはフォームから何かを選び出すことができるのです。のライブラリーを使用しています。だから、そう呼ばれているんです。そして、それを元にマークアップ・ファイルを生成し、ユーザーがmqlで使えるようにするのですが、最初はユーザーが利用可能なリストからコントロールを選択するという事実が残されています。同じ図書館でも、「横から見た」だけなんです。