私のアプローチコアはエンジンです。 - ページ 86

[Dmitry Fedoseev]

Peterさん、ellipseのGIFを見ると、フォームは1枚のキャンバスのように見えますが？また、ドロップダウンリストはどのように機能するのでしょうか？ドロップダウン・リストがフォームのサイズより大きい場合に興味があります。

[Реter Konow]

Vasiliy Sokolov:

こう言ってはなんですが、私自身、自分の解答の杜撰さが気に食わないところがあるんです。MTオブジェクトを作成する必要があります。しかし、実際はただの偏見に過ぎない。どんな違いがあるのでしょうか？完全な転送には20〜30個も必要ありません。

30*64文字＝1920文字。大きなテーブルデータの転送にはこれで十分です。

[Реter Konow]

Dmitry Fedoseev:
Peterさん、楕円のGIFを見ると、フォームは1つの連続したキャンバスなんですね。また、ドロップダウンリストはどのように機能するのでしょうか？ドロップダウン・リストがフォームのサイズを超える場合に興味があります。

はい、フォームは1つのkanvasです。コンストラクタは、canvas自体の名前を書き、それを操作するためのラッパー関数を作成します。

ドロップダウンリストは、ウィンドウの外側の領域でも機能します。これを実装しています。

ドロップダウンリストは、もうひとつのカンヴァスです。ボタンがクリックされると表示され、消えます。

[Реter Konow]

Vasiliy Sokolov:

構造体をユニオンを介してバイト配列に直接マッピングし、グローバルアクセスで共有する。技術的に可能かどうかはわかりませんが、もし可能なら、まったくコピーする必要がないので、スピードは宇宙規模になるでしょう。

例を示していただければ、この解決策を喜んで受け入れたいと思います。

[Maxim Kuznetsov]

グラフィカルなオブジェクトを介したデータ交換には 注意が必要です :-)

でないと、Expert Advisorが「最適化できない」ように見えてしまうので...。

[Vasiliy Sokolov]

Реter Konow:

私の解答は、初期条件下での最良の選択肢です。

文字列とは。

1. 固定サイズなし。その結果、文字列の配列を整理することも、その配列の中の任意の文字列にアクセスすることも不可能になる。
2. 文字列のデータ打ち込みが 全くない。文字列解析の内部で動的にサブタイプを定義する必要があります。必要なトークンのパースに貴重な時間を浪費することになります。また、レキシムにエラーが含まれていても、文字列はそれを何ら制御しません。文字列を手に入れ、それが正しいことを祈るのです。
3. 1バイトあたりの情報記憶効率が低い。opt=1;cancel=3 "のようなサービス文字列は、せいぜい256文字中35〜40文字（バイト）（17％）しか使えません。100バイトの情報を送るためには、588バイトの文字列を形成する必要があり、通信路に過大な負荷をかけることになります。文字を圧縮してしまうと、コードが非常に複雑になります。変数名を略すと、ほんの少ししか役に立ちません。

そして、そんな当たり前のことをやっているにもかかわらず、まるでロビンフッドの ように、いかに自分が速く、正確に、ひもを当てたかを宣言するのです。いや、してないし、不健康極まりない。

基礎的な知識が必要なところで、勘に頼ろうとしないことです。

[Реter Konow]

Vasiliy Sokolov:

文字列とは。

1. 決まったサイズはありません。その結果、文字列の配列を整理することも、その配列の中の任意の文字列にアクセスすることも不可能になる。
2. 文字列のデータ入力が 完全に欠落している。文字列解析の内部で動的にサブタイプを定義する必要があります。必要なトークンのパースに貴重な時間を浪費することになります。また、レキシムにエラーが含まれていても、文字列はそれを何ら制御しません。文字列を手に入れ、それが正しいことを祈るのです。
3. 1バイトあたりの情報格納効率が低い。opt=1;cancel=3 "のようなサービス文字列は、せいぜい256文字中35〜40文字（バイト）（17％）しか使えません。100バイトの情報を送るためには、588バイトの文字列を形成する必要があり、通信路に過大な負荷をかけることになります。文字を圧縮してしまうと、コードが非常に複雑になります。変数名を略すと、ほんの少ししか役に立ちません。

そして、そんな当たり前のことをやっているにもかかわらず、まるでロビンフッドの ように、いかに自分が速く、正確に、ひもを当てたかを宣言するのです。いや、してないし、不健康極まりない。

基本を知るべきところで、根性論に乗ろうとしないことです。

Vasilyさん、MTの開発者がMTオブジェクトの記述を保存する際に、文字列の問題を考慮したとは思いませんか？

誰かの基礎知識の上に乗って、自分の直感でさらに上を目指すほうが、よっぽどカッコいい。

[Vasiliy Sokolov]

Реter Konow:

Vasiliyさん、MTの開発者は、MTのオブジェクトの記述を保存するときに、文字列の問題を考慮したと思いませんか？

ピーター：どのデータストレージのアルゴリズムにも弱点と強みがあります。開発者は確かにいろいろなことに配慮していますし、確かに良いのですが、根本的に文字列はいつまでたっても文字列のままなのです。

[Реter Konow]

Vasiliy Sokolov:

ピーター：どのデータストレージのアルゴリズムにも弱点と強みがあります。もちろん、開発者はいろいろなことを考慮し、確かに良いのですが、根本的に文字列はいつまでたっても文字列のままなのです。

ワシリー 実践の結果、私の解決策に欠陥があると分かったら、それを放棄するつもりだ。そして、ニコライの解決策をとることにします。それも悪ければ、OnChartEvent() に戻って、何もできないと言うことになります。

しかし、私のソリューションの実装がまだいい加減なものになるとは思えません。

すぐにわかります。

[Vasiliy Sokolov]

z.s. 特に、MTオブジェクトに文字列を格納する件ですが、1つだけ奇妙な不具合があります。データの圧縮を開始し、オブジェクト名に印字不可能な文字を使用した場合、場合によってはこのオブジェクトにアクセスできなくなることがあります。この不具合は非常に特殊で、知っている人も少ないので、おそらくまだ残っていると思いますが、それでもつまずくことがあるかもしれません。