MQL5への願い - ページ 81

 
stringo писал(а)>>

SpeechText機能は、常にクラッシュの原因となっています。すべてのOSで同じようにサポートされているわけではないので。一般に、Speech SDKはOSのオプションとして、オプションのコンポーネントとして提供されます。

標準のSpeechText関数を削除した後、職人がDLLを通して類似の関数を呼び出すようにしました。そして、このDLLのユーザーは、上記のコンポーネントをインストールしています。クライアント端末のインストール時に、このコンポーネントを強制的にインストールさせることはできません。

あなたができることは、あなた自身の "準公式 "DLLを作成し、このフォーラムにアップロードすることです。

アプリケーションとして(または公式サイトで)、簡単な使い方の説明(dllのインポートとコマンドの実行方法を示すのみ)。必要な人はダウンロードする。そして、すべての人が幸せになるのです。

.

- 途中質問ですが、フォーラムにあるDLLは5thバージョンでも使えるのでしょうか、それとも再コンパイルが必要なのでしょうか?

 
chief2000 писал(а)>>

- 途中、質問ですが、フォーラムにあるDLLはバージョン5で動作するのでしょうか、それとも再コンパイルが必要なのでしょうか?

>> 機能します。

 

既に言われているかもしれませんが・・・、テスターで可視化速度の調整をうまくしてほしいです。

また、多通貨のEAを テスターで各ペアごとにではなく、全ペアで一括してテストできるようにしてほしいです。

 

実を言うと、MT5にJavaのネイティブサポートを追加してくれたら、カッコいいんですけどね。MQL5とJAVAを両方持っていて、端末の機能をAPIで使えるということです。

 

GMT時間のネイティブサポートを導入することを提案します。これは、取引所の開閉に依存するExpert Advisorの動作を確実に保証するものであり、DCサーバーで設定された残り時間に依存せず、システムDLLの呼び出しやローカルシステムの設定の正確さ(無謬性)を必要としないものです。

時刻はNTP(Network Time Protocol)により、一般に公開されているサーバー(例:time.windows.com)から取得するか、独自の正確なタイムサーバーを開いて取得することができます。Linuxプラットフォームには、NTPサーバーをセットアップするためのツールが組み込まれており、COMポートを介してシンプルなGPSレシーバーをサーバーに接続するだけです。

サーバーへの常時要求は必要なく、ローカルとリモートの時刻を定期的に同期(リコンシレーション)させるだけで良いのです。

現在、MT4プラットフォームには、100%確実にGMTを出す方法はなく、このモノがどうしても必要です。

 
Shaitan писал(а)>>

GMT時間のネイティブサポートを導入することを提案します。これは、取引所の開閉に依存するExpert Advisorの動作を確実に保証するものであり、DCサーバーで設定された残り時間に依存せず、システムDLLの呼び出しやローカルシステムの設定の正確さ(無謬性)を必要としないものです。

時刻はNTP(Network Time Protocol)により、一般に公開されているサーバー(例:time.windows.com)から取得するか、独自の高精度タイムサーバーを立ち上げることができます。Linuxプラットフォームには、NTPサーバーをセットアップするためのツールが組み込まれており、COMポートを介してシンプルなGPSレシーバーをサーバーに接続するだけです。

サーバーへの常時要求は必要なく、ローカルとリモートの時刻を定期的に同期(リコンシリエーション)させるだけでよい。

今日まで、MT4プラットフォームは、100%の信頼性とGMTを与え、この事は必死に必要とされている、メソッドを持っていません。

賛成
MQL5のGMTを基準とした1)ローカルタイムと2)サーバータイムのオフセットを環境変数で指定。これにより、異なる証券会社の端末間でExpert Advisorを問題なく移行できるなど、履歴データ処理の普遍的なアルゴリズムが実現されます。

 
sol >> :

実を言うと、MT5にJavaのネイティブサポートを追加してくれたら、カッコいいんですけどね。MQL5とJAVAを併せ持つこと、端末機能のAPIを持つこと。

なぜJavaなのか、どこでそんな特権を手に入れたのか、何がそんなに「かっこいい」のか。この場合、Ada, APL, Boo, COBOL, Component Pascal, Delphi, Eiffel, Forth, FORTRAN, Haskell, IronPython, Lexico, Lisp, Mercury, Mondrian, Nemerle, .Net Framework/ASP.NET, Oberon, Perl, PHP, RPG, Ruby, Silverlight, Smalltalk, Visual Basic, WFC, 1Cのサポートをターミナルに追加し、すべての開発者は自分のネイティブ開発環境でMetaTraderを平等に使えるよう提案することにします。

 
chv >> :

なぜJavaなのか、なぜそんな特権があるのか、何がそんなに「クール」なのか。その場合、Ada, APL, Boo, COBOL, Component Pascal, Delphi, Eiffel, Forth, FORTRAN, Haskell, IronPython, Lexico, Lisp, Mercury, Mondrian, Nemerle, .Net Framework/ASP.NET, Oberon, Perl, PHP, RPG, Ruby, Silverlight, Smalltalk, Visual Basic, WFC, 1Cのサポートを追加し、あらゆる開発者がそれぞれのネイティブ開発プラットフォームで平等にMetaTraderを使用できるようにしてみてはどうかと思います。


だって、Javaはかっこいいけど、Ada, APL, Boo, COBOL, Component Pascal, Delphi, Eiffel, Forth, FORTRAN, Haskell, IronPython, Lexico, Lisp, Mercury, Mondrian, Nemerle, .Net Framework/ASP.NET, Oberon, Perl, PHP, RPG, Ruby, Silverlight, Smalltalk, Visual Basic, WFC, 1CはドSだものね。

 
sol >> :

だって、Javaはかっこいいけど、Ada, APL, Boo, COBOL, Component Pascal, Delphi, Eiffel, Forth, FORTRAN, Haskell, IronPython, Lexico, Lisp, Mercury, Mondrian, Nemerle, .Net Framework/ASP.NET, Oberon, Perl, PHP, RPG, Ruby, Silverlight, Smalltalk, Visual Basic, WFC, 1CはドSですからねぇ。

まあ、ムリヤリやりすぎなんだけどね。

Java、.Net、Delphi - 必要にして十分。

 
Shaitan >> :

GMT時間のネイティブサポートを導入することを提案します。

...

10,000,000 mio %に支えられている。

シングルタイムでの運用は、さまざまなメリットがあります。

(そして、願わくば、「ミックスタイム」に賛成している人たちよりも多くの人たちが、「ミックスタイム」に賛成している人たちよりも多くの人たちが、「ミックスタイム」に賛成していることを望みます)。

その中で最も重要なのは、私が信じていることです。

- 取引選択の幅が広がります。

- 情報資源とのシームレスで途切れのないドッキングを実現。