クラウドソーシングによるGUI。オープンベータテストを実施。 - ページ 48 1...414243444546474849505152535455...58 新しいコメント Алексей Барбашин 2020.03.07 23:03 #471 ピーター、私をどう扱おうが勝手だが、もう少し経験豊富な同志からアドバイスをもらうといい。 #include <GUI_DRIVE.mqh> #include "..\Files\CORES.mqh" #include "..\Files\Internal_API.mqh" GUI_DRIVE.mqh ファイルは、コード内で最初に接続されています。 それ以前には何も宣言されていない。 もしこれをコンパイルすると、G_COREが見つからないというエラーが出ますが、これはこのファイルで配列が宣言されていないためです。 結論は？さて、結論は簡単で、配列はこのファイルで宣言されなければならない、ということです。結局、この配列で操作するのはこのファイルであり、このファイルが「エンジン」だからだ!したがって、その中の配列自体の宣言は、使用文脈からして正しい。 次のファイルCORES.mqhは、配列にフォーム 要素の説明を記入するものである。 もちろん、これらのファイルを使ってEA自体をコンパイルする場合、最初のファイルで配列を宣言しておけば、2番目のファイルをコンパイルしたときに、すでにプログラムのコンテキストで配列が見えているので、コンパイルの問題は発生しません。 しかし、私たちが言っているのは、各ファイルがエラーなくコンパイルされることなのです。2番目のファイルではG_CORE配列に要素を入れているので、このファイルをコンパイルする際に、配列が宣言されて いないと当然ながらエラーになります。 そして、ここでは、アレキサンダーが言ったように、スタブを使うのです。 ピョートル君はディファインの大ファンだから、何が起こっているのか分かるはずだ。 GUI_DRIVE ファイルで、カーネル要素のグローバル配列 G_CORE を宣言し、後はエラーなくコンパイルされるはずです。 そして、このファイルの中に、defineを追加するのです。 #define __DRIVE__ Cores ファイルに移動します。配列を宣言する前に、コンパイルプリプロセッサーを使用します。 #ifndef __DRIVE__ int G_CORE[][prop_limit]; #endif そして、アレイを埋めるのです。もちろん、宣言なしで行うには、配列への記入方法を少し変える必要があります。 CORESファイルをコンパイルすると、__DRIVE__の デフォルトがなくなり、配列宣言のコードもコンパイルされ、すべてが うまくいく、という要旨はご理解いただけたと思います。 EAの一部としてコンパイルされた場合、最初のファイルをコンパイルした後、defineが宣言され、2番目のファイルでは、コンパイラがこのコードの部分を「カット」するため、配列は宣言されません。 ご理解いただけたでしょうか？ もう一度言いますが、すべてのファイルはエラーなくコンパイルされなければなりません。依存関係がある場合は、その場所を適切に提供し、必要に応じてリコンパイル処理系を追加する必要があります。 すべてのファイルがエラーなくコンパイルされていれば、システム全体の整合性に自信を持つことができます。 また、各ファイルのプロパティを追加することも忘れないでください。 #property strict このプロパティは、コードに対してより厳しいチェックを与えます。 Реter Konow 2020.03.07 23:32 #472 これでは実用的な意味がほとんどありません。各ファイルがエラーなくコンパイルされていれば、アセンブリ全体の整合性に関係なく、ユーザーは簡単にいずれかのファイルの接続を見落とすことができます。忘れがちなことですがとにかく、取るに足らないことなので、無駄なことはしないようにしています。これは完全にナンセンスです。ナンセンスである。 Реter Konow 2020.03.08 07:31 #473 はい、プリプロセッサを操作することで、各ファイルがエラーなく別々にコンパイルされるようにすることができます。しかし、そこに間違いがあるのです。それらは全体の一部であり、他の部分からの独立性を「描く」べきではありません。そして実際、ユーザーは「このままでも動くから、すべてのファイルは必要ない」と判断することもあります。そんな、非常に意味の怪しい活動に時間を浪費しているのか？誰を騙そうとしてるんだろう？コンパイラー？経験豊富な」同志は、その厳しい声を恐れ、何事も常に正しいと信じているようだ。だから、意味がなくても適応しようとするのです。私のマークアップ言語のコードでは、定数の前に(sring)を付けなければならないため、何千もの警告が発生していました。各数値の前に型変換を入れると、どんなコードになるかは想像がつきますね。でも、少なくとも警告はないでしょう。 Alexandr Andreev 2020.03.08 07:39 #474 Реter Konow: はい、プリプロセッサーを操作することで、各ファイルをエラーなく別々にコンパイルすることができます。 しかし、そこに間違いがあるのです。それらは全体の一部であり、他の部分からの独立性を「描く」べきではありません。そして実際、ユーザーは「このままでも動くから、すべてのファイルは必要ない」と判断することもあります。 そんな、非常に意味の怪しい活動に時間を浪費しているのか？誰を騙そうとしてるんだろう？コンパイラー？ 経験豊富な」同志は、その厳しい声を恐れ、何事も常に正しいと信じているようだ。だから、意味がなくても、適応しようとする。 私のマークアップ言語のコードでは、定数の前に(sring)を付けなければならないため、何千もの警告が発生していました。各数値の前に型変換を入れると、どんなコードになるかは想像がつきますね。でも、少なくとも警告はないでしょう。 メタ・エディター自体のインターフェイスを少し変えて、使いやすさだけを追求した別のソフトウェアを書いている同志もいますよ。 この規格は、キーボードを使うようなもので、モールス信号で文字を入力する代わりに、鳴子で文字を入力するのです。スタブでは、コンパイル時にファイルを常に反転させる以外は何も変わりません。しかし、スタブは2行のコードです。ボタンを1つ押すだけで、このブラウジングにどれだけの時間を費やすことでしょう。そして、何回7を反転させるか、何がより合理的になるのか、人生を無駄にしないために、スキヤキで文字を入力するのです。 オブジェクトやクラスの話ではなく、単に時間短縮の話であることに注意してください。あなたの時間... そして、その書き方の基準を自分で考えることができる。 Реter Konow 2020.03.08 07:42 #475 ロシア語でのコーディングはもちろんのこと、英語の開発環境ではデフォルトで差別される。また、ロシア語では100％使えるのに、私の脳には30％しか性能が残らないというのは、適応力がないのでしょうか？プロフェッショナリズム」の代償はここまで。 Alexandr Andreev 2020.03.08 07:51 #476 Реter Konow: ロシア語でのコーディングはもちろんのこと、英語の開発環境ではデフォルトで差別される。ロシア語は100％使えるのに、脳は30％しか使えないというのは、どうなんでしょう？ プロフェッショナリズム」の代償はここまで。 プロフェッショナルは、コードに独自のデータ型を 使用します。一般的には、どの言語であってもかまいません。 しかし、ある関数がこの順番で整数を期待するとしたら受け入れる（幅、高さ）。 その代わり、誤って混ぜて書いてしまう Accept (height, width) - すると、コピー機自身が「ここはごちゃごちゃしている」と言っています。それが自分にとって有効かどうか。それは、言葉やモノの問題でもないのです。このエラーを自分で探さなくていいということです Реter Konow 2020.03.08 07:58 #477 Alexandr Andreev: プロのコードでは、個人が独自のデータ型を 使用します。言語は問いません。 しかし、ある関数がこの順番で整数を期待するとしたら受け入れる（幅、高さ）。 その代わり、誤って混ぜて書いてしまう Accept (height, width) - すると、コピー機自身が「ここはごちゃごちゃしている」と言っています。それが自分にとって有効かどうか。それは、言葉やモノの問題でもないのです。ただ、このエラーを自分で探さなくていいということなんです。 既成のソリューションをテストし、ユーザーに伝えるためのブランチです。私は建設的なテスターを必要としているのであって、何か文句を言いたいだけの野心的な「プロ」ではないのです。抽象的な問題を論じるつもりはない。組み立てたパネルを接続して、バグを発見し、報告しましたか？ありがとうございました。賢いふりをして、理解できないものをつまみ食いして......さようなら。 Реter Konow 2020.03.08 08:02 #478 紳士淑女の皆さん、ここはあなたの居場所ではありません。エディターを走らせていない、パネルをつないでいない、でも「教えている」人にとっては、話は短い。それ以外の方々は、ようこそ! Igor Zakharov 2020.03.08 08:06 #479 Алексей Барбашин: ピーター、私をどう扱おうが勝手だが、もう少し経験豊富な同志の 助言を受けなさい。 ....... また、各ファイルにプロパティを追加することを忘れないでください。 #property strict このプロパティは、コードに対してより厳しいチェックを与えます。 5用です。そこはいつも同じです。 一般的には、コンパイル時に多くの警告が出ることは、コードの信頼性を高めることにはならない、ということに同意しますが。 Реter Konow 2020.03.08 08:09 #480 Igor Zakharov: 5人用だから、いつも厳しいんです コンパイル時に多くの警告を出すことは、コードの信頼性を高めることにはならないからです。 警告を削除します。一時的なものです。 1...414243444546474849505152535455...58 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ピーター、私をどう扱おうが勝手だが、もう少し経験豊富な同志からアドバイスをもらうといい。
GUI_DRIVE.mqh ファイルは、コード内で最初に接続されています。 それ以前には何も宣言されていない。
もしこれをコンパイルすると、G_COREが見つからないというエラーが出ますが、これはこのファイルで配列が宣言されていないためです。
結論は？さて、結論は簡単で、配列はこのファイルで宣言されなければならない、ということです。結局、この配列で操作するのはこのファイルであり、このファイルが「エンジン」だからだ!したがって、その中の配列自体の宣言は、使用文脈からして正しい。
次のファイルCORES.mqhは、配列にフォーム 要素の説明を記入するものである。
もちろん、これらのファイルを使ってEA自体をコンパイルする場合、最初のファイルで配列を宣言しておけば、2番目のファイルをコンパイルしたときに、すでにプログラムのコンテキストで配列が見えているので、コンパイルの問題は発生しません。
しかし、私たちが言っているのは、各ファイルがエラーなくコンパイルされることなのです。2番目のファイルではG_CORE配列に要素を入れているので、このファイルをコンパイルする際に、配列が宣言されて いないと当然ながらエラーになります。
そして、ここでは、アレキサンダーが言ったように、スタブを使うのです。
ピョートル君はディファインの大ファンだから、何が起こっているのか分かるはずだ。
GUI_DRIVE ファイルで、カーネル要素のグローバル配列 G_CORE を宣言し、後はエラーなくコンパイルされるはずです。
そして、このファイルの中に、defineを追加するのです。
#define __DRIVE__Cores ファイルに移動します。配列を宣言する前に、コンパイルプリプロセッサーを使用します。
そして、アレイを埋めるのです。もちろん、宣言なしで行うには、配列への記入方法を少し変える必要があります。
CORESファイルをコンパイルすると、__DRIVE__の デフォルトがなくなり、配列宣言のコードもコンパイルされ、すべてが うまくいく、という要旨はご理解いただけたと思います。
EAの一部としてコンパイルされた場合、最初のファイルをコンパイルした後、defineが宣言され、2番目のファイルでは、コンパイラがこのコードの部分を「カット」するため、配列は宣言されません。
ご理解いただけたでしょうか？
もう一度言いますが、すべてのファイルはエラーなくコンパイルされなければなりません。依存関係がある場合は、その場所を適切に提供し、必要に応じてリコンパイル処理系を追加する必要があります。
すべてのファイルがエラーなくコンパイルされていれば、システム全体の整合性に自信を持つことができます。
また、各ファイルのプロパティを追加することも忘れないでください。
このプロパティは、コードに対してより厳しいチェックを与えます。
はい、プリプロセッサーを操作することで、各ファイルをエラーなく別々にコンパイルすることができます。
メタ・エディター自体のインターフェイスを少し変えて、使いやすさだけを追求した別のソフトウェアを書いている同志もいますよ。
この規格は、キーボードを使うようなもので、モールス信号で文字を入力する代わりに、鳴子で文字を入力するのです。スタブでは、コンパイル時にファイルを常に反転させる以外は何も変わりません。しかし、スタブは2行のコードです。ボタンを1つ押すだけで、このブラウジングにどれだけの時間を費やすことでしょう。そして、何回7を反転させるか、何がより合理的になるのか、人生を無駄にしないために、スキヤキで文字を入力するのです。
オブジェクトやクラスの話ではなく、単に時間短縮の話であることに注意してください。あなたの時間... そして、その書き方の基準を自分で考えることができる。ロシア語でのコーディングはもちろんのこと、英語の開発環境ではデフォルトで差別される。ロシア語は100％使えるのに、脳は30％しか使えないというのは、どうなんでしょう？
プロフェッショナルは、コードに独自のデータ型を 使用します。一般的には、どの言語であってもかまいません。
しかし、ある関数がこの順番で整数を期待するとしたら受け入れる（幅、高さ）。
その代わり、誤って混ぜて書いてしまう
Accept (height, width) - すると、コピー機自身が「ここはごちゃごちゃしている」と言っています。それが自分にとって有効かどうか。それは、言葉やモノの問題でもないのです。このエラーを自分で探さなくていいということです
プロのコードでは、個人が独自のデータ型を 使用します。言語は問いません。
しかし、ある関数がこの順番で整数を期待するとしたら受け入れる（幅、高さ）。
その代わり、誤って混ぜて書いてしまう
Accept (height, width) - すると、コピー機自身が「ここはごちゃごちゃしている」と言っています。それが自分にとって有効かどうか。それは、言葉やモノの問題でもないのです。ただ、このエラーを自分で探さなくていいということなんです。
ピーター、私をどう扱おうが勝手だが、もう少し経験豊富な同志の 助言を受けなさい。
.......
また、各ファイルにプロパティを追加することを忘れないでください。
このプロパティは、コードに対してより厳しいチェックを与えます。
5用です。そこはいつも同じです。
一般的には、コンパイル時に多くの警告が出ることは、コードの信頼性を高めることにはならない、ということに同意しますが。
5人用だから、いつも厳しいんです
コンパイル時に多くの警告を出すことは、コードの信頼性を高めることにはならないからです。