エラー、バグ、質問 - ページ 3122 1...311531163117311831193120312131223123312431253126312731283129...3185 新しいコメント Alexey Viktorov 2021.12.18 16:57 #31211 Vitaly Muzichenko #:そして、誰かがグラフィカルなオブジェクトを持つプログラムを持っている場合、あなたのタイププレフィックス "l" < プレフィックス "l" による削除です（オブジェクトが作成されたときに "label" と "line" という名前が使われました>）。サードパーティ製プログラム内の "l " で始まるすべてのオブジェクトを消去します。これは良い解決策とは言えません。 Vitalyさん、初心者スレに入ったらどうですか？これらの基本は、多かれ少なかれプログラマーが昔から知っていることです。そして、「星」のものだけが、すべて知っているわけではない・・・。 Vitaly Muzichenko 2021.12.18 17:04 #31212 Alexey Viktorov #:Vitalyさん、初心者スレに入ったらどうですか？これらの基本は、多かれ少なかれプログラマーには昔から知られていることです。そして、「星」のものだけが、すべて知っているわけではない・・・。 素晴らしい ええ、たぶん行きますよ :) x572intraday 2021.12.18 17:12 #31213 Vitaly Muzichenko #:そして、誰かがグラフィカルなオブジェクトを持つプログラムを持っている場合、あなたのタイププレフィックス "l" < プレフィックス "l" による削除です（オブジェクトが作成されたときに "label" と "line" という名前が使われました >）。サードパーティ製プログラム内の "l " で始まるすべてのオブジェクトを消去します。これは良い解決策とは言えません。 私もそう思っていたんです。他のプログラマーが同じオブジェクト名や同じプレフィックスの名前を糊塗する可能性があるので、プレフィックス（特に短いもの）でオブジェクトを削除することは、完全に一致する名前のオブジェクトにぶつかって削除するよりも危険です。また、2つ目のプログラムでは、すでに存在する名前を持つ2つ目のオブジェクトを作成することはできず、前のオブジェクトを残す必要があることも覚えておく必要があります（私の意見です）。いずれにせよ、このようなオブジェクトを自分のオブジェクトだと判断して削除しようとする近隣のプログラムは、同じ名前の他人のオブジェクトを削除することになります。 同じプログラム内のオブジェクトの名前をできるだけ排他的にすることで、同じ名前の異質なオブジェクトに出くわして不要な操作をしてしまう確率を下げる、というのが今のところ唯一の解決策だと思います。しかし、オブジェクト名の長さには制限があるため、プレフィックスを長くすることは技術的に必ずしも可能ではないことを念のためお伝えしておきます。 Vitaly Muzichenko 2021.12.18 17:22 #31214 x572intraday #:これは、私も考えていたことです。他のプログラマーが同じオブジェクト名や同じプレフィックスを持つ名前を作る可能性があるので、プレフィックス（特に短いもの）でオブジェクトを削除することは、完全に一致したオブジェクトに名前でぶつかって削除するよりも危険です。また、2つ目のプログラムが既存の名前で2つ目のオブジェクトを作成することはできず、前のオブジェクトが残らなければならないことも念頭に置いておく必要があります（私の意見です）。いずれにせよ、そのようなオブジェクトを自分のオブジェクトだと判断して削除する2番目のプログラムは、同じ名前の他人のオブジェクトを削除することになります。同じプログラム内のオブジェクトの名前をできるだけ排他的にすることで、同じ名前の異質なオブジェクトに出くわして不要な操作をしてしまう確率を下げる、というのが今のところ唯一の解決策だと思います。しかし、オブジェクト名の長さには制限があるため、プレフィックスを長くすることは技術的に必ずしも可能ではないことを念のためお伝えしておきます。 念を押すまでもなく、私は毎日グラフィカルなオブジェクトを使って仕事をしています。 誤った論理は......なんだ？なるほど、失敗のポイントですね。それはあなたの場合です。 x572intraday 2021.12.18 17:50 #31215 Vitaly Muzichenko #:私は毎日グラフィカルなオブジェクトを使って仕事をしているので、思い出す必要はないでしょう。誤った論理がカギを握る...何？なるほど、失敗のポイントですね。それはあなたの場合です。また、失敗とは何でしょうか？ そして、私は一般的に、あなたのことではなく（私たちは私的な文通をしているわけではありません）、私たちを読んでいる一般の人々、その中にはおそらくアマチュアがいることを思い起こさせるのです。 Vitaly Muzichenko 2021.12.18 17:55 #31216 x572intraday #:そして、その失敗とは？ すでに記述していますが、選択はあなた次第です。 このプログラムは、あなたにとって貴重で正しいものなのです。しかし、そこには批判的なものであっても、受け入れがたい欠点があるものです。 以上、私の評価を述べたので、各自で整理してください。 x572intraday 2021.12.18 18:14 #31217 Vitaly Muzichenko #:すでに記述していますが、選択はあなた次第です。 私はあなたを包括的に説得し、批判的でないいくつかの些細な点でのみあなたの正しさを認めました。しかし、もしあなたが感動せず、思いとどまったのなら、私は理解します。コードの作者から直接反論を受け入れるのは難しいのです。 x572intraday 2021.12.18 18:14 #31218 フリーコードを探すといえば プログラマーの何パーセントが、有益な取引のために、あるいはコードを学ぶためにプログラムを検索しているか、推測してみてください。個人的には、この分野でプログラマーを目指す人は圧倒的に少ないので、前者の方向性が強いと思います。 Vitaly Muzichenko 2021.12.18 18:36 #31219 x572intraday #:フリーコードを探すといえばプログラマーの何パーセントが、有益な取引のために、あるいはコードを学ぶためにプログラムを検索しているか、推測してみてください。個人的には、検索する人の中には、自分がこの分野のプログラマーだと思う人が圧倒的に少ないので、前者の方が優勢だと思います。 要は、そのようなコードは個人のマシンでは使えないということなのですが、あなたはそれを認めていませんね。プログラマーは確かに、コードの中身を見た上で、それを入れることはないでしょう。 また、プリフィクスについても議論を始めたが、私は議論するためにここに来たのではないのだ。 がんばってください。 x572intraday 2021.12.18 21:50 #31220 Vitaly Muzichenko #:それは、個人のマシンではそのコードは使えないのに、それを認めなかったということです。 もちろん、そんなことはしていない。なぜなら、これらの欠陥がマシンの速度を低下させるためには、負荷の高い計算、例えば非常に太いループや非常に頻繁な再初期化で使用しなければならないからです。そのような場合には、このコードの採用はお勧めできません。しかし、今回の場合はすべてが空回り。失敗を声高に主張する矛盾は屈辱以外の何物でもない。でも、ありがとうございました。 そして、より悟りを開くために、私は常に自分のコードを改善することに前向きです。 1...311531163117311831193120312131223123312431253126312731283129...3185 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
そして、誰かがグラフィカルなオブジェクトを持つプログラムを持っている場合、あなたのタイププレフィックス "l" < プレフィックス "l" による削除です（オブジェクトが作成されたときに "label" と "line" という名前が使われました>）。
サードパーティ製プログラム内の "l " で始まるすべてのオブジェクトを消去します。これは良い解決策とは言えません。
Vitalyさん、初心者スレに入ったらどうですか？これらの基本は、多かれ少なかれプログラマーが昔から知っていることです。そして、「星」のものだけが、すべて知っているわけではない・・・。
Vitalyさん、初心者スレに入ったらどうですか？これらの基本は、多かれ少なかれプログラマーには昔から知られていることです。そして、「星」のものだけが、すべて知っているわけではない・・・。
素晴らしい
ええ、たぶん行きますよ :)
そして、誰かがグラフィカルなオブジェクトを持つプログラムを持っている場合、あなたのタイププレフィックス "l" < プレフィックス "l" による削除です（オブジェクトが作成されたときに "label" と "line" という名前が使われました >）。
サードパーティ製プログラム内の "l " で始まるすべてのオブジェクトを消去します。これは良い解決策とは言えません。
私もそう思っていたんです。他のプログラマーが同じオブジェクト名や同じプレフィックスの名前を糊塗する可能性があるので、プレフィックス（特に短いもの）でオブジェクトを削除することは、完全に一致する名前のオブジェクトにぶつかって削除するよりも危険です。また、2つ目のプログラムでは、すでに存在する名前を持つ2つ目のオブジェクトを作成することはできず、前のオブジェクトを残す必要があることも覚えておく必要があります（私の意見です）。いずれにせよ、このようなオブジェクトを自分のオブジェクトだと判断して削除しようとする近隣のプログラムは、同じ名前の他人のオブジェクトを削除することになります。
同じプログラム内のオブジェクトの名前をできるだけ排他的にすることで、同じ名前の異質なオブジェクトに出くわして不要な操作をしてしまう確率を下げる、というのが今のところ唯一の解決策だと思います。しかし、オブジェクト名の長さには制限があるため、プレフィックスを長くすることは技術的に必ずしも可能ではないことを念のためお伝えしておきます。
これは、私も考えていたことです。他のプログラマーが同じオブジェクト名や同じプレフィックスを持つ名前を作る可能性があるので、プレフィックス（特に短いもの）でオブジェクトを削除することは、完全に一致したオブジェクトに名前でぶつかって削除するよりも危険です。また、2つ目のプログラムが既存の名前で2つ目のオブジェクトを作成することはできず、前のオブジェクトが残らなければならないことも念頭に置いておく必要があります（私の意見です）。いずれにせよ、そのようなオブジェクトを自分のオブジェクトだと判断して削除する2番目のプログラムは、同じ名前の他人のオブジェクトを削除することになります。
同じプログラム内のオブジェクトの名前をできるだけ排他的にすることで、同じ名前の異質なオブジェクトに出くわして不要な操作をしてしまう確率を下げる、というのが今のところ唯一の解決策だと思います。しかし、オブジェクト名の長さには制限があるため、プレフィックスを長くすることは技術的に必ずしも可能ではないことを念のためお伝えしておきます。
念を押すまでもなく、私は毎日グラフィカルなオブジェクトを使って仕事をしています。
誤った論理は......なんだ？なるほど、失敗のポイントですね。それはあなたの場合です。
私は毎日グラフィカルなオブジェクトを使って仕事をしているので、思い出す必要はないでしょう。
誤った論理がカギを握る...何？なるほど、失敗のポイントですね。それはあなたの場合です。
また、失敗とは何でしょうか？
そして、私は一般的に、あなたのことではなく（私たちは私的な文通をしているわけではありません）、私たちを読んでいる一般の人々、その中にはおそらくアマチュアがいることを思い起こさせるのです。そして、その失敗とは？
すでに記述していますが、選択はあなた次第です。
このプログラムは、あなたにとって貴重で正しいものなのです。しかし、そこには批判的なものであっても、受け入れがたい欠点があるものです。
以上、私の評価を述べたので、各自で整理してください。
すでに記述していますが、選択はあなた次第です。
私はあなたを包括的に説得し、批判的でないいくつかの些細な点でのみあなたの正しさを認めました。しかし、もしあなたが感動せず、思いとどまったのなら、私は理解します。コードの作者から直接反論を受け入れるのは難しいのです。
フリーコードを探すといえば
プログラマーの何パーセントが、有益な取引のために、あるいはコードを学ぶためにプログラムを検索しているか、推測してみてください。個人的には、この分野でプログラマーを目指す人は圧倒的に少ないので、前者の方向性が強いと思います。
フリーコードを探すといえば
プログラマーの何パーセントが、有益な取引のために、あるいはコードを学ぶためにプログラムを検索しているか、推測してみてください。個人的には、検索する人の中には、自分がこの分野のプログラマーだと思う人が圧倒的に少ないので、前者の方が優勢だと思います。
要は、そのようなコードは個人のマシンでは使えないということなのですが、あなたはそれを認めていませんね。プログラマーは確かに、コードの中身を見た上で、それを入れることはないでしょう。
また、プリフィクスについても議論を始めたが、私は議論するためにここに来たのではないのだ。
がんばってください。
それは、個人のマシンではそのコードは使えないのに、それを認めなかったということです。
もちろん、そんなことはしていない。なぜなら、これらの欠陥がマシンの速度を低下させるためには、負荷の高い計算、例えば非常に太いループや非常に頻繁な再初期化で使用しなければならないからです。そのような場合には、このコードの採用はお勧めできません。しかし、今回の場合はすべてが空回り。失敗を声高に主張する矛盾は屈辱以外の何物でもない。でも、ありがとうございました。
そして、より悟りを開くために、私は常に自分のコードを改善することに前向きです。