MQL5への願い - ページ 49 1...424344454647484950515253545556...131 新しいコメント toxa 2008.08.04 14:34 #481 もうひとつ。 PsPadのようなMetaEditorのアドオンを書く能力を与える。 など、素敵なものを追加してください。 1.ペアブラケットに下線を 引く!!!! 2. ペアブラケットを勝手に追加してくれるスクリプト。 3.必要な機能にすぐにジャンプできるようなファイルツリーを作ってください。 4.キルCtrl+F2、やってくれ!!!!Ctrl+1, Ctrl+2, .... toxa 2008.08.04 14:38 #482 ペアブラケットがない場合、コンパイラはしばしばファイルの終わりを 表示します!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! で、1000行を検索する :) toxa 2008.08.04 14:40 #483 お前らは言語のプロなのか？フレームワークはどこだ！！！！！！！！！！！！！！！！！！！！！！！！至急とても速いはずなんです。 toxa 2008.08.04 15:32 #484 そうそう、今思い出したけど、トレーリングストップを設定する関数をAPIで直接作れ!!!!(頭痛が減る!!!) Valery V. Chesnokov 2008.08.04 15:49 #485 Toxa писал (а)>> そうだ、そうだ、トレーリングストップを設定する関数をAPIで作ればいいんだ！」。(>> 頭痛が減る!!!) どのようなトレーリングですか？;) Trailingのための関数とExpert Advisorのライブラリ / Yury Dzyuban」の 記事で、そのうちの11個について説明しています。このロジックは応用レイヤーに属し、つまり各関係者が独自に作成するものです。 MQL-editorのプラグイン技術があると便利です。このページで紹介したこと（ペアブラケット、コードテンプレートのオートコンプリート、変数が使われていることのチェックなど）は、Microsoft Visual Studio 2008 / 2005環境では、Visual StudioExtensions 技術をベースにしたサードパーティ開発会社JetBrains Resharperで簡単に実装することが可能です。 Сергей Ковалев 2008.08.05 12:05 #486 chv писал (а)>> どのようなトレーリングですか？;) Trailingのための関数とExpert Advisorのライブラリ / Yury Dzyuban」の 記事で、そのうちの11個について説明しています。このロジックは応用レイヤーに属し、つまり各関係者が独自に作成するものです。 私もそう思います。 その思いはすでに表明しています。言語開発者がある特定の機能を書くことは問題ないと思います。特定のアルゴリズムに縛られることは、ひとつの傾向、ドグマを生み出すことになるからです。取引アルゴリズムのプログラミングは、あくまでもプログラマー（取引戦略の開発者）の仕事です。 もうひとつは、純粋に技術的、サービス的な機能だけでなく、その作成に困難が伴うような機能のライブラリーが必要なことです。例えば、サーバから返されるエラー処理用の関数をプログラミングする場合、プログラマは、あるエラーに対するExpert Advisorの反応を常に正しく理解することはできません（リクエストが多すぎる、ブローカが忙しい、など）。 Сергей Ковалев 2008.08.05 14:03 #487 個人的な意見ですが、一部のオブジェクトにプロパティを追加すると非常に便利だと思います。 例えば、チャンネルの長さを決めるバーの数。 チャネルとの連携が難しい。 H1のチャンネル長を24時間に設定することを意図させる。 直感的なアルゴリズムは、オブジェクトの右と左の時間 座標を計算することに還元される。そして、これらの計算を行うのは難しいことではなく、左の座標は右の座標から24hを引いた値として計算されるのです。 同時に、例えばチャンネルの右ポイントを0barに設定し、10:00 Monにプログラムを実行した場合、左ポイントは現在のMonの1barに設定されます。実際のチャンネル長は24本ではなく、10本となります。 例えば水曜日にテストを行う場合、このようなエラーを発見することは困難です。この場合、ユーザーは「正しい」テストの結果、チャンネルの長さが24本であることを確認します。 小さなTFでチャンネルを構築 する場合にも同様の問題が発生し、その引用文には「穴」が記されている。 Виктор 2008.08.06 09:16 #488 SK. писал (а)>> もうひとつは、純粋に技術的、サービス的な機能を持つライブラリや、その作成が困難と思われる機能のライブラリが必要なことです。例えば、サーバーから返されるエラー処理の機能をプログラミングする場合、プログラマーは、このエラーやこのエラー（リクエストが多すぎる、ブローカーが忙しい、など）に対して専門家がどう対応すべきかを常に正しく理解することはできない。 トレーダーにとって、デリバリーパッケージの中にトレード操作のライブラリーが用意されているのは理想的なことでしょう。 そのため、トレーダーは再クオートやエラー処理について考える必要はありません。開発者ほどうまくやる人はいないと思っています。 そしてプロは、必要であれば自分でバリエーションを書いていく。 Владимир 2008.08.06 21:52 #489 メニューで他のテキスト要素に対して行われるのと同様に、#define 構造を使用する際にシンボリック名やシンボリック定数の色を変更できるようにすると便利でしょう。 例えば、こんな感じです。#define pi 3.14159265358 一見些細なことだが、多くの定義があるとすぐに見えなくなる ! brici 2008.08.11 05:49 #490 - MTにチャットがあるといい。 プラットフォームによっては（チャットが）ある、そこしかない。 1...424344454647484950515253545556...131 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
もうひとつ。
PsPadのようなMetaEditorのアドオンを書く能力を与える。
など、素敵なものを追加してください。
1.ペアブラケットに下線を 引く!!!!
2. ペアブラケットを勝手に追加してくれるスクリプト。
3.必要な機能にすぐにジャンプできるようなファイルツリーを作ってください。
4.キルCtrl+F2、やってくれ!!!!Ctrl+1, Ctrl+2, ....
ペアブラケットがない場合、コンパイラはしばしばファイルの終わりを 表示します!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
で、1000行を検索する :)
そうだ、そうだ、トレーリングストップを設定する関数をAPIで作ればいいんだ！」。(>> 頭痛が減る!!!)
どのようなトレーリングですか？;)
Trailingのための関数とExpert Advisorのライブラリ / Yury Dzyuban」の 記事で、そのうちの11個について説明しています。このロジックは応用レイヤーに属し、つまり各関係者が独自に作成するものです。
MQL-editorのプラグイン技術があると便利です。このページで紹介したこと（ペアブラケット、コードテンプレートのオートコンプリート、変数が使われていることのチェックなど）は、Microsoft Visual Studio 2008 / 2005環境では、Visual StudioExtensions 技術をベースにしたサードパーティ開発会社JetBrains Resharperで簡単に実装することが可能です。
どのようなトレーリングですか？;)
Trailingのための関数とExpert Advisorのライブラリ / Yury Dzyuban」の 記事で、そのうちの11個について説明しています。このロジックは応用レイヤーに属し、つまり各関係者が独自に作成するものです。
私もそう思います。
その思いはすでに表明しています。言語開発者がある特定の機能を書くことは問題ないと思います。特定のアルゴリズムに縛られることは、ひとつの傾向、ドグマを生み出すことになるからです。取引アルゴリズムのプログラミングは、あくまでもプログラマー（取引戦略の開発者）の仕事です。
もうひとつは、純粋に技術的、サービス的な機能だけでなく、その作成に困難が伴うような機能のライブラリーが必要なことです。例えば、サーバから返されるエラー処理用の関数をプログラミングする場合、プログラマは、あるエラーに対するExpert Advisorの反応を常に正しく理解することはできません（リクエストが多すぎる、ブローカが忙しい、など）。
個人的な意見ですが、一部のオブジェクトにプロパティを追加すると非常に便利だと思います。
例えば、チャンネルの長さを決めるバーの数。
チャネルとの連携が難しい。
H1のチャンネル長を24時間に設定することを意図させる。
直感的なアルゴリズムは、オブジェクトの右と左の時間 座標を計算することに還元される。そして、これらの計算を行うのは難しいことではなく、左の座標は右の座標から24hを引いた値として計算されるのです。
同時に、例えばチャンネルの右ポイントを0barに設定し、10:00 Monにプログラムを実行した場合、左ポイントは現在のMonの1barに設定されます。実際のチャンネル長は24本ではなく、10本となります。
例えば水曜日にテストを行う場合、このようなエラーを発見することは困難です。この場合、ユーザーは「正しい」テストの結果、チャンネルの長さが24本であることを確認します。
小さなTFでチャンネルを構築 する場合にも同様の問題が発生し、その引用文には「穴」が記されている。
もうひとつは、純粋に技術的、サービス的な機能を持つライブラリや、その作成が困難と思われる機能のライブラリが必要なことです。例えば、サーバーから返されるエラー処理の機能をプログラミングする場合、プログラマーは、このエラーやこのエラー（リクエストが多すぎる、ブローカーが忙しい、など）に対して専門家がどう対応すべきかを常に正しく理解することはできない。
トレーダーにとって、デリバリーパッケージの中にトレード操作のライブラリーが用意されているのは理想的なことでしょう。
そのため、トレーダーは再クオートやエラー処理について考える必要はありません。開発者ほどうまくやる人はいないと思っています。
そしてプロは、必要であれば自分でバリエーションを書いていく。
メニューで他のテキスト要素に対して行われるのと同様に、#define 構造を使用する際にシンボリック名やシンボリック定数の色を変更できるようにすると便利でしょう。
例えば、こんな感じです。#define pi 3.14159265358 一見些細なことだが、多くの定義があるとすぐに見えなくなる !