エラー、バグ、質問 - ページ 1702

[Dmytro Zelenskyy]

なるほど。ありがとうございます。

[Sergei Vladimirov]

Dmytro Zelenskyy:

OK、符号をそのままにdoubleをintに正しく変換する方法（数値は関係ない、制限外ならintに制限する）

ロングに変換する。

[Anton]

fxsaber:
返信後、すぐに閉じてください。

入力パラメータが異なるとはいえ、1つでもコピーが動作している場合に備えて、自分自身（インジケータ）を削除できるようにする必要がありました。そのためには、自分自身のハンドルを知る必要がありました。残念ながら、当時はMQLでは100％不可能だということを知りませんでした。そこで私は、あまりスマートではない仕掛けを試してみることにした。

すべてのハンドルを通しました。チェックする前にインジケータに書いたランダムと一致すれば、自動的にそのハンドルは私のものということになり、必要であれば自分で削除することができるのです。

このような配慮から、このような無害なコードが書かれ、開発者のあいまいな、しかし明らかに否定的な反応を引き起こしたのである。ほら、そんなことできないでしょ。何をしたんですか？さて、CopyBufferを通して自分のバッファの値を読みました。違法なのか!

開発者の対応に「そんなことできないよ」というようなことはありません。どこにも「違法」とは書いていない。

この「無害なコード」が絶対に必要だと思うのであれば、使ってみてください。バッファを読み込んだ後、OnCalculate()にIndicatorRelease(handle))を追加するだけです。自分の」インジケーターであることを1ティックごとに確認する必要はないのですね。

そうすることで、インジケーターが問題を解決し、「見えない存在」であることをやめることができるのです。

#property indicator_separate_window
#property indicator_buffers 1
#property indicator_plots   1

double Buffer[];

int handle=INVALID_HANDLE;
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnInit()
  {
   ::SetIndexBuffer(0,Buffer,INDICATOR_DATA);
   handle=ChartIndicatorGet(0,1,ChartIndicatorName(0,1,0));
  }

#define  TOSTRING(A) #A + " = " + (string)A + "\n"
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
int OnCalculate(const int rates_total,
                const int prev_calculated,
                const datetime &time[],
                const double &open[],
                const double &high[],
                const double &low[],
                const double &close[],
                const long &tick_volume[],
                const long &volume[],
                const int &spread[])
  {
   if(handle!=INVALID_HANDLE)
     {
      Buffer[rates_total-1]=MathRand();

      double BufferCopy[];

      if(CopyBuffer(handle,0,0,1,BufferCopy)>0)
         Print(TOSTRING(BufferCopy[0])+TOSTRING(Buffer[rates_total-1]));
         
      if(IndicatorRelease(handle)) 
         handle=INVALID_HANDLE;
     }

   return(rates_total);
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnDeinit(const int Reason)
  {
   if(handle!=INVALID_HANDLE)
      IndicatorRelease(handle);
   return;
  }

このように、グラフのない端末上でも、バックグラウンドで任意のコードを無制限に実行することが可能であることを、社会に知らしめることができます。ここで少しヒントを。それをバグと考えるかどうかは、用語の問題でしょう。私の理解では、開発者はここで建築的な何かを変えることはできません。だから怒るのです。この反応は、他に説明がつきません。

サービスデスクの対応に「怒り」はない。日頃から問題を誇張する動機に誤解があるようです。

開発者が変えることができるのです。しかし、彼らは通常、非正規の行動であっても、それが明確に有害でない場合は「取り上げ、禁止する」という提案には非常に慎重です。この「ハック」はかなり特殊なものですが、おそらく誰かが使っているのでしょう。

おそらく、これに関する端末の編集はまだ行われるでしょうが、巨大な問題ではなく、この問題の優先順位は最小限であることは確かです。

どうせ誰も声をあげないんだから。こ のようなレーキは、Helpによく反映されるでしょう。

この端末の「重大なバグ」が、自分だけの関心事であることをよく理解していることがわかった。

この際、この問題を解決しよう。技術的な内容はすべて議論されており、一方、感情はこのスレッドには不要です。

[fxsaber]

Anton:

開発者の対応に「それはダメだ」というようなことはない。どこにも「違法」とは書いていない。

もし、この「無害なコード」が自分にとって絶対に必要だと思うのであれば、使ってみてください。バッファを読み込んだ後、OnCalculate()にIndicatorRelease(handle))を追加するだけです。自分の」インジケーターであることを1ティックごとに確認する必要はないのですね。

いや、もちろん、そんな必要はない。

こうして、インジケーターはあなたの問題を解決し、「見えない」存在でなくなるのです。

この件に関して、最近、あなたの同僚から返信がありました。

トレーディング、自動売買システム、ストラテジーテストに関するフォーラム

エラー、バグ、質問

スラワ さん 2016.09.07 17:17

fxsaber

iCustom後のIndicatorReleaseはどうすればいいのか？

何のために？

やめてくれIndicatorCreateの後では、以下のいずれかを行ってはならない。

答えは出ていない。

トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム

バグ、バグ、質問

fxsaber さん 2016.09.07 17:27

Afterはすぐにという意味ではない。しかし、その必要がないのであれば、いつすればいい のでしょうか？

サービスデスクの対応に「怒り」はない。定期的に問題を誇張するのは、あなたのモチベーションに対する誤解があります。

その動機は、純粋に自分勝手なものです。私は、すべてがドキュメントに従って予測通りに動くことを望んでいます。バグは迷惑、それが結果です。

開発者は変わるべき立場にある。しかし、彼らは通常、明らかに有害である場合を除き、非正規の行動であっても「取り上げ、禁止する」という提案には非常に慎重である。この「ハック」はかなり特殊なものですが、おそらく誰かが使っているのでしょう。

これについては、まだ端末の編集があるかもしれませんが、確かに巨大な問題ではなく、この問題の優先順位は最小限です。

優先順位については、私も同感です。

この端末の「重大なバグ」が、自分にとってのみ興味深いものであることを、あなたはよく理解していることがわかった。

このまま質問を終えましょう。すべての技術的な詳細が議論されますが、感情はこのスレッドに不要です。

いや、別の理由でコメントしないのです。どんなに深刻なバグがあったとしても私の「本気」は、ALREADYで作って同じMarketに入れられるバグのことでした。そして、VPSに十分なコンピューティングリソースがないという事実に直面する。とにかく、おわかりいただけたと思います。

[Alexey Navoykov]

Vladimir Pastushak:

そんなことより、これからの生活を楽にするために、いろいろと工夫しているんです。

私はこの方法で問題を解決しました。親はすべてprotecedで、継承はprotecedの下で行われ、次にoverrideです。

親がすべてprotectedなら保護継承の必要はない（publicのままでいい）。 しかし、これでは最初に何をしたかったのかがわからない。 親のメソッドをクラスの内部に隠す必要があるのなら（私が考えていたように外部ではない）、保護と何の関係があるのか。 プリミティブが必要なのだ。

[Sergei Vladimirov]

Alexey Navoykov:
ただ、今となっては、あなたが元々何を望んでいたのかが分からなくなっています。

ポップアップリストで利用できないメソッドを取り除くだけのようです。

[Alexey Navoykov]

Sergei Vladimirov:
ポップアップリストで利用できないメソッドを取り除くだけのように思えるが。

アクセスできないものは出てこないわけですね。

[Vladimir Pastushak]

Sergei Vladimirov:
ポップアップリストの利用できないメソッドを削除すればいいようです。

それだけでなく、グラフィカルなオブジェクトのクラスを自分用に書き直し、オブジェクトのすべてのプロパティが記述された1つのクラスから、今ではボタン型の子孫を簡単かつ分かりやすく（少なくとも私にとっては）作ることができるようになりました。

さらに、これらの単純な要素から、より複雑なものを最小限のエラー確率で、最大限のスピードとシンプルさで構築することができます（少なくとも、私にとってはそうです）。

もしかしたら、標準ライブラリにはすべてが揃っている、と親しみを込めて一蹴されるかもしれませんが、今だから言いますが、すべてではありませんし、理解不能なものばかりです。完全に理解した上で仕事をすることに慣れているので、仕組みを理解するためには自分で全部やってみないと......。

[Sergei Vladimirov]

Alexey Navoykov:
アクセスできないものは出てこないわけですね。

いや、そうなんです。

ちなみに、スタジオでも同じです。

[Alexey Navoykov]

Sergei Vladimirov:

いや、そうなんです。

それなら、Metakvotsはこの点に注意を払うべきです。 なぜアクセスできないメソッドを表示するのか。 結局、保護されたセクションはすべて隠されているのが当然なのですから、ここも同じであるべきなのです。