MQLで書かれたUIのギャラリー - ページ 59

新しいコメント
  
#include<(2)  KIB PROJECTS\(6) DEMO PROJECTS\Demo project 1.mqh>

デモ・プロジェクト1は(1)KIB-source v1に含まれていますが、図に関連するウィンドウが表示されないのはなぜですか？

 
hini #:
カタログはまだロシア語です。カタログやファイル名をKIB PROJECTSのように英語表記にできないでしょうか？これは私からのささやかなお願いです！
もちろん、kodobaseにアップロードする前にカタログを英語に翻訳します。ただ、時間がないのです。これは公開テスト用の暫定版です。
 
hini #:

デモ・プロジェクト1は（1）KIB-source v1に含まれていますが、図に関連するウィンドウが表示されないのはなぜですか？

不思議ですね。今確認します。
 
hini #:

デモ・プロジェクト1は（1）KIB-source v1に含まれていますが、図に関連するウィンドウが表示されないのはなぜですか？

アセンブリを確認しました。Demo-project 1.mqhはここにあります：

(2) KIB PROJECTS\(6) DEMO PROJECTS\Demo project 1.mqh


 
リリースの詳細については、もう少し後で説明するつもりだ。
 

昨日、新バージョンをダウンロードした後、多くの作業を終え、感情的になっていた私は、文字通り新機能を賞賛する非常に前向きな記事を書いた。このような熱意は、厳密な技術的議論の場ではあまり適切ではない。今日は、実装されたソリューションを冷静かつ公平に見てみたい。建設的な批判と客観的な評価を歓迎する。第三者であるユーザーの視点を明確にすることは私にとって重要だ。フィードバックは調整と改善の助けになる。もちろん、バグを発見し修正するためにも。

 
リリースの内訳を説明しよう。
 
重要な情報が長く表示されるように、新しいページから始めることにする。
 


課題は、ユーザー・コードとプログラムのグラフィカル・インターフェースとの プログラム的インタラクションを実装することに設定された。

アイディアによると

  • KIBコードを書き、デバッグした後、ユーザーは（準備のできたウィンドウの形で）希望する結果を得て、プロジェクトを保存します。
  • UIDATA.mqhとAPI.mqhの2つのファイルが生成されます。最初のファイルはインターフェイスのロードと操作に必要で、2番目のファイルはエレメントのイベントの固定に必要です。
  • ユーザーは、Files フォルダから 自分のプロジェクト（現在：KIB PROJECTS(5) USER PROJECTS Project 1）に両方のファイルを転送する。
  • Expert Advisor またはインジケータを、エンジンと両ファイルを接続する線でコンパイルします：
//+------------------------------------------------------------------+
#include<(1)  KIB 1.0\(4) CONNECTIONS\KIB-DRIVE CONNECTIONS.mqh>
//--------------------------------------------------------------------
#include<(2)  KIB PROJECTS\(5) USER PROJECTS\Project 1\UIDATA.mqh>
//--------------------------------------------------------------------
#include<(2)  KIB PROJECTS\(5) USER PROJECTS\Project 1\API.mqh> 
//+------------------------------------------------------------------+
  • チャート上に EA を表示し、インターフェイスを見る。
EA Shell v1.mq5は デモプロジェクトの例として使用されており、ユーザープログラムを「表現」しています。EA シェルv1.mq5には、ユーザー・アナログに必要な同一の接続があります 。

//----------------------------------------------------------------------------------

しかし、このリリース以前は、ユーザーはサブキー化されたAPIファイル 内のインタラクティブ要素のイベントのみを受け取ることができました。

強調しておきたいのは、 ユーザーには多くの、絶対に必要なソフトウェア機能がなかったということ です 。

それらを列挙しよう：

  • GUIウィンドウのプログラムによる開閉。
  • 異なるタイプのエレメントのパラメータ値を取得/設定する。
  • プログラムによる要素の状態切り替え：例えば、ユーザー操作または実行中のExpert Advisor/Indicatorによって固定された外部イベントによって、要素のオン/オフ、ロック/アンロックを切り替える。
  • 要素プロパティの他の値をプログラムで取得/設定：ベース、テキスト、フレームカラー。アイコンの変更。


今回のアップデートで、設定されていたタスクはほぼすべて解決した。



以下に列挙してみよう。
  • プログラム・コールでGUIウィンドウを開閉できる。
  • ユーザーは、パラメータを持つ要素のパラメータで値を取得/設定できます。表のセル(CELL)やパラメータ(VALUE)を持つテキスト・ラベルのような非インタラクティブ要素を含む。
  • 異なるタイプの要素の2つまたは4つの状態間のプログラム切り替えが実装されています。ボタンとチェックボックスでは、4つのソフトウェアスイッチング状態（オン/オフ/オンロック/オフロック）が利用可能で、他の要素では2つ（ロック/ロック解除）です。
  • プログラムの戻り値/設定値のために、個々の要素プロパティの小さなセットが利用可能です。各セットは、インテリセンス・リストで始まる接頭辞で表されます。これは、類似のプロパティを持つ要素の小さな関連グループを一般化したものです。このアプローチにより、異なるタイプの要素の多数のプロパティの混乱がなくなります。
  • プログラムでパラメータに値を設定すると、APIファイル内のその要素の場所にイベントが送信され、そこでユーザーはそれを処理する追加のコードを書くことができます。
  • テーブルのセルは、行と列の名前を折りたたむことで自動的に名前が付けられます。それらはUIDATA.mqhファイル内で名前と機能ラッパーを取得します。しかし、これらはインタラクティブな要素ではないため、APIファイルには存在しない。それらはウィンドウ要素のリストで見つけることができ、そうでなければ他の要素と同様にソフトウェア制御に反応する。


プログラム制御の可能性により、以前は利用できなかったものが 実現されている：

1.値のディスパッチ。ある要素の値を取得し、それを同じ、あるいは別のウィンドウの他の要素に転送する。

2.警告ウィンドウやダイアログウィンドウをソフトウェアで開くこと。例えば、ユーザーに対して緊急のメッセージや勧告を表示する必要がある場合など。

3.要素パラメーターのクエリーによる、設定と実行ステータスの全体像の取得。他のプログラムパラメータの分析を補完するものとして使用できる。

4.作業プロセスを中断することなく、プログラム設定をダイナミックにリセット。

5.ベース、テキスト、フレーム（フレームはまだありません）の色を変更できるため、インターフェイスはよりインタラクティブで有益なものになります。例えば、値を巻き戻したときに、その値がリスクゾーンに入った場合、ボタン付きの入力フィールドは、そのベースやテキストの色を赤にすることで、ユーザーに危険を知らせることができます。これは今や簡単に実装できます。スライダーバーも同様です。危険な値のゾーンでは、プログラムでバーの色を変えることができます。これは、インタラクティブで、有益で、実用的であることがわかります。


今のところ、私はまだこれからの可能性を完全に実現できていません。


次は、新バージョンを破るための実践的な部分に移ろう。


 

結局のところ、デモの実用的な部分はかなり広範囲に及ぶため、そのカバーには時間がかかるだろう。コメントや写真、GIFを交えながら、新機能を詳しく、わかりやすく説明し、お見せしたいと思います。プレゼンテーションを今日と明日の2日間に分けなければならないかもしれない。でも大丈夫、あなたの理解は深まるでしょう。あなたも休んでください。


新バージョンのエンジンの機能を解析する計画：

1.新しいフォルダとファイルは、以前のものを完全に消去してから MEにインストールすることを忘れないでください。入れ替える必要はありません。

2.作業するには、ファイル(1) EA Shell v1.mq5と API.mqhを 開く必要があります。 他のファイルを開く必要はありません。デモプロジェクト1.mqhと 同じインターフェースと使い慣れたウィンドウを使用します。 最初のファイルはExpertsフォルダにあり（すでにあると思います）、2番目のファイルはここにあります：



このフォルダにあるUIDATA.mqhとAPI.mqhファイルには、必要なものがすべて含まれています。コンストラクターで新しいファイルを生成する必要はありません。


3.主な作業はファイル(1)のEA Shell v1.mq5、 関数_OnInit()と_OnTimerで行われますが、API.mqhを 調べることもあります。 もし興味があれば、UIDATA.mqhファイルを開いて、ウィンドウとエレメントのラッパー関数がどのようなものか見てみてください。一番下に印刷されている。そうでなければ、このファイルは作業には必要ないので、閉じてしまって構わない。


これから取り上げるトピックは以下の通りです：

1. インテリセンスのリストをナビゲートし、正しいウィンドウ関数を選択する。

2.プログラムでウィンドウを開いたり閉じたりする

3. インテリセンスのリストで方向を決め、正しいウィンドウの機能を選択する。

4. 個別の要素プロパティのリストをナビゲートする。

5.要素名とウィンドウ・ラッパー機能の解析。

6.選択した要素のパラメータ値を その型の変数に返す。いくつかの異なる要素の3つの型を考える。

7.異なるタイプの要素のパラメータに値を設定する。これらの要素のインターフェイスウィンドウに値がどのように表示されるかを見てみよう。

8.ある要素のパラメータ値を返し、その 値を 修正して 別の要素に転送する。異なるタイプの要素と値を考え、異なるウィンドウで異なるタイプの要素間の転送をテストしてみましょう。

9.前の値を返す(_V_LAST)。いつ、どのような場合に最後の値が必要なのか（現在の値と混同しないように）。

10.異なるタイプのエレメントのON/OFF/LOCK_ON/LOCK_OFF/LOCK/UNLOCK状態の設定をテストする。

11.11.異なるタイプの要素（例えば、ボタンとスライダーを持つ入力フィールド）の値の変化をリンクし、同期させてみましょう。1つの要素（手動またはソフトウェア）の値が変化すると、それに応じて2番目の要素の値も変化するとします。

12.スライダーとボタン付き入力フィールドの範囲の境界を、ラッパー関数を使ってプログラムでリセットしてみましょう。テストする時間がなかったが、うまくいきそうな気がする。しかし、見てみよう。

13.13.ラッパー関数で要素の状態を返すようにしてみよう。機能には含まれているのだが、テストする時間がない。さて、どうなることやら。結果は不明。

14.テキストとエレメント・ベースの色を取得・設定してみましょう。これらの色を簡単なイベントや値の境界に関連付けることができます。

15.新しいAPIファイルのプリントアウトをナビゲートしたり読んだりする方法について、もう少し詳しく説明しよう。


今のところは以上ですが、追加も可能です。

1...525354555657585960616263646566...83
新しいコメント