void OnLog(
ushort send_id, // идентификатор запрошенного события // например модификация ордера
ushort rec_id, // идентификатор возвращенного события // например ошибка модификацииlong lparam, // параметр типа long // например тикет ордераstring sparam // сформированная строка на выводсамим тестером
{
/*
здесь можно переопределить выводимую строку в лог журнала Тестера по своему усмотрению
на основании тикета в параметр sparam, и передать её дальше на вывод в базовую функцию
Например, по событию MODIFY_SLTP и возвращенному ответу + известному тикету lparam пользователь сам сможет
сформировать и вывести ту информацию, которая ему больше всего интересна для данного случая
*/return(::OnLog(send_id, rec_id, lparam, sparam)); // вызов базовой функции вывода в журнад тестера
}
エージェントの種類（ローカル/リモート）をプログラムで定義することは可能ですか？
なぜ？
このオプションを使用すると、テスト中のMQLプログラムのログの配布を整理したり、外部DLL モジュールからの関数呼び出しを制限したりするのに便利です。
IMHO もしテスターのコンセプトが、異なるモードで使用できるものであるなら、それに応じて、これらのモードをプログラムで定義する必要性や欲求があるはずです。
1.早期バインディングにより、DLLからインポートされた 関数を使用してリモートエージェントでex5をロードすることができない
2) テストは、ローカルエージェントとリモートエージェントの両方で、まったく同じ方法で行う必要があります。そうでなければ、奇跡的な結果を得ることができるだろう
1.早期バインディングにより、DLLからインポートされた 関数を使用してリモートエージェントでex5をロードすることができない
2) テストは、ローカルエージェントとリモートエージェントの両方で、まったく同じ方法で行う必要があります。そうでなければ、奇跡的な結果を得ることができるだろう
私の実務では、ポジションや注文を開いたり変更したりするときは、常に拡張ログメッセージを使用します。
もちろん、たまたまですが、端末自体もイベントに関する情報を出力しています。しかし、多くの場合、この情報は不要です。
なぜなら、あまりにも多くのメッセージ＋自分自身のメッセージがあり、結果としてログが2倍になるからです。
そのため、テスターメッセージの出力を設定できるようにする要望があります（一部のイベントに対する出力をオフにしたり、ユーザー定義の文字列に置き換えたりすることが可能です）。
とりあえず、テスターで取引イベントの 種類（機能の読み分け）ごとにメッセージ表示を無効化すれば十分だと思います。
これは、異なる取引イベントに対するテスター動作の構造（_TesterInfoタイプ）を作成し、それを埋めることによって行うことができます。
または、その代わりに
私の基準である「Custom max」は（他の多くの人もそうだと思いますが）、いくつかのカスタムインジケーターで構成されているので。
シングルパスモードだけでなく、最適化中にも見たかったものです。
そうすれば、どのパラメータが原因で「カスタム最大値」が増えたのか、ある一節で本当にわかるようになります。
そして、これだけではありません。パラメーターの最適化には、次のような指標を追いかけることが望ましいというのは、多くの人が共感してくれることでしょう。
- ドローダウンの種類
- 損得勘定
- 安定性
- バランス成長線の線形回帰（テーマを 思い出す）
- オープンポジションの時間に対するポイントの比率でトレードの質を判断する基準
等は、それぞれ独自の指標の開発を持っています...
開発者の方にお聞きしたいのですが...。
この便利なオプションが使えるようになる日は来るのでしょうか？
あなたの投稿からはよくわかりませんが、OnTester() 関数についてご存知でしょうか。
私は知っているだけでなく、この革新性が新バージョンのMTの価値全体の半分近くを占めていると考えています。
本題の件、とても興味があります（私だけでなく、多くの人がそうだと思います）...。先ほどの本質を...
教えてください、希望はあるのでしょうか？
不思議なもので、どうしてはっきりしないのでしょう。OnTester()に直結する「custom max」については、冒頭で明示的に記述しています。
私は知っているだけでなく、この革新性が新バージョンのMTの価値全体の半分近くを占めていると考えています。
本題の件、とても興味があります（私だけでなく、多くの人がそうだと思います）...。先ほどの本質を...
教えてください、希望はあるのでしょうか？
そこで、OnTesterに独自のフィットネス関数の計算を実装し、それを使って最適化します。それとも、そういう問題ではないのでしょうか？最適化結果」レポートには、OnTester()の値について別の列があります。
そこで、OnTesterに独自のフィットネス関数を実装し、それによる最適化を行います。それとも、質問はそれについてではないのですか？OnTester()関数の 値については、レポート「最適化結果」に別のカラムが出力されます。
結果とは別に、標準にない有用な指標をたくさん見たかったんです。実際に開発されたものもそうですが、多くの人が持っていると思います。
私の「カスタムマックス」の計算式は、7種類のインジケータ（多くのインジケータと同様）の組み合わせで構成されています。パスごとに "custom max "がどんどん増えていくので、どの指標が改善されているかを確認するためには、最適化を止めて1パスで見るしかない、他に方法がない((
最適化を停止することなく、開発した指標のいずれかを、個別の（有効/無効）カラムで直接表示する可能性を開きます。
すべてのトレーダーがあなたに感謝し、頭を下げることでしょう。余計なお世話と思う人はいないはずです。
教えてください、希望はあるのでしょうか？それとも手間をかけるほどではないのか...。