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

新しいコメント
 
hini #:
コンパイル時に生成される5,000以上の警告（その多くはマークアップ言語ファイルにある）をどうやって取り除くのか？
できない。文字列配列にマークアップ・コードを書くのだから、技術的には避けられない。このデータ型は慣例的にあらゆる値や単語を書くのに適している。

結局のところ、コンストラクタはキーワード、名前、数値を完全に区別できるので、それは問題ではない。

この方法によるデータの損失はない。
 
理論的には、各数値の前に(int)や(double)と書くこともできるが、それはユーザーに任せる。
 
コンパイラののどを "踏む "必要があるが、最終的には我々の勝ちだ）。大したことではない。


念のために言っておく。私はプログラミングのルールやコンパイラの警告を 尊重するが、この場合、私はより良い解決策を見つけられなかった。この方法を好まない人がいることは承知しているが、結果的には最も最適だった。そして無害だ。
 
明日にはアップデートを掲載し、自分のインターフェイスを作りたい人たちが最終的に作り始められることを心から願っている。頑張るよ。
 
Реter Konow コンパイラの警告を 尊重するが、今回はこれ以上の解決策が見つからなかった。この方法を好まない人がいることは承知しているが、結果的には最も最適な方法だった。そして無害だ。
ちょっとした話だ：

マークアップ・コードをどこに書くかという問題が生じたとき、私は主に2つの選択肢に直面した。頭に浮かんだ長所と短所を天秤にかけた結果、いくつかの理由から配列の方がずっと良いと判断した。第一に、コンストラクタのコードで配列の内容を即座に初期化して処理できる。第二に、コンストラクタやエンジンからコントロールの個々の属性やプロパティに高速でアクセスでき、必要に応じて読み込みや書き換えができること（ファイルでは大問題になる）。そして第三に、カスタムOnChartEvent()イベントを介してリソースに配列を送信する方がはるかに簡単です。これが配列を選んだ理由だ。そして警告。まあ、仕方ない。目的を達成するためには、常に何かを犠牲にしなければならない。

 
上の文章を訂正：リソース単位ではなく、構成された文字列のスライス単位で前進する。
 
そして、マークアップをテキストファイルに書くというアイデアの「棺桶の蓋」に最後の釘を刺すことになる：

.txtファイルは、重大なタイプミスがないことを確認するためにコンパイルすることができない。つまり、もしユーザーがカンマや引用符、スペースなどで何かひどい間違いをしたとしても、コンパイラーからはそれがわからないということだ。

インターフェイスの構築に失敗した後で初めて、彼は自分がひどいコードをタイプしたことに気づき、最後のタイプミスを見つけるために内部を探さなければならない。一つでも見逃すと、その手順をやり直さなければならない。

これは、コンパイラの警告がないことの代償として、非常に高くつく。

だからこそMQLでは、マークアップ・コードに文字列配列を使ったバリアントは代替手段がなく、使えないのだ。そしてコンパイラの警告は 当然のこととして受け止めるべきである。
 
追伸：コンパイラーはキーワードのスペルを間違えても警告します。インテリセンスが役立つこともある。.txtファイルでは、キーワードのスペルを間違えてもわからない。つまり、配列よりもファイルの方が実用的な利点がないのだ。

この特殊なケースでコンパイラの警告を 取り除かない理由を詳しく説明できたと思います。

それでは皆さん、ごきげんよう。

 
Реter Konow コンパイラの警告を 削除すべきではない理由を詳しく説明できたと思います。

みなさん、こんにちは。

わかりました。
 
コンストラクタの中心にあるコードは以下の部分だろうか？
ファイル:
Snipaste_2024-06-25_09-04-41.png  7 kb
1...171819202122232425262728293031...83
新しいコメント