クラウドソーシングによるGUI。オープンベータテストを実施。 - ページ 29

新しいコメント
 
Alexandr Andreev:

まあ、半分くらいは例があったんですけどね。作業機能の一部として、何らかのファイルがあることは明らかです。スイッチ（ボタン）が生成され、ボタンを押したときのリアクションを書くことができるところ。

はい、これは半端な例です。ポジションのバグのせいで最後まで行けなかった。

ボタン、チェックボックス、入力ボックス、スライダー、ドロップダウン、ラジオボタングループに反応させることができます。

今のところ、エディターでこれらの要素を作成することができます。イベントハンドラをファイル内に作成し、その中でユーザーがリアクションを指定する。

また、ユーザーが要素にアクセスするファイルには、関数が出力されます。

1.要素の現在値を取得する。
2.要素に新しい値を設定する。

E_（エレメント）やW_（ウィンドウ）という接頭辞に反応するインテリセンスから、簡単に関数を選択することができます。

夕方には、完全な例証があります。
 
総じて、ボタンレスポンスの実装に関するリリースは、かなり実現性が高いと思います。ただ、デザインに工夫が必要です。
 
Реter Konow:
はい、これは半分例です。ポジションのバグのせいで最後まで行けなかった。

リアクションは、ボタン、チェックボックス、入力フィールド、スライダー、ドロップダウンリスト、ラジオボタングループに刻むことができます。

今のところ、エディターでこれらの要素を作成することができます。イベントハンドラをファイル内に作成し、その中でユーザーがリアクションを指定する。

また、ファイルには関数が印刷されており、ユーザーはこれを通して要素にアクセスする。

1.要素の現在値を取得する。
2.要素に新しい値を設定する。

E_（エレメント）、W_（ウィンドウ）の接頭辞に対応するインテリセンス・リストから、簡単に関数を選択することができます。

夕方には、完全な例証があります。

他にどんな機能を選べばいいのか...。は一切必要ありません。その中で、私が理解しているように、有効なボタンがスイッチに割り当てられているファイルを生成します。フルストップここから先は、このボタンに対するみんなのリアクションの呼び方次第です。例えば、押されたことを保存するためとか。プレスのフィードバック環境は不要だと思う。

 
Alexandr Andreev:

えー、他にどんな機能を選べばいいのか・・・。そんなものは必要ない。その中で、私が理解しているように、有効なボタンをスイッチに割り当てるファイルを生成する。 それだけです。フルストップここから先は、このボタンに対するみんなのリアクションの呼び方次第です。例えば、押されたことを保存するためとか。押しつけがましさをフィードバックするための環境は不要だと思う。

デザインに工夫を凝らした方が良い

 
Alexandr Andreev:

えー、他にどんな機能を選べばいいのか...。そんなものは必要ない。その中で、私が理解しているように、有効なボタンをスイッチに割り当てるファイルを生成する。 それだけです。フルストップここから先は、このボタンに対するみんなのリアクションの呼び方次第です。例えば、押されたことを保存するためとか。プッシュ・フィードバックができる環境......不要だと思う。

そしてここでは、クラスによって環境を実装するのが良いだろう。また、タブメニューの呼び出しなどなど。

 
Alexandr Andreev:

えー、他にどんな機能を選べばいいのか...。そんなものは必要ない。その中で、私が理解しているように、有効なボタンをスイッチに割り当てるファイルを生成する。 それだけです。フルストップここから先は、このボタンに対するみんなのリアクションの呼び方次第です。例えば、押されたことを保存するためとか。フィードバックできる環境は不要だと思います。

わかってないなぁ。

1.ハンドラにリアクションを入力すればいいんですね。

2.もし、要素（例えば、入力フィールドの テキスト）から現在の値を取得したい場合は、レディリストからその関数を呼び出します。
 
Alexandr Andreev:

そして、その環境はクラスを通じて実装されるべきものです。また、タブメニューの呼び出しなど。

ピーターさんの鼻先に「授業が必要だ」という表現を振りかざすのはやめましょう。せめて映像だけでも待って、それから質問しようよ。

私はすでにPeterに、彼の「カーネル」を非常に単純な方法で修正することを提案しました。こういう授業はクソだ。飛び込みたくないと思う人は、それはその人の勝手だ。

しかし、構造物を使えば、ピーター自身が楽になるだけだ。

コア」、つまりグローバル配列の現在の姿は、多次元配列、いや少なくとも2次元配列です。2つ目の次元は、インデックスによる特定のコントロールタイプのプロパティを含んでいます。プロパティは、インデックスが定義に置き換えられ、名前による「擬似参照」が得られるので、名前によるアクセスも可能です。実際、ピーターのコードにある「マークアップ言語」のように、すべてが定義の上に成り立っているのです。

私はすでにPeterに構造体を実装することを提案しているので、グローバル配列を一次元化し、プロパティを直接名前で参照できるようにすればよいのです。コアの構築も、元の構造に新しい小道具を追加し、さらにそれを名前で呼ぶだけで十分なので、簡素化されるでしょう。また、多数のdefineとそれを使用するメソッドのリストを削除することで、コード自体を短くすることができます。

一方ではクラスではないのですが、他方ではPeterにとってグローバル配列の取り扱いがずっと簡単になります。それに、ピーターはすでに組合という似たような組織で仕事をした経験もある。

でも、ピーターにはピーターなりの先生のやり方があるので、あとは結果を待つだけです......。

 

横断的な例として、次のようなスキームを提案したい。取引金額、SL価格、TP価格の3つのフィールドと、BUYとSELLの2つのボタンからなるフォームを作成します。

Expert Advisorを作成 し、GUIをinluderとして接続する。初期入札のための変数を追加する。初期化されると、初期入札額がGUIの該当フィールドに渡される。

Expert Advisorの機能「Open Deal」を作成します。この関数は、GUI上のボタンがクリックされるとすぐに呼び出される必要があります。

関数自体では、どのコマンドが与えられたかを「調べ」、またGUIに現在設定されているレートを尋ね、これらのデータに基づいて対応するディールを開くのです。

 
Алексей Барбашин:

横断的な例として、次のようなスキームを提案したい。取引金額、SL価格、TP価格の3つのフィールドと、BUYとSELLの2つのボタンからなるフォームを作成します。

Expert Advisorを作成 し、GUIをinluderとして接続する。初期入札のための変数を追加する。初期化されると、初期入札額がGUIの該当フィールドに渡される。

Expert Advisorの機能「Open Deal」を作成します。この関数は、GUI上のボタンがクリックされるとすぐに呼び出される必要があります。

関数自体では、どのコマンドが与えられたかを「調べ」、またGUIに現在設定されているレートを尋ね、これらのデータに基づいて対応するディールを開くのです。

ロット、テイク、ストップ＋売買ボタン？ シンプルで分かりやすい例です。そうします。注文を出したり、逆指値を取得したりする機能を追加する予定です。
 
Реter Konow:
わかってないなぁ。

1.ハンドラでリアクションを書く、ですね。

2.ある要素（例えば、入力フィールドの テキスト）から現在の値を取得したい場合は、レディリストからその関数を呼び出します。

なぜかというと、これは、フィールドが埋められ、入力値がテンプレート型であるときに呼び出される関数によっても実装可能だからです...。のすべてです。紐のようにさせても...。それでもフィールドの高速充填は行われない

1...222324252627282930313233343536...58
新しいコメント