Canvasでクラウドソーシングのプロジェクトを作る - ページ 35 1...282930313233343536373839404142...45 新しいコメント Maxim Kuznetsov 2020.01.26 17:26 #341 ちなみに、以前は長らく放置されていたものを人々が扱うので これは、GUIのクライアント・サーバ・インターフェイスであるyandexから、ネットワーク上でも撮影したランダムなスクリーンショットである。車輪を再発明する必要はない...(宣伝1秒）パイは本当にかっこいいですね。正直なタングステンはそこに住んでいる :-) Roman 2020.01.26 17:37 #342 Алексей Барбашин: そう、そこが一番の問題なんです!同市場ではdllの使用が禁止されているため、車輪の再発明をしなければならない。GUIは必要ないと思う人がいても、1つのスレッドでどんな場合でも複雑で長い計算はうまくいかず、すべてがハングアップしてしまいます。 だから、市場で禁止されているDELLでやらなければならない...。 といった具合に。そのため、私はすべてをmqlメソッドで描いて解決する必要があります。 実は、GUIとロジックをスレッドに分離することは、もちろんすでに可能です。ここでは、並列性の問題については、すでに https://www.mql5.com/ru/forum/288985/page5#comment_14722396 で議論されています。 その結果、winndaで行われているように、フォーム自体はメインスレッドに残し、追加の計算を「バックグラウンド」実行に移行させることができるようになりました。Windows、Linux、Androidの場合、このようになります。 ええ、その記事は見たことがあります。調べる気も起きないようなコードの束で、別の松葉杖のようなものです。 何でもかんでもdllでやったほうが圧倒的に早いし楽なのに。 ちなみに、mqlのSocketとWebRequestは、mqlサーバが使えないと、接続が切れてしまうので、あきらめました。 ソケットやwebrequestの関数はブロックされるので、mqlのソケットやwebrequestsを使ったアプリケーションを作る場合は、この点に注意してください。 Maxim Kuznetsov 2020.01.26 17:47 #343 Maxim Kuznetsov: ちなみに、今までやっていたことを人がやっている以上 これは、yandex、GUIクライアントサーバーインターフェイス、およびネットワーク経由で取得したランダムスクリーンショットです。車輪を再発明する必要はない...(宣伝1秒）パイは本当にかっこいいですね。正直なタングステンはそこに住んでいる :-) ちなみに、スクリーンショットにあるScratchは、Konovがやりたいことはだいたい決まっていて、サイコロからアルゴリズムを組み立てることなんです。 Roman 2020.01.26 17:53 #344 Maxim Kuznetsov: それは、マイクロソフトが担当しているからです :-) 海賊版システムで製品のアップグレードやアクティベーションを行うと、ログイン情報が失われるのはなぜでしょうか？ マイクロソフトはDLLの署名キーに何の関係があるのでしょうか？ それは開発者を特定するだけ です。 dllに署名するための鍵は、マーケットプレイスで完全に認証された人にMQから渡すことができます。 このキーを使って、開発者は自分のDLLに署名し、誰が書いたかを識別します。 Dll署名キーは、製品のアクティベーションに影響しません。 Реter Konow 2020.01.26 17:54 #345 Maxim Kuznetsov: /// MKLにまともなGUIがないのはご理解いただけるでしょうか。手持ちのものは95年のものです。恥を知れ...また、サードパーティ製のGUIを求める声もありますが、MTでどう使うかは考えていますか？どのように接続するのですか？それとも、ハニーをあげないで、お決まりの言葉を言わせて？)) Алексей Барбашин 2020.01.26 18:19 #346 Реter Konow: MKLにまともなGUIがないのはご理解いただけるでしょうか。手持ちのものは95年のものです。恥を知れ...また、サードパーティ製のGUIを求める声もありますが、MTでどう使うかは考えていますか？どのように接続するのですか？それともハニーをあげないで、お決まりの言葉を言わせてもらう？)) マキシムはこのテーマを誰よりもよく知っていて、1年半ほど前に、マークアップをベースにしたGUIのバージョンを発表しています。さらに、GUIは外部環境で構築されたが、プログラム（インジケータ、Expert Advisor）と完全に相互作用していた。 マキシムさん、質問に答えてしまってすみませんでした。 しかし、話を元に戻したいと思います。標準ライブラリの 動作に関する記事から画像を引っ張ってきました。 このスクリーンショットは、ダイアログの構成を簡略化したものです。 このバージョンでは、Borderはチャート上にキャンバスオブジェクトを作成するメインエレメントであり、すべてのスレーブオブジェクトはその上に描画されます。というか、スレーブオブジェクトに依存して描画される。 CloseボタンはCaptionに、CaptionはBorderに描画され、描画されたすべての要素とともにCanvasに描画されます。 Реter Konow 2020.01.26 18:33 #347 Алексей Барбашин: ピーター 君の目を盗んで、マキシムのために教えてあげようかな。マキシムはこの話題に誰よりも詳しく、1年半ほど前に、マークアップをベースにしたかのように形成された彼のバージョンのGUIを投稿したんだ。さらに、GUIは外部環境で構築されたが、プログラム（インジケータ、Expert Advisor）と完全に相互作用していた。 マキシムさん、質問に答えてしまってすみませんでした。 しかし、話を元に戻したいと思います。標準ライブラリの 動作に関する記事から画像を引っ張ってきました。 このスクリーンショットは、ダイアログの構成を簡略化したものです。 このバージョンでは、Borderはチャート上にキャンバスオブジェクトを作成するメインエレメントであり、すべてのスレーブオブジェクトはその上に描画されます。というか、スレーブオブジェクトに依存して描画される。 閉じるボタンはCaptionに、CaptionはBorderに描画され、このボタンと描画されたすべての要素がCanvasに描画されます。 彼が何を投稿し、GUIの問題で何をしたかは知りませんが、私のスレッドでは、彼は技術的な提案や解決策、議論などを一つも行っていません。サードパーティのソリューションを指摘し、車輪の再発明をしないよう促す、空虚な荒らし行為のみ。 話を元に戻します。 私が標準ライブラリに精通している限り（実際にはほとんどないのですが）、エレメントとウィンドウはMTオブジェクトで構成されています。つまり、私たちの文脈では、彼らはキャンバスに描かれていないのです。もちろん描画はされますが、キャンバス上には描画されないので、ピクセルの色を制御したり、表面のグラデーションを作成したりすることはできません。 理論的には、ライブラリの構造をコピーして、キャンバス上にアナログを作ることができます。理論的には... 問題は、CCanvas自体がその上でGUIを作るのに適していないことです。なぜ？なぜなら、kanvasシステムは主にグラフィックプリミティブに使用されるからです。つまり、要するにこのクラスはプリミティブ以外何も提供しないのです。GUIアーキタイプは自分で作る必要があります。そしてこの場合、授業は必要ない。自前のソリューションでやりくりする方が便利です。結局、クラスがなくても長方形のマーカーを描くことはできるのです。キャンバスを作成したり、読み込んだりするのと同じです。それはとてもシンプルなことです。そのため、私は自分なりの解決策を優先しました。 しかし、CCanvasなしではやっていけない人がいます。だから、こだわらないんです。 Алексей Барбашин 2020.01.26 18:41 #348 Реter Konow: GUI関連で何を投稿し、何をしたかは知りませんが、私のスレッドでは、技術的な提案も、解決策も、議論も一切していません。サードパーティのソリューションを指摘し、車輪の再発明をしないよう促す、空虚な荒らし行為のみ。 話を元に戻します。 私が標準ライブラリに精通している限り（実際にはほとんどないのですが）、エレメントとウィンドウはMTオブジェクトで構成されています。つまり、私たちの文脈では、彼らはキャンバスに描かれていないのです。もちろん描画はされますが、キャンバス上には描画されないので、ピクセルの色を制御したり、表面のグラデーションを作成したりすることはできません。 理論的には、ライブラリの構造をコピーして、キャンバス上にアナログを作ることができます。理論的には... 問題は、CCanvas自体がその上でGUIを作るのに適していないことです。なぜ？なぜなら、kanvasシステムは主にグラフィックプリミティブに使用されるからです。つまり、要するにこのクラスはプリミティブ以外何も提供しないのです。GUIアーキタイプは自分で作る必要があります。そしてこの場合、授業は必要ない。自前のソリューションでやりくりする方が便利です。結局、クラスがなくても長方形のマーカーを描くことはできるのです。キャンバスを作成したり、読み込んだりするのと同じです。それはとてもシンプルなことです。そのため、私は自分なりの解決策を優先しました。 しかし、CCanvasなしではやっていけない人がいます。だから、私はそれを主張しない。 ストップ！ピーター（だよね）、お互いを理解するために規約を作ろうよ。条件1：CanvasをCCanvasクラスと呼ばず、画面の一部やあるリソースを具体的に描画するためのCanvasと呼ぶことにする。CCanvasクラスは、このようなこととは全く関係がないので、ここでは一切触れないことにします。そのキャンバスに描画するための機能を提供するだけで、それだけで十分なのです。実は、私たちはさまざまな手法で絵を描くことができます。 描画」とは、画素の配列を形成し、それを基にリソースを作成 し、チャート上に配置することを意味します。 Реter Konow 2020.01.26 18:42 #349 Алексей Барбашин: ストップ！ピーター（ですよね）、お互いの理解のために、ある程度の慣例を受け入れましょう。条件1：CCanvasをクラスと呼ばず、画面の一部、特に1つのリソースを描画するためのキャンバスと呼ぶことにする。CCanvasクラスは、このようなこととは全く関係がないので、ここでは一切触れないことにします。そのキャンバスに描画するための機能を提供するだけで、それだけで十分なのです。実は、私たちはさまざまな手法で絵を描くことができます。 描画」とは、画素の配列を形成し、それを基にリソースを作成 し、チャート上に配置することを意味します。 そうなんです。 Maxim Kuznetsov 2020.01.26 18:49 #350 Алексей Барбашин: ピーター 君の目を盗んで、マキシムのために教えてあげようかな。マキシムはこの話題に誰よりも詳しく、1年半ほど前に、マークアップをベースに形成された彼版のGUIを発表しているんだ。さらに、GUIは外部環境で構築されたが、プログラム（インジケータ、Expert Advisor）と完全に相互作用していた。 マキシムさん、質問に答えてしまってすみませんでした。 しかし、話を元に戻したいと思います。標準ライブラリの 動作に関する記事から画像を引っ張ってきました。 このスクリーンショットは、ダイアログの構成を簡略化したものです。 このバージョンでは、Borderはチャート上にキャンバスオブジェクトを作成する主要な要素であり、すべてのスレーブオブジェクトはその上に描画されます。というか、スレーブオブジェクトに依存して描画される。 閉じるボタンはCaptionに、CaptionはBorderに描画され、すべての要素はキャンバスに描画されます。 もちろん、これは全く正しいことではありません :-) Tcl DLL (ツール共通言語) にインターフェースを付け、TkグラフィックスをPython/Ruby/その他でGUIとして共有する。 目標はGUIを手に入れることではなく、素敵な副産物を手に入れることでした :-) tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ; 私見ですが、便利で、何より短いです :-) 私は誰かを煽っているわけではありません - 私はtcl/tkを知っていて、それを使い、私の経験を共有しています（sourceforge atclを参照）。 1...282930313233343536373839404142...45 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ちなみに、以前は長らく放置されていたものを人々が扱うので
これは、GUIのクライアント・サーバ・インターフェイスであるyandexから、ネットワーク上でも撮影したランダムなスクリーンショットである。車輪を再発明する必要はない...
(宣伝1秒）パイは本当にかっこいいですね。正直なタングステンはそこに住んでいる :-)
そう、そこが一番の問題なんです!同市場ではdllの使用が禁止されているため、車輪の再発明をしなければならない。GUIは必要ないと思う人がいても、1つのスレッドでどんな場合でも複雑で長い計算はうまくいかず、すべてがハングアップしてしまいます。 だから、市場で禁止されているDELLでやらなければならない...。
といった具合に。そのため、私はすべてをmqlメソッドで描いて解決する必要があります。
実は、GUIとロジックをスレッドに分離することは、もちろんすでに可能です。ここでは、並列性の問題については、すでに https://www.mql5.com/ru/forum/288985/page5#comment_14722396 で議論されています。
その結果、winndaで行われているように、フォーム自体はメインスレッドに残し、追加の計算を「バックグラウンド」実行に移行させることができるようになりました。Windows、Linux、Androidの場合、このようになります。
ええ、その記事は見たことがあります。調べる気も起きないようなコードの束で、別の松葉杖のようなものです。
何でもかんでもdllでやったほうが圧倒的に早いし楽なのに。
ちなみに、mqlのSocketとWebRequestは、mqlサーバが使えないと、接続が切れてしまうので、あきらめました。
ソケットやwebrequestの関数はブロックされるので、mqlのソケットやwebrequestsを使ったアプリケーションを作る場合は、この点に注意してください。
ちなみに、今までやっていたことを人がやっている以上
これは、yandex、GUIクライアントサーバーインターフェイス、およびネットワーク経由で取得したランダムスクリーンショットです。車輪を再発明する必要はない...
(宣伝1秒）パイは本当にかっこいいですね。正直なタングステンはそこに住んでいる :-)
ちなみに、スクリーンショットにあるScratchは、Konovがやりたいことはだいたい決まっていて、サイコロからアルゴリズムを組み立てることなんです。
それは、マイクロソフトが担当しているからです :-)
海賊版システムで製品のアップグレードやアクティベーションを行うと、ログイン情報が失われるのはなぜでしょうか？
マイクロソフトはDLLの署名キーに何の関係があるのでしょうか？ それは開発者を特定するだけ です。
dllに署名するための鍵は、マーケットプレイスで完全に認証された人にMQから渡すことができます。
このキーを使って、開発者は自分のDLLに署名し、誰が書いたかを識別します。
Dll署名キーは、製品のアクティベーションに影響しません。
///
MKLにまともなGUIがないのはご理解いただけるでしょうか。手持ちのものは95年のものです。恥を知れ...また、サードパーティ製のGUIを求める声もありますが、MTでどう使うかは考えていますか？どのように接続するのですか？それとも、ハニーをあげないで、お決まりの言葉を言わせて？))
MKLにまともなGUIがないのはご理解いただけるでしょうか。手持ちのものは95年のものです。恥を知れ...また、サードパーティ製のGUIを求める声もありますが、MTでどう使うかは考えていますか？どのように接続するのですか？それともハニーをあげないで、お決まりの言葉を言わせてもらう？))
マキシムはこのテーマを誰よりもよく知っていて、1年半ほど前に、マークアップをベースにしたGUIのバージョンを発表しています。さらに、GUIは外部環境で構築されたが、プログラム（インジケータ、Expert Advisor）と完全に相互作用していた。
マキシムさん、質問に答えてしまってすみませんでした。
しかし、話を元に戻したいと思います。標準ライブラリの 動作に関する記事から画像を引っ張ってきました。
このスクリーンショットは、ダイアログの構成を簡略化したものです。
このバージョンでは、Borderはチャート上にキャンバスオブジェクトを作成するメインエレメントであり、すべてのスレーブオブジェクトはその上に描画されます。というか、スレーブオブジェクトに依存して描画される。
CloseボタンはCaptionに、CaptionはBorderに描画され、描画されたすべての要素とともにCanvasに描画されます。
ピーター 君の目を盗んで、マキシムのために教えてあげようかな。マキシムはこの話題に誰よりも詳しく、1年半ほど前に、マークアップをベースにしたかのように形成された彼のバージョンのGUIを投稿したんだ。さらに、GUIは外部環境で構築されたが、プログラム（インジケータ、Expert Advisor）と完全に相互作用していた。
マキシムさん、質問に答えてしまってすみませんでした。
しかし、話を元に戻したいと思います。標準ライブラリの 動作に関する記事から画像を引っ張ってきました。
このスクリーンショットは、ダイアログの構成を簡略化したものです。
このバージョンでは、Borderはチャート上にキャンバスオブジェクトを作成するメインエレメントであり、すべてのスレーブオブジェクトはその上に描画されます。というか、スレーブオブジェクトに依存して描画される。
閉じるボタンはCaptionに、CaptionはBorderに描画され、このボタンと描画されたすべての要素がCanvasに描画されます。
彼が何を投稿し、GUIの問題で何をしたかは知りませんが、私のスレッドでは、彼は技術的な提案や解決策、議論などを一つも行っていません。サードパーティのソリューションを指摘し、車輪の再発明をしないよう促す、空虚な荒らし行為のみ。
話を元に戻します。
私が標準ライブラリに精通している限り（実際にはほとんどないのですが）、エレメントとウィンドウはMTオブジェクトで構成されています。つまり、私たちの文脈では、彼らはキャンバスに描かれていないのです。もちろん描画はされますが、キャンバス上には描画されないので、ピクセルの色を制御したり、表面のグラデーションを作成したりすることはできません。
理論的には、ライブラリの構造をコピーして、キャンバス上にアナログを作ることができます。理論的には...
問題は、CCanvas自体がその上でGUIを作るのに適していないことです。なぜ？なぜなら、kanvasシステムは主にグラフィックプリミティブに使用されるからです。つまり、要するにこのクラスはプリミティブ以外何も提供しないのです。GUIアーキタイプは自分で作る必要があります。そしてこの場合、授業は必要ない。自前のソリューションでやりくりする方が便利です。結局、クラスがなくても長方形のマーカーを描くことはできるのです。キャンバスを作成したり、読み込んだりするのと同じです。それはとてもシンプルなことです。そのため、私は自分なりの解決策を優先しました。
しかし、CCanvasなしではやっていけない人がいます。だから、こだわらないんです。
GUI関連で何を投稿し、何をしたかは知りませんが、私のスレッドでは、技術的な提案も、解決策も、議論も一切していません。サードパーティのソリューションを指摘し、車輪の再発明をしないよう促す、空虚な荒らし行為のみ。
話を元に戻します。
私が標準ライブラリに精通している限り（実際にはほとんどないのですが）、エレメントとウィンドウはMTオブジェクトで構成されています。つまり、私たちの文脈では、彼らはキャンバスに描かれていないのです。もちろん描画はされますが、キャンバス上には描画されないので、ピクセルの色を制御したり、表面のグラデーションを作成したりすることはできません。
理論的には、ライブラリの構造をコピーして、キャンバス上にアナログを作ることができます。理論的には...
問題は、CCanvas自体がその上でGUIを作るのに適していないことです。なぜ？なぜなら、kanvasシステムは主にグラフィックプリミティブに使用されるからです。つまり、要するにこのクラスはプリミティブ以外何も提供しないのです。GUIアーキタイプは自分で作る必要があります。そしてこの場合、授業は必要ない。自前のソリューションでやりくりする方が便利です。結局、クラスがなくても長方形のマーカーを描くことはできるのです。キャンバスを作成したり、読み込んだりするのと同じです。それはとてもシンプルなことです。そのため、私は自分なりの解決策を優先しました。
しかし、CCanvasなしではやっていけない人がいます。だから、私はそれを主張しない。
ストップ！ピーター（だよね）、お互いを理解するために規約を作ろうよ。条件1：CanvasをCCanvasクラスと呼ばず、画面の一部やあるリソースを具体的に描画するためのCanvasと呼ぶことにする。CCanvasクラスは、このようなこととは全く関係がないので、ここでは一切触れないことにします。そのキャンバスに描画するための機能を提供するだけで、それだけで十分なのです。実は、私たちはさまざまな手法で絵を描くことができます。
描画」とは、画素の配列を形成し、それを基にリソースを作成 し、チャート上に配置することを意味します。
ストップ！ピーター（ですよね）、お互いの理解のために、ある程度の慣例を受け入れましょう。条件1：CCanvasをクラスと呼ばず、画面の一部、特に1つのリソースを描画するためのキャンバスと呼ぶことにする。CCanvasクラスは、このようなこととは全く関係がないので、ここでは一切触れないことにします。そのキャンバスに描画するための機能を提供するだけで、それだけで十分なのです。実は、私たちはさまざまな手法で絵を描くことができます。
描画」とは、画素の配列を形成し、それを基にリソースを作成 し、チャート上に配置することを意味します。
そうなんです。
ピーター 君の目を盗んで、マキシムのために教えてあげようかな。マキシムはこの話題に誰よりも詳しく、1年半ほど前に、マークアップをベースに形成された彼版のGUIを発表しているんだ。さらに、GUIは外部環境で構築されたが、プログラム（インジケータ、Expert Advisor）と完全に相互作用していた。
マキシムさん、質問に答えてしまってすみませんでした。
しかし、話を元に戻したいと思います。標準ライブラリの 動作に関する記事から画像を引っ張ってきました。
このスクリーンショットは、ダイアログの構成を簡略化したものです。
このバージョンでは、Borderはチャート上にキャンバスオブジェクトを作成する主要な要素であり、すべてのスレーブオブジェクトはその上に描画されます。というか、スレーブオブジェクトに依存して描画される。
閉じるボタンはCaptionに、CaptionはBorderに描画され、すべての要素はキャンバスに描画されます。
もちろん、これは全く正しいことではありません :-)
Tcl DLL (ツール共通言語) にインターフェースを付け、TkグラフィックスをPython/Ruby/その他でGUIとして共有する。
目標はGUIを手に入れることではなく、素敵な副産物を手に入れることでした :-)
tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ;
私見ですが、便利で、何より短いです :-)
私は誰かを煽っているわけではありません - 私はtcl/tkを知っていて、それを使い、私の経験を共有しています（sourceforge atclを参照）。