//Часть твоего кода:
voidOnDeinit(constint reason)
{
if(UninitializeReason() != REASON_CHARTCHANGE) // Что ты здесь сделал? - ЕСЛИ ПРОИСХОДИТ СМЕНА ТФ, ТО НИЧЕГО НЕ ДЕЛАЕМ. Бред!
// И зачем здесь использовать функцию UninitializeReason(), когда можно уже существует переменная reason? {
ObjectDelete(0,"InitDeinit");
ChartRedraw(0); // Не нужная функция в данном случае, т.к. она обычно применяется после изменении свойств объктов. Объект удалится и так.
Print(__FUNCTION__, " InitDeinit удалён"); // А где ж твоя любимая проверка, вдруг не удален.
}
}
作り直した例は、今回の問題に完璧にマッチしていたわけではありません。UninitializeReasonによる解決策を持たない別の例を示すことができます。
以上、この対談を終わります。耳かきの方法を議論することに何の意味があるのでしょうか。他に解決策がなければ、自分のコードを使うこともできますが、普遍性が必ずしも理想的な解決策とは限りません。
例えば、ラズベリーの茂みを1本切り取るのに、伐採作業員を呼ぼうとは誰も思わないでしょう。つまり、あなたのコードは、木こりの隊員がラズベリーの茂みを1本切るのに匹敵するのです。
アレクセイに告ぐ
よくわからないのですが、古いDeInitと新しいOnInitが別々のスレッドで実行される場合、OnInitはDeInitの発生と終了を待つだけで何が問題なんでしょうか。グローバル変 数をセマフォとして使用する。
プリミティブな2ビットの例を使う意味はあるのでしょうか？
代わりに、ほぼ正しいコードの例を使用してください。
アレクセイ、この例はLoserでも理解できるように作ったんだ。だから、プリミティブだと書いたのです。すみません、ストレートAのために設計されたものではありません。
今朝、通り過ぎるトラックに吠える小犬を見ました。彼女は愛を送っています。
アレクセイ、この例は成績の悪い人でもわかるように作ったんだ。だから、プリミティブと書いたのです。すみません、ストレートAのために設計されたものではありません。
今朝、通り過ぎるトラックに吠える犬を見かけました。彼女は愛を送っています。
一緒に吠えていたんですか？
作成前にオブジェクトの存在を確認しない例から、何が理解できるでしょうか。開発者に対するクレームで、重大なエラーで、どのようにでも書けるようにしたわけではない？私は好きなように書くので、開発者はそのための条件をすべて提供してくれなければなりません。開発者は、私が将来犯すかもしれないあらゆる失敗を想定しておかなければならないのです。これで終わり？問題が存在しないところから吸い出してはいけない。
オブジェクトを作成する前にチェックすることがない例から、何が理解できるでしょうか？開発者に対して、「重大なミスがあっても好きなように書けるようにしなかった」というクレーム？
アレクセイ、君は完全に蚊帳の外のようだね。一次資料の 読み込みをお願いします。
以下はその引用です。"オブジェクトが以前に作成されたことがある場合、その座標の変更を試みます。"
大きな作品では、様々な種類のチェックを入れるのが良い形だと理解しています。しかし、この場合、このチェックは意味がありません。なぜなら、オブジェクトがなければObjectCreateが作成し、あれば単にその座標を変更するだけだからです。この非常に原始的な例では、古いTFのDeunitによってオブジェクトを削除する事実を示すことが目的であり、これは完璧に示している。
あなたの "ヒット・アンド・ラン "は何の意味もない。おそらく、自分に注目を集めようとしているのでしょう。
また、指を鍛えるために、何の意味もない余計なコードが欲しいという方には、 「Keyboard Solo」という優れた教材がおすすめです。
一緒に飛び込んだりしましたか？
オブジェクトを作成する前にチェックを行わない例から、どのようなことが理解できるでしょうか。粗悪なミスで好き勝手なことを書けるようにしなかったと開発者にクレーム？私は好きなように書くので、開発者はそのための条件をすべて提供してくれなければなりません。開発者は、私が将来犯すかもしれないあらゆる失敗を想定しておかなければならないのです。これで終わり？問題が存在しないところから吸い出してはいけない。
既存のオブジェクトを作成しようとすると、何がそんなに恐ろしいのでしょうか？消えてしまうのでしょうか？
既存のオブジェクトを作ろうとすると、何がそんなにひどいことになるのでしょうか？消えてしまうのでしょうか？
Dimitri あなたは教養あるプログラマーだと思います。プログラミングのマナーについて教えてもらっていないのですか？
それ以外は、配列の オーバーランなどの可能性を想定して、昔のmql4と同じように書けばよい。応答がエラーになる...じゃあ、フラグを立てて...。続けよう、時間がない...。そして、より厳格な言語ではどうしようもない問題にぶつかり、開発者に文句を言い始める...。
キリストは復活されました。
...この非常に原始的な例の目的は、Deunitが旧TFのオブジェクトを削除した事実を示すことであり、それは完璧に実証されています ...
失敗の事実は、応答例で示されている。問題のないところから吸い出す必要はないのです。初期化解除 の理由を確認すると、オブジェクトは削除されず、座標が変更されるだけです。
私の例は、新TFのUnitと旧TFのUnitの並びが曖昧な場合の問題を示すために作成したもので、解決策ではありません。
問題を解決するのではなく、迂回させただけです。
私の例では、古いTFのユニットでは、TFを変更した場合も含めて、いかなる場合でもオブジェクトを削除し、新しいオブジェクトのユニットでは、再び作成することが重要なだけである。
もし配列が最初に古いTFのDeunit、次に新しいTFのUnitであれば、論理的にそうなるはずです。その後、オブジェクトは削除され、再び作成されます。
もし、シーケンスが最初に新しいTFのUnit、次に古いTFのDeunitであれば、Unitでオブジェクトを作成しようとしても、まだ削除されていないので、単に変更されるだけである。そして、旧TFのDeunitによって削除される。これがバグです。
このブランチを読んでおらず、この「機能」を知らないプログラマが遭遇する可能性があることを示すのが、この例のポイントでした。
この例は、解決策を示すものではありません。解答のバリエーションとして、こちらと こちらが 紹介されています。また、後で解決策を追加すると思いますが、ターミナルのグローバル変数やファイルを使用せず、1つのウィンドウに複数の同一のインジケータを設定しても、この解決策が機能するようにすることです。この問題を解決しようとしましたか？あるいは、特に他人のコードの誤りを見つける能力しかないのか。