Язык программирования MQL5 позволяет решать задачи на совершенно новом уровне. Даже те задачи, которые уже вроде имеют решения, благодаря объектно-ориентированному программированию могут подняться на качественно новый уровень. В данной статье специально взят простой пример проверки появления нового бара на графике, который был преобразован в достаточно мощный и универсальный инструмент. Какой? Читайте в статье.
オブジェクトの種類が増えれば増えるほど、このような機能の必要性は高まります。そして、アンカーポイントの数が種類によって決められないようなオブジェクトを作るときに必要になってくるでしょう。例えば、ある種のポリラインであってもよい。しかし、今のところあまり重要ではありませんが、サービスデスクでの希望として実行することができます。
今のところ、（必要であれば）オブジェクトタイプ別にアンカーポイントの数を出すスイッチ関数を作るのがベストです。
このテーブル（MQL5 Reference / Standard constants, enumerations and structures /Object constants/ Object types）をswitchで作成するだけです。この関数の入力パラメータは ObjectGetInteger(chart_id,name,OBJPROP_TYPE) となります。
すべてのタイプがアンカーポイントに強固に固定されているため、隠れた危険はありません。しかし、点数が変化するオブジェクトが出現した場合、このような機能が切実に必要になります。
さて、最も現実的な方法は（必要であれば）、オブジェクトの種類に応じて アンカーポイントの数を出すスイッチ関数を作成することです。
昔、ObjectGetにプロパティを求めたことがあります。
これは、MT5の内部にあるロジックそのものに関係しているような気がします。
おそらく、すべてのポイントを調べて、EMPTYであるかどうかをチェックしているのでしょう。そして、ポイントに通常の桁があれば、ビルドします。
つまり、オブジェクトの種類とアンカーポイントの数には直接的な関係はないのです。
だから、「自分で切り替えなければならない」と正しく指摘したのですね。
さて、最も現実的な方法は（必要であれば）、オブジェクトの種類に応じてアンカーポイントの数を出すスイッチ関数を作成することです。
このテーブル（MQL5 Reference / Standard constants, enumerations and structures / Object constants / Object types）をswitchで作成するだけです。この関数の入力パラメータは ObjectGetInteger(chart_id,name,OBJPROP_TYPE) となります。
すべてのタイプがアンカーポイントに強固に固定されているため、隠れた危険はありません。しかし、ポイント数が可変の新しいオブジェクトを入手した場合、この機能が本当に必要になります。
昔、ObjectGetにプロパティを求めたことがあります。
もし、点数が変化するオブジェクトがあるならば、このような機能は非常に必要です。
おそらく、すべてのポイントを調べて、EMPTYであるかどうかをチェックしているのでしょう。そして、ポイントに通常の桁があれば、ビルドします。
つまり、オブジェクトの種類とアンカーポイントの数には直接的な関係はないのです。
ポイント数が変動するような場合は、このような機能が非常に必要になります。
はい、上に書いたように、スイッチ経由で実装しています。特に問題なく動作しています。しかし、その考えはさらに進んで、もっと便利で普遍的なものが欲しいのです。
ちなみに、ユーザーが自分でオブジェクトを作れるようにするのもいいと思います。例えば、標準的なオブジェクトを共通の「ブランド」を持つグループに統合することくらいは可能でしょう。そうすれば、複数のオブジェクトを1つのグループとして参照することが可能になります。それから、ポリライン、リング、トーラスなどのトリッキーなオブジェクトもありますね。といった具合に。また、ある操作パネルのオブジェクトでさえも、統合することができました。また、Ctrl-Bでは、オブジェクトのシートではなく、オブジェクトグループの名前などがきちんと表示されます。また、OnChartEven()ハンドラで変更されたオブジェクトから100000イベントを取得する問題も解決されます。なぜなら、これらの100000オブジェクトはグループにマージされ、1つのCHARTEVENT_OBJECT_CHANGE イベントのみを受信することができるからです。すべてにおいて、美しいものになるでしょう。もちろん、クラスによって部分的に実装することは可能ですが、全部は無理です。
Lizar:
Ctrl-Bは、オブジェクトのシートではなく、オブジェクトのグループの名前をきちんと表示するとか..........................。
......これらの 100000 オブジェクトはグループにまとめられ、1 つのCHARTEVENT_OBJECT_CHANGE イベントを受信することができます。すべてにおいて、美しい......。
夢は捨てろ、期待するな。
:)
複数の商品のローソク足を一度に表示するインジケータを作成しています。起動後、新しいバーが 表示される前に、すべてが正しく表示されます。
しかし、新しいバーが出現してからは、変化が見られます。
また、ChartRedrawは役に立ちません。でも、右のボタン「リフレッシュ」を押せば、すべて揃うんですけどね。ズレを防止する方法を教えてください。
double price; はMqlTradeRequestで 自動的に正規化されるのでしょうか？ (ありえませんが)そうでないとしたら、なぜ標準ライブラリ ではまだ正規化されていないのでしょうか？(9ヶ月前にこの問題を提起した）。
標準ライブラリの編集だけで事なきを得ましたが、そうでないことはご存知の通りです（バージョンアップ時に破られる）。
もし私が間違っているとしたら、どのような点を指摘すればよいのでしょうか？
恣意性を問われないよう、トレーダーの価格を変更することは許されないため、自動的に正規化することはしていません。
計算された価格を使用する場合は、自分で価格を正規化する必要があります。Bid/Ask 価格が正味で変化しない注文の場合、正規化は必要ない。
恣意性を問われないよう、トレーダーの価格を変更することは許されないため、自動的に正規化することはしていません。
計算された価格を使用する場合は、自分で価格を正規化する必要があります。Bid/Ask 価格が正味で変化しない注文の場合、正規化は必要ない。
ありがとうございます、欲しいものが見つかりました。4ではbid/askさえも正規化する必要があった。
実は、MT4では、BidとAskを正規化する必要はありません。デフォルトで常に正規化されています。
手元に例があるのなら、ぜひ見せてほしい。
実は、MT4では、BidとAskを正規化する必要はありません。デフォルトで常に正規化されています。
手元に例があれば、ぜひ見せてください。