エラー、バグ、質問 - ページ 3121 1...311431153116311731183119312031213122312331243125312631273128...3185 新しいコメント Alexey Viktorov 2021.12.18 06:10 #31201 x572intraday #: 知っている人は教えてください。既存のコードの新バージョンをCodeBaseに アップロードした場合、以前の開発者は再投票の禁止がリセットされ、新バージョンに再び投票できるようになるのでしょうか?私自身は非常に疑問ですが、もしそれが可能なら、新しい評価（仮に以前の評価より低くならないことになっている）の代わりに以前の評価をリセットするのが公平でしょう。なぜなら、コードは発展途上で、新しいバージョンは投票者をより満足させるかもしれませんが、古いコードに対する古い評価は無効になる可能性があるからです。(確かに、機能が大きくなるとコードも大きくなるので、新たなバグや不具合が出て、さらに面倒なことになるかもしれません）。何が起こるかわからない...と新しいスコアが低くなるかもしれないが、それはそれで構わない）。 あなたの...コードの低評価に髪を引き裂くのはやめてください。もし、ある人があなたのコードに1点をつけたとしても、それが何であるかということではありません。まあ、少なくとも100回は書き直してください...100回ともこのコードはそのように評価されるでしょう。そんなに難しいことなんですか？ x572intraday 2021.12.18 10:25 #31202 Alexey Viktorov #:あなたの...コードの低評価に髪を引き裂くのはやめてください。もし、ある人があなたのコードに1点をつけたとしても、それが何であるかということではありません。まあ、最低100回はやり直してください...100回ともこのコードはこの評価です。そんなに難しいことなんですか？ おそらく、あなたの履歴書は投票の現実を反映しており、それは悲しいことです。でも、自分が悲しいのではなく、その仮想の星はお茶で飲めないし、財布にも入れられない、新しいユーザーに心配をかけながら、商品の見せ方のコンセプトにがっかりしているのです。信頼できる評価/格付けがない場合、ユーザーは「評価で並べ替え」という基準で欲しい製品を効果的に検索することができません。評価システムが空虚なシステムであることが判明し、人は役に立たない星の数を信用するのではなく、名前/説明で正しい製品を探すことになるのです。そうでないと、どんどんネタが釣られてしまうので...。表面上のこと（当然かどうかは別として）、本当に必要なことは見落とされる。これをもっと配慮したものに変えてはどうかと提案しただけです。でも、誰もその現実と戦おうとしないのであれば、私は手を洗います。 Vitaly Muzichenko 2021.12.18 11:40 #31203 x572intraday #:あなたのまとめは投票の実態を反映しているのでしょうが、残念なことです。しかし、私が悲しいのは私ではなく、そのバーチャルスターがお茶で飲めず、財布に入れられないことです。私は、新しいユーザーに対して正確に心配しながら、製品の見せ方のコンセプトに失望しているのです。信頼できる評価/格付けがない場合、ユーザーは「評価で並べ替え」の基準で欲しい製品を効果的に検索することができません。評価システムが空虚なシステムであることが判明し、人は役に立たない星の数を信用するのではなく、名前/説明で正しい製品を探すことになるのです。そうでないと、どんどんネタが釣られてしまうので...。表面上のこと（当然かどうかは別として）、本当に必要なことは見落とされる。これをもっと配慮したものに変えてはどうかと提案しただけです。でも、誰もその現実と戦おうとしないのであれば、私は手を洗います。 あなたのコードを見てみましょう。 int calculated=iBars(_Symbol,PArray[0]); if(calculated<=0) return(0); if(!GlobalVariableGet(_Symbol+": PSR_bars_calculated") || calculated!=GlobalVariableGet(_Symbol+": PSR_bars_calculated") || calculated>GlobalVariableGet(_Symbol+": PSR_bars_calculated")+1) { if(!GlobalVariableGet(_Symbol+": PSR_SingleActuation") || (GlobalVariableGet(_Symbol+": PSR_SingleActuation") && calculated!=GlobalVariableGet(_Symbol+": PSR_bars_calculated"))) { for(int p=0; p<ArraySize(PArray); p++) { 各ティックはグローバル変数にアクセスするトリガーとなり、一度に4つのリクエストが可能です。 このことから、このコードは個人のマシンでは使用できず、ハードディスクを必要としない他の場所で使用することができます。 検索中に1つのループで3回ArraySizeを 呼び出す必要があり、それらの2つがある一方で、これはプロセッサに追加の負荷であり、これはまた、コードのパフォーマンスが低下し、望ましく ありません。 DeIniteは変な方法でオブジェクトを削除する、ここは何も問題ないが、初心者には悪い例だ、普通にやるなら、オブジェクト作成時にプレフィックスを入力し、過剰な再計算をせずに削除 するのが良いだろう。 私はあなたのコードに2点を与えます。 インジケーターの仕事については......実行したことがないのでわかりません。 目的？ x572intraday 2021.12.18 12:49 #31204 Vitaly Muzichenko #:では、あなたのコードを見てみましょう。ティック毎にグローバル変数へのアクセスが発生し、一度に4つのリクエストが発生します。このことから、このコードは個人のマシンでは使用できず、ハードディスクを必要としない他の場所で使用することができます。検索中に1つのループで3回ArraySizeを 呼び出す必要があり、それらの2つがある一方で、これはプロセッサに追加の負荷であり、これはまた、コードのパフォーマンスが低下し、望ましく ありません。DeIniteは変な方法でオブジェクトを削除する、ここは何も問題ないが、初心者には悪い例だ、普通にやるなら、オブジェクト作成時にプレフィックスを入力し、過剰な再計算をせずに削除 するのが良いだろう。 私はあなたのコードに2点を与えます。インジケーターの仕事については......走ったことがないのでわかりません。目的？ 1.ティック毎にGPが呼び出されるため、ティック毎、また再初期化（例えばTFの遷移）毎にOnCalculate() のメインコードや重いコードが実行されず、インジケータが高速に動作するようになるのです。新しいデータの計算 - 各ティックよりも、はるかにまれである新しい低バーD 1の外観を持つだけです。 2.徹底的に考え抜いたコードですが、パフォーマンスに影響がないことが確実なので、不要な比較演算をif() に残しています。 3.MUST not beについては、大きく誇張されています。ダウンロードして、ご自分の目で確かめてください。インジケーターが飛ぶんです。 4.GPがAFにダウンロードされ、実行中のMT5 セッションでアクセスするたびに同じ場所から読み込まれるとは知りませんでした。やはり端末を起動した時に一度液晶からRAMに読み込まれ、そこで生きているのだと思いますし、インジケータは液晶にではなくRAMにアクセスするのだと思います。 5.ArraySize() は高価な関数ではないと思います。また、たとえ高価なものであっても、この特別なコードでは気づかないでしょう。私はおそらく、この関数が頻繁に使用される最初のインジケータで最適化し、一方、インジケータ自体ははるかに複雑で、リソースを大量に消費することになるでしょう。 6.OnDeinit() の中で、私は使っています。 ObjectsDeleteAll(0,StringSubstr(EnumToString(PArray[p]),7)+" "+line_types[lt]+" l",0,-1); ここで、" l "という接頭語によって、そこだけ削除されています（オブジェクトの作成時に "label"と "line"という名前が使われています）。 7.これで、コードをダウンロードして理解したユーザーが行うべきことができました。欠点が見つかったということですが、これもMQLを 学ぶ上での一部です。 8.結論：1.) このインジケータの非理想的なコードの私の主な議論 - シンプルさ、コンパクトさ、スピード...2.) 私の不完全なコードの第二の主な議論 - 速度と汎用性の点で悪い類似品さえない（他の人のオリジナルの議論を参照）、オリジナルと比較して改善の利用可能性、ところで、狭いので、多数の同様の繰り返しブロックの観点からコンパクトなループに折り畳まれていないです。 9.ポイント7にもかかわらず、他人のコードをよく理解していなかったんですね。スコアが2というのは低すぎる。私は、ソフトウェア製品をコードで評価することは、まだお勧めしません。客観性については、一人のユーザーに客観性を求めるのは無理なので、何も言いません。客観的な推定値（レーティング）は、複数のまともなユーザーの推定値の合計としてのみ可能であり、必ずしも高くなくてもよいことは確かである。 Need an advice How to select by ArrayBSearch help... Vitaly Muzichenko 2021.12.18 13:26 #31205 x572intraday #:1.ティックごとにGPへの参照があるため、ティックごと、また再初期化（例えばTFの遷移など）ごとにOnCalculate() のメインコードや重いコード全体が実行されず、インディケータが速く動作する。新しいデータの計算 - 各ティックよりも、はるかにまれな新しい安値バーD 1の出現時のみ。2.徹底的に考え抜いたコードですが、パフォーマンスに影響がないことが確実なので、if()の 中に冗長な比較演算を残しています。3.MUSTについて - 大いに誇張されている。ダウンロードして、インジケーターが飛ぶことをご自分の目で確かめてください。4.GPがHDDにダンプされ、実行中のMT5 セッション内でアクセスされるたびにそこから読み出されるとは知りませんでした。やはり、ターミナルを起動した時に一度HDからRAMに読み込まれてそこに住み、インジケータはHDにではなくRAMにアクセスするのだと思います。5.ArraySize() は高価な関数ではないと思います。また、たとえ高価なものであっても、この特別なコードでは気づかないでしょう。私はおそらく、この関数がかなり頻繁に使用される最初のインジケータで最適化し、一方でインジケータ自体ははるかに複雑でリソース集約的なものにすると思います。6.OnDeinit() の中で、私は使っています。ここで、" l "という接頭語によって、そこだけ削除されています（オブジェクトの作成時に "label"と "line"という名前が使われています）。7.これで、コードをダウンロードして理解したユーザーが行うべきことができました。欠点が見つかったということですが、これもMQLを 学ぶ上での一部です。8.結論：1.) このインジケータの非理想的なコードの私の主な議論 - シンプルさ、コンパクトさ、スピード...2.) 私の不完全なコードの第二の主な議論 - 速度と汎用性の点で類似のものがないこと（他の誰かのオリジナルの議論を参照）、オリジナルと比較して改良が可能であること、ちなみに、狭いので、多数の同様の繰り返しブロックの点でコンパクトループに折り畳まれていないこと。9.ポイント7にもかかわらず、他人のコードをよく理解していなかったんですね。スコアが2というのは低すぎる。私は、ソフトウェア製品をコードで評価することは、まだお勧めしません。客観性については、一人のユーザーに客観性を求めるのは無理なので、何も言いません。客観的な推定値（レーティング）は、一部のまともなユーザーの推定値の合計としてのみ可能であり、必ずしも高いものである必要はないのです。 接頭辞による削除は以下のようになります。 ObjectsDeleteAll(0, "pref_"); //"pref_label" および "pref_line" OnCalculateに少なくとも最初の行を追加し、現在のように毎ティックではなく、新しいバーでアドレス指定するようにしました。 x572intraday 2021.12.18 13:35 #31206 Vitaly Muzichenko #:接頭辞による削除は、以下のようになります。 ObjectsDeleteAll(0, "pref_"); //"pref_label" および "pref_line" OnCalculateに少なくとも最初の行を追加し、現在のようにティック毎ではなく、新しいバーで参照されるようにします。 ところで、7についてですが、MQL5の ドキュメントでも、何年も修正されないエラーに遭遇したことがあります。 x572intraday 2021.12.18 13:49 #31207 Vitaly Muzichenko #:接頭辞による削除は次のようになります： ObjectsDeleteAll(0, "pref_"); //"pref_label" および "pref_line" D1 }、{W1}、{MN1}の いずれかが先頭にあり、その後に「l...」のような不変の接頭辞 が来るので、あなたの言うように削除するのは妥当ではありません。動的接頭辞と静的接頭辞を入れ替えて、バージョンに応じて安全に削除することができます。 しかし、「{D1} R1」とした方が便利な情報を「R1{D1}」と 取るのは不便であり、合理的 ではありません。昔、考え抜いた結果、そのとおりにしたんです。 Vitaly Muzichenko 2021.12.18 14:01 #31208 x572intraday #:接頭辞の先頭は{D1}か {W1}か{MN1}のいずれかであり、さらに「l...」のように変更できない接頭辞 があるため、ご提案の方法で削除するのは賢明な方法ではありません。動的接頭辞と静的接頭辞を入れ替えて、バージョンに応じて安全に削除することができます。 しかし、「{D1} R1」とした方が便利な情報を「R1{D1}」と 取るのは不便なので、合理的 ではありません。昔、考え抜いた結果、そのとおりにしたんです。 DrawTheLine("pref"+line_types[lt], St x572intraday 2021.12.18 14:57 #31209 Vitaly Muzichenko #: それでも、そう、原理的にはできるんです。について、当時考えながら、颯爽と上記のように説明しました。ObjectSetString(0,tf+" "+LineType+" label",OBJPROP_TEXT,"{"+tf+"} "+LineType);オブジェクト名のことではありません。チャートはラベルにOBJPROP_TEXTで 設定されたものをそのまま読みますが、オブジェクト名は隠れていてほとんど読まれないので、あまり読まれない方法で署名 することができます。一方、"オブジェクトのリスト "では(Ctrl+b)の方が、オブジェクト名が読みやすいので、私のやり方の方が好ましいと思います。また、オブジェクト名を極端に長くする必要がある場合もあるので、余計なpref_は全く許容さ れない。 Vitaly Muzichenko 2021.12.18 15:40 #31210 x572intraday #:それでも、そう、原理的にはできるんです。について、当時考えながら、颯爽と上記のように説明しました。オブジェクト名のことではありません。チャートはラベルにOBJPROP_TEXTで 設定されたものを正確に読み取りますが、オブジェクト名は隠れていてほとんど読まれないので、あまり読み取れない符号が 付くことがあります。一方、"オブジェクトのリスト "では(Ctrl+b)で読めるオブジェクト名が表示されることが望ましいので、やはり私のバージョンが望ましいと思います。さ らに、オブジェクト名が極端に長くなる場合もあるので、余計なpref_は全く許容さ れない。 そして、誰かがまだグラフィカルなオブジェクトを持つプログラムを持っている場合は、プレフィックス "l" <ここでちょうどプレフィックス "l" （名前 "ラベル" と "ライン" は、オブジェクトが作成されたときに使用されていた>で削除されます。 サードパーティ製プログラム内の "l " で始まるすべてのオブジェクトを消去します。これは良い解決策ではありません 1...311431153116311731183119312031213122312331243125312631273128...3185 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
知っている人は教えてください。既存のコードの新バージョンをCodeBaseに アップロードした場合、以前の開発者は再投票の禁止がリセットされ、新バージョンに再び投票できるようになるのでしょうか?私自身は非常に疑問ですが、もしそれが可能なら、新しい評価（仮に以前の評価より低くならないことになっている）の代わりに以前の評価をリセットするのが公平でしょう。なぜなら、コードは発展途上で、新しいバージョンは投票者をより満足させるかもしれませんが、古いコードに対する古い評価は無効になる可能性があるからです。(確かに、機能が大きくなるとコードも大きくなるので、新たなバグや不具合が出て、さらに面倒なことになるかもしれません）。何が起こるかわからない...と新しいスコアが低くなるかもしれないが、それはそれで構わない）。
あなたの...コードの低評価に髪を引き裂くのはやめてください。もし、ある人があなたのコードに1点をつけたとしても、それが何であるかということではありません。まあ、少なくとも100回は書き直してください...100回ともこのコードはそのように評価されるでしょう。そんなに難しいことなんですか？
あなたの...コードの低評価に髪を引き裂くのはやめてください。もし、ある人があなたのコードに1点をつけたとしても、それが何であるかということではありません。まあ、最低100回はやり直してください...100回ともこのコードはこの評価です。そんなに難しいことなんですか？
おそらく、あなたの履歴書は投票の現実を反映しており、それは悲しいことです。でも、自分が悲しいのではなく、その仮想の星はお茶で飲めないし、財布にも入れられない、新しいユーザーに心配をかけながら、商品の見せ方のコンセプトにがっかりしているのです。信頼できる評価/格付けがない場合、ユーザーは「評価で並べ替え」という基準で欲しい製品を効果的に検索することができません。評価システムが空虚なシステムであることが判明し、人は役に立たない星の数を信用するのではなく、名前/説明で正しい製品を探すことになるのです。そうでないと、どんどんネタが釣られてしまうので...。表面上のこと（当然かどうかは別として）、本当に必要なことは見落とされる。これをもっと配慮したものに変えてはどうかと提案しただけです。でも、誰もその現実と戦おうとしないのであれば、私は手を洗います。
あなたのまとめは投票の実態を反映しているのでしょうが、残念なことです。しかし、私が悲しいのは私ではなく、そのバーチャルスターがお茶で飲めず、財布に入れられないことです。私は、新しいユーザーに対して正確に心配しながら、製品の見せ方のコンセプトに失望しているのです。信頼できる評価/格付けがない場合、ユーザーは「評価で並べ替え」の基準で欲しい製品を効果的に検索することができません。評価システムが空虚なシステムであることが判明し、人は役に立たない星の数を信用するのではなく、名前/説明で正しい製品を探すことになるのです。そうでないと、どんどんネタが釣られてしまうので...。表面上のこと（当然かどうかは別として）、本当に必要なことは見落とされる。これをもっと配慮したものに変えてはどうかと提案しただけです。でも、誰もその現実と戦おうとしないのであれば、私は手を洗います。
あなたのコードを見てみましょう。
各ティックはグローバル変数にアクセスするトリガーとなり、一度に4つのリクエストが可能です。
このことから、このコードは個人のマシンでは使用できず、ハードディスクを必要としない他の場所で使用することができます。
検索中に1つのループで3回ArraySizeを 呼び出す必要があり、それらの2つがある一方で、これはプロセッサに追加の負荷であり、これはまた、コードのパフォーマンスが低下し、望ましく ありません。
DeIniteは変な方法でオブジェクトを削除する、ここは何も問題ないが、初心者には悪い例だ、普通にやるなら、オブジェクト作成時にプレフィックスを入力し、過剰な再計算をせずに削除 するのが良いだろう。
私はあなたのコードに2点を与えます。
インジケーターの仕事については......実行したことがないのでわかりません。
目的？
では、あなたのコードを見てみましょう。
ティック毎にグローバル変数へのアクセスが発生し、一度に4つのリクエストが発生します。
このことから、このコードは個人のマシンでは使用できず、ハードディスクを必要としない他の場所で使用することができます。
検索中に1つのループで3回ArraySizeを 呼び出す必要があり、それらの2つがある一方で、これはプロセッサに追加の負荷であり、これはまた、コードのパフォーマンスが低下し、望ましく ありません。
DeIniteは変な方法でオブジェクトを削除する、ここは何も問題ないが、初心者には悪い例だ、普通にやるなら、オブジェクト作成時にプレフィックスを入力し、過剰な再計算をせずに削除 するのが良いだろう。
私はあなたのコードに2点を与えます。
インジケーターの仕事については......走ったことがないのでわかりません。
目的？
1.ティック毎にGPが呼び出されるため、ティック毎、また再初期化（例えばTFの遷移）毎にOnCalculate() のメインコードや重いコードが実行されず、インジケータが高速に動作するようになるのです。新しいデータの計算 - 各ティックよりも、はるかにまれである新しい低バーD 1の外観を持つだけです。
2.徹底的に考え抜いたコードですが、パフォーマンスに影響がないことが確実なので、不要な比較演算をif() に残しています。
3.MUST not beについては、大きく誇張されています。ダウンロードして、ご自分の目で確かめてください。インジケーターが飛ぶんです。
4.GPがAFにダウンロードされ、実行中のMT5 セッションでアクセスするたびに同じ場所から読み込まれるとは知りませんでした。やはり端末を起動した時に一度液晶からRAMに読み込まれ、そこで生きているのだと思いますし、インジケータは液晶にではなくRAMにアクセスするのだと思います。
5.ArraySize() は高価な関数ではないと思います。また、たとえ高価なものであっても、この特別なコードでは気づかないでしょう。私はおそらく、この関数が頻繁に使用される最初のインジケータで最適化し、一方、インジケータ自体ははるかに複雑で、リソースを大量に消費することになるでしょう。
6.OnDeinit() の中で、私は使っています。
ここで、" l "という接頭語によって、そこだけ削除されています（オブジェクトの作成時に "label"と "line"という名前が使われています）。
7.これで、コードをダウンロードして理解したユーザーが行うべきことができました。欠点が見つかったということですが、これもMQLを 学ぶ上での一部です。
8.結論：1.) このインジケータの非理想的なコードの私の主な議論 - シンプルさ、コンパクトさ、スピード...2.) 私の不完全なコードの第二の主な議論 - 速度と汎用性の点で悪い類似品さえない（他の人のオリジナルの議論を参照）、オリジナルと比較して改善の利用可能性、ところで、狭いので、多数の同様の繰り返しブロックの観点からコンパクトなループに折り畳まれていないです。
9.ポイント7にもかかわらず、他人のコードをよく理解していなかったんですね。スコアが2というのは低すぎる。私は、ソフトウェア製品をコードで評価することは、まだお勧めしません。客観性については、一人のユーザーに客観性を求めるのは無理なので、何も言いません。客観的な推定値（レーティング）は、複数のまともなユーザーの推定値の合計としてのみ可能であり、必ずしも高くなくてもよいことは確かである。
1.ティックごとにGPへの参照があるため、ティックごと、また再初期化（例えばTFの遷移など）ごとにOnCalculate() のメインコードや重いコード全体が実行されず、インディケータが速く動作する。新しいデータの計算 - 各ティックよりも、はるかにまれな新しい安値バーD 1の出現時のみ。
2.徹底的に考え抜いたコードですが、パフォーマンスに影響がないことが確実なので、if()の 中に冗長な比較演算を残しています。
3.MUSTについて - 大いに誇張されている。ダウンロードして、インジケーターが飛ぶことをご自分の目で確かめてください。
4.GPがHDDにダンプされ、実行中のMT5 セッション内でアクセスされるたびにそこから読み出されるとは知りませんでした。やはり、ターミナルを起動した時に一度HDからRAMに読み込まれてそこに住み、インジケータはHDにではなくRAMにアクセスするのだと思います。
5.ArraySize() は高価な関数ではないと思います。また、たとえ高価なものであっても、この特別なコードでは気づかないでしょう。私はおそらく、この関数がかなり頻繁に使用される最初のインジケータで最適化し、一方でインジケータ自体ははるかに複雑でリソース集約的なものにすると思います。
6.OnDeinit() の中で、私は使っています。
ここで、" l "という接頭語によって、そこだけ削除されています（オブジェクトの作成時に "label"と "line"という名前が使われています）。
7.これで、コードをダウンロードして理解したユーザーが行うべきことができました。欠点が見つかったということですが、これもMQLを 学ぶ上での一部です。
8.結論：1.) このインジケータの非理想的なコードの私の主な議論 - シンプルさ、コンパクトさ、スピード...2.) 私の不完全なコードの第二の主な議論 - 速度と汎用性の点で類似のものがないこと（他の誰かのオリジナルの議論を参照）、オリジナルと比較して改良が可能であること、ちなみに、狭いので、多数の同様の繰り返しブロックの点でコンパクトループに折り畳まれていないこと。
9.ポイント7にもかかわらず、他人のコードをよく理解していなかったんですね。スコアが2というのは低すぎる。私は、ソフトウェア製品をコードで評価することは、まだお勧めしません。客観性については、一人のユーザーに客観性を求めるのは無理なので、何も言いません。客観的な推定値（レーティング）は、一部のまともなユーザーの推定値の合計としてのみ可能であり、必ずしも高いものである必要はないのです。
接頭辞による削除は以下のようになります。 ObjectsDeleteAll(0, "pref_"); //"pref_label" および "pref_line"
OnCalculateに少なくとも最初の行を追加し、現在のように毎ティックではなく、新しいバーでアドレス指定するようにしました。
接頭辞による削除は、以下のようになります。 ObjectsDeleteAll(0, "pref_"); //"pref_label" および "pref_line"
OnCalculateに少なくとも最初の行を追加し、現在のようにティック毎ではなく、新しいバーで参照されるようにします。
ところで、7についてですが、MQL5の ドキュメントでも、何年も修正されないエラーに遭遇したことがあります。
接頭辞による削除は次のようになります： ObjectsDeleteAll(0, "pref_"); //"pref_label" および "pref_line"
D1 }、{W1}、{MN1}の いずれかが先頭にあり、その後に「l...」のような不変の接頭辞 が来るので、あなたの言うように削除するのは妥当ではありません。動的接頭辞と静的接頭辞を入れ替えて、バージョンに応じて安全に削除することができます。 しかし、「{D1} R1」とした方が便利な情報を「R1{D1}」と 取るのは不便であり、合理的 ではありません。昔、考え抜いた結果、そのとおりにしたんです。
接頭辞の先頭は{D1}か {W1}か{MN1}のいずれかであり、さらに「l...」のように変更できない接頭辞 があるため、ご提案の方法で削除するのは賢明な方法ではありません。動的接頭辞と静的接頭辞を入れ替えて、バージョンに応じて安全に削除することができます。 しかし、「{D1} R1」とした方が便利な情報を「R1{D1}」と 取るのは不便なので、合理的 ではありません。昔、考え抜いた結果、そのとおりにしたんです。
DrawTheLine("pref"+line_types[lt], Stそれでも、そう、原理的にはできるんです。について、当時考えながら、颯爽と上記のように説明しました。
オブジェクト名のことではありません。チャートはラベルにOBJPROP_TEXTで 設定されたものをそのまま読みますが、オブジェクト名は隠れていてほとんど読まれないので、あまり読まれない方法で署名 することができます。
一方、"オブジェクトのリスト "では(Ctrl+b)の方が、オブジェクト名が読みやすいので、私のやり方の方が好ましいと思います。また、オブジェクト名を極端に長くする必要がある場合もあるので、余計なpref_は全く許容さ れない。それでも、そう、原理的にはできるんです。について、当時考えながら、颯爽と上記のように説明しました。
オブジェクト名のことではありません。チャートはラベルにOBJPROP_TEXTで 設定されたものを正確に読み取りますが、オブジェクト名は隠れていてほとんど読まれないので、あまり読み取れない符号が 付くことがあります。
一方、"オブジェクトのリスト "では(Ctrl+b)で読めるオブジェクト名が表示されることが望ましいので、やはり私のバージョンが望ましいと思います。さ らに、オブジェクト名が極端に長くなる場合もあるので、余計なpref_は全く許容さ れない。そして、誰かがまだグラフィカルなオブジェクトを持つプログラムを持っている場合は、プレフィックス "l" <ここでちょうどプレフィックス "l" （名前 "ラベル" と "ライン" は、オブジェクトが作成されたときに使用されていた>で削除されます。
サードパーティ製プログラム内の "l " で始まるすべてのオブジェクトを消去します。これは良い解決策ではありません