Glade is a RAD tool to enable quick & easy development of user interfaces for the GTK+ toolkit and the GNOME desktop environment. The user interfaces designed in Glade are saved as XML, and by using the GtkBuilder GTK+ object these can be loaded by applications dynamically as needed. By using GtkBuilder, Glade XML files can be used in...
まずはExpertからですね。専門家に関連するタスクを3種類あげましたが、あなたのインターフェースでは実現不可能であることがわかりました。
何が役に立つのか？おそらく、より深い統合、あるいは「遠隔操作」に限定したプロジェクトなのでしょう。
あなたのエネルギーを平和的な目的のために使ってください。）
もちろん、GUIライブラリの開発はクリエイティブで、ある意味やりがいのあるビジネスであることは理解しています（コードを書き、ウィンドウを描き、結果を見るのです）。でも、これだけ行き詰まると、無駄な時間が増えてしまう...。
要するに、MTに代替GUIをどう引っ掛けるかということです。
- というDLLが書かれています。
- 最初の呼び出しで、個別のトレースを作成し、グラフサブシステムを初期化する。
- 各ユーザーに2つのメッセージキュー（MTからGUIへ、またはその逆）があります。
- MQ4/5クラスが作成され、基本的にこれらのキューにあるメッセージを処理/フィルタリングし、СhartEvent
- 構造体の共有と配列の同期を行うためのオプションのAPI
この方法で、ほぼすべての最新のシステムに接続することができます。
- DotnetのwinformsとotherShareが使える（C#でマネージャコードをフックしてDLLを作る方法がリソースのどこかに載っていた）
- gtkとデザイン in gladehttps://glade.gnome.org/
- デザイナーを起用したQthttps://www.qt.io/ui/
- httpサーバーも制限付きで運用可能です :-)
正しい」アーキテクチャとは、探索可能なGUIを別スレッドで動作させ、EA/インジケータの速度を低下させないことであることが判明しました。GUIは「特別な訓練を受けた人たち」が設計・描画しています :-)Expert Advisor/Indicatorは実質的に「モデル」です（MVCなどと同様）。
私のインターフェイスでは、これらのタスクが実現不可能だとは言っていません）。つまり、OOPに基づく技術は、アプローチの非互換性から、私のコードに統合することができません。これらの作業は、基本的な（優先順位の高い）ものの実装が終わってから、自分で実装することになりますね。
OOPは関係ない。もちろん、グローバル 変数で文字列やイベントを渡すことはできますが、これは特殊なケースで、ましてや「新世代の取引プログラム」を謳った大規模なプロジェクトでは無理でしょう。
あなたのエネルギーを平和のために使ってください。）
私の目標は、純粋に平和的なものです）。
あなたの提案は面白いですね。実装してみてはいかがでしょうか。
個人的には、「他人の解決策を自分の解決策と比較することは、自分に対する選択 である」ということは、ごく当たり前のことなのです。
MTには独自の言語があります。C++やC#があるのに、なぜ必要なのか？なぜ作られたのか？
それらの言語がアルゴトレーダーのタスクに最適にチューニングされていなかったから作られたのだと思います。専門的な応用言語が必要だったのだ。
ユーザーは、簡単にできるのであれば、インターフェースの作り方など気にしない。ご指摘のようなインターフェースの作成は、本格的なプロでないとできませんし、それ以外の方は、DLLによるサードパーティーのプログラムの接続が異なるのはもちろん、標準の MTライブラリーを 使うのも難しい場合がありますね。
もし私があなたのバージョンを開発するとしたら、DLLが主に自分自身のために使われることをご存知のように、それをコミュニティに広めることはできないでしょう。そして、この解決策が他の人にどんな良い影響を与えるのか？
あなたのソリューションは可能ですが、広く普及させることはできません。
OOPは関係ない。もちろん、グローバル 変数で文字列やイベントを渡すことはできますが、これは特殊なケースで、ましてや「新世代の取引プログラム」を謳った大規模なプロジェクトでは無理でしょう。
友人たちよ、私はフォーラムでおしゃべりに夢中になっている間に、少し停滞していたプロジェクトに 再び取り掛かろうとしています。定期的にここに開発の進捗状況を投稿し、皆さんにお返事していく予定です。
今後のEAのインターフェースについて、ご意見、ご感想、ご提案がありましたら、お気軽にお書きください。
ありがとうございます。
しかし、技術不足、共通規格の欠如、作成されたグラフィックの低品質などの問題が、リスクを負って取引ロボットのユーザーインターフェースを作成するプログラマーに立ちはだかったのです。MTの完全なUIを作るのは、取引ロジックをコーディングしたり、統計情報を収集するアルゴリズムを書いたり、パターン認識をストラテジーに実装するよりもはるかに難しいことが明らかになった。このような困難が、アルゴリズム取引が、人間とプログラムとの必要な相互作用の領域を大きく広げ、取引の有効性を高め、最も独創的なアイデアの可能性を引き出す 新しいレベルへと 移行する際の障害となったのです。アルゴリズムに "鉄 "で縛られたプログラムの欠点を、人間の思考の柔軟性で補うことができる、インタラクションの領域です。
今のEAはレールの上を走る路面電車のようなもので、ユーザーはそれ以外のことを知らない。しかし、EAが自動車のように、どの方向にも舵を切ることができるようになったらどうだろう。そんな "クルマ "があれば、市場でも安心です ...
皆さん、こんにちは。
アルゴリズム取引の 新しいレベルについて、非常によく書かれています。事実、トレーディングのためのモダンなインターフェースは非常に必要なものです。それをどう作るかは別問題です。例えば、私たちのサイトにはライブ統計があります。しかし、ロボットを外部リソースに結びつけ、そこにUIを実装するのであれば可能です。MTではインフォグラフィックを使おうとはせず、都合の良いところで作成しています。しかも、普通のトレーダーはブラウザーの使い方を知っているわけで、新しいインターフェースは、やはり勉強して慣れる必要がある。ユーザーのための個別統計は、すぐに多くのことを行うことができます。
しかし、トラムについては、どこを操縦するのか？どういうことですか？私たちの経験では、為替市場を「路面電車のように」横断する、記述され、テストされ、調整されたロボットは、トレーダーが操縦する場合よりも安全で効果的であることが分かっています。トラムの話に戻りますが、トラムがどのようなルートを通るのかを理解することが重要です。でも、最終地点が同じなら......クルマはどうなるんだろう？事故が起こる確率は何倍にもなります。舵取りをしようとする人たちこそ、問題を起こすのです。
すごいですねぇ。私もそうしたいです。しかし、人工知能が欲を出して利益の何割かを懐に入れたり、私怨を理由に所有者を破産させたりする可能性もある)) 。
皆さん、こんにちは。
アルゴリズム取引の新しいレベルについて非常によく書かれています。実は、取引のためのモダンなインターフェースは、とても必要なものなのです。どう作るかは別問題です。例えば、私たちのサイトにはライブ統計があります。しかし、ロボットを外部リソースに結びつけ、そこにUIを実装するのであれば可能です。MTではインフォグラフィックを使おうとはせず、都合の良いところで作成しています。しかも、普通のトレーダーはブラウザーの使い方を知っているわけで、新しいインターフェースは、やはり勉強して慣れる必要がある。ユーザー向けの個別統計はこれからですが、さらに多くの情報を提供する予定です。
しかし、トラムについては、どこを操縦するのか？どういうことですか？私たちの経験では、為替市場を「路面電車のように」横断する、記述され、テストされ、調整されたロボットは、トレーダーが操縦する場合よりも安全で効果的であることが分かっています。トラムの話に戻りますが、トラムがどのようなルートを通るのかを理解することが重要です。でも、最終地点が同じなら......クルマはどうなるんだろう？事故が起こる確率は何倍にもなります。舵取りをしようとする人たちこそ、問題を起こすのです。
午後
私が考える未来のアドバイザー（MT）とは、「必要なものを一つのプログラムに集約し、つなげる」という信念に基づくものです。
私は、どんなプログラムも、その集中化と汎用性こそが最大の効率であると確信しています。必 要な機能を最大限に組み合わせ、不要なものを削ぎ落とすことで、EAを含むあらゆるメカニズムの効率を質的に向上させることができる。現在、提供されている取引ロボットの多くは、互換性のない言語やリソースをさまざまな方法で接続する試みが指向されています。外部DLLの 使用、ビジュアルスタジオで構築されたインターフェース、異なる統計サービスなどを提案されています。取引ロボットの容量を増やすタスクは、この方法で解決することが できますが、それは明らかである - この解決策は不便であり、誰にでも適しているわけではありません。
すべての人が、 あまり 熟練して いない アルゴトレーダーでさえ、大きな費用をかけずに独立して（あるいは誰かの助けを借りて）自分が使いたい取引ロボットを構築し、それらを統合し修正する最も複雑なタスクを解決しようとする外部のリソースに頼らざるを得なくなるまで、取引ロボットは新しいレベルに飛躍することはないだろう。それが私の信念です。
外側の統計とロボットの中の統計は根本的に違うものです。最初のケースでは、ユーザーは統計情報を監視し、自分の戦略のいくつかのパラメータをリセットすることができますだけで、2番目のケースでは、取引の統計情報は、ロボット自身がその設定を調整することができ、リアルタイムでExpert Advisorによって分析されます。取引戦略の設定を修正するためのアルゴリズムを記述することができ、統計値が低い場合には戦略を完全に置き換えることも可能です。このアイデアの開発ポテンシャルは明らかです。これが、自動車にできて路面電車にできない「操舵」ということです。
EAがあるプラットフォームにあり、そのインターフェイスが別のプラットフォームにあり、統計が第3のプラットフォームにあるという選択肢は、誰もが自分のEAに望む理想的なメカニズムという点では、良いとは言えません。))
画面に大きく "get paid "と表示されるだけで、DVDからすぐにグリーンが出てくるのです ))。