記事"ビジュアルストラテジービルダー。 プログラミングなしでトレーディングロボットを作成する"についてのディスカッション - ページ 4

新しいコメント
 
Nikolai Semko:

この特別なケースでは、何も問題はないと思う。ロボットでも信号でもなく、非プログラマーのための生産手段なのだから。
あるものは商品であり、別のものは商品や技術を生産するための機械である。普通の商品は国内に輸入される際に関税がかかるが、技術は探し出され、国家自身がその代金を支払う用意がある。
プラットフォームのプロモーションのため、この商品のプロモーションはMQの手に委ねられているため、水面下での合意はほとんどない。
さらに、MQの利益のための真剣かつ広範な仕事が報われるべきなのは事実である。
しかし、前例ができてしまった :)))
例外のないルールは存在しない。自分の不利益になるような「ルール」の原則を追求するのは賢明ではないだろう。

公益のために価値ある技術的なものを生み出す人は、MQに同様の忠誠を期待する権利があると確信している。そして当然のことだ。

あなたはとても賢明だ、ニコラス))

まったく同感です（笑)。

 
Nikolai Semko:

MQLウィザードでMQが考案し実装したコンストラクタが、新たな開発、新たなグラフィカル・ライフを手に入れ、有償の製品でテストされ、完璧になるのであれば、何も問題はない。

私は、それが悪いことだと言っているのではありません。それどころか、ソフトウェア開発の分野で人々の功績を評価することは有益だと言っているのです。

MQについて - 彼らが急いでさらに何かを開発するとは思えません。それに、この製品はまるで必要ないと言っているかのようです。

ニコライ・セムコ：

たとえ "談合 "があったとしても、"合意 "と呼ぶ方が正しいだろう。どんな犯罪？

私は陰謀や謀略を探す検事ではありません。そうではなく、自分たちの製品に関する記事がMQに興味を持たせるか持たせないか、どのような基準で判断しているのかを皆さんに理解していただきたいのです。

ニコライ・セムコ：

私はまた、このプログラマーのコミュニティで、ある種の双方向的な流れを作りたいと考えています。個人的には、長い間それについて話してきました。今のところ、この分野では大きな遅れを感じている。
もちろん、私のビジョンはこの実装とは大きく異なるが、それでも何かはある。
この製品の有用性や実用性については議論したくもない。重要なのはトレンドだ。

Expert Advisors/Indicators/Scriptsの設定に関する 問題を解決し、作業の便宜のために色やその他のグッズを追加できるようにするというトピックを作成したのですが、残念ながら関心を持つ人はほとんどいませんでした。

 
Andrey Barinov:

無料版はフルバージョンより不便なだけで、十分に使える。

そう、やって、やって、バーンと全部消し飛んでしまうのだ。まあ、ちょっと怪しげな楽しみではあるが。

それとも、私が制限のひとつを誤解していたのでしょうか？

アンドレイ・バリノフ：

もしコードが必要なら、あるテンプレートのスキームのコードを生成して研究してみてください。何か役に立つものが見つかるかもしれません。例えば、トレード・クラスはスタティック・クラスとして作られ、他のコードとは別に使うことができます。

なぜ生成されたコードが必要なのか？相互作用がどのように機能するのか、どのように接続が発生し（テンプレートが準備され）、そして解釈されるのかを理解するのは興味深いことです。

 
Andrey Barinov:

どういう意味か説明していただけますか？

つまり、アイコンの密度が非常に高く、他のアイコンとアイコンの間をまたいでつながっている。

グラフィックの利点は、情報の知覚を向上させ、プログラムのロジック／コードの構造をより読みやすくすることだと私は考えている。

個人的には、古典的なフローチャートの形で要素を配置する方が、読むのに便利である。

 
Aleksey Vyazmikin:

そう、やって、やって、バーンって、全部消えちゃうんだ。

それとも、私が制限のひとつを誤解していたのでしょうか？

スケマティック作成中は何も削除されない。スキーマは、ある一定数のソースコード生成後に削除される。

なぜ生成されたコードが必要なのですか？インタラクティビティがどのように機能するのか、どのように接続が起こり（パターンが準備され）、そして解釈されるのかを理解するのは興味深いことです。

これはまさに生成されたコードから理解できることです。

個人的には、古典的なフローチャートの形で要素を配置する方が読みやすいだろうし、そのためには作業スペースがもっとあるはずだ。

ズームのことですか？それともアイコンの大きさについてですか？スクロールはあります。アイコンの密度はユーザーの要望次第です。アイコンの密度を低くすることもできます。

 
Andrey Barinov:

スキーマ生成プロセスでは何も削除されない。スキーマは、一定回数のソース・コード生成後に削除されます。

これはまさに、生成されたコードから理解できることである。

ズームについてですか？それともアイコンのサイズについて？スクロールはある。アイコンの密度はユーザーの要望次第だ。密度を低くすることもできます。

では、私は説明を誤解していました。

そうかもしれない。

これはスペーススクロールのことで、私はスクリーン上でそれを見なかった、それが私が書いた理由だ。

 
Aleksey Vyazmikin:

私は説明を誤解していたようだ。

もしかしたらできるかもしれないが、誰にでもできるわけではない

スペーススクロールのことなんだけど、画面には表示されなかったから書いたんだ。

もし興味深いトピックであれば、この部分についてより技術的な記事を書くことができます。

簡単に言うと、各要素はクラス、つまりオブジェクトに対応している。オブジェクトはデータを交換する ことで相互に作用する（ポインタ-リンクを介して）。これらのオブジェクトのすべてのクラスとリンクは、生成されたコードで見ることができます。


スクロールバーは、必要なとき（要素が収まらなくなったとき）に自動的に表示されます。スキームのサイズは、その境界線を「ドラッグ」することで変更できます。

 
楽しい。記事では、市販品での働き方について説明している...
 

小さな批判として

1.スクロールに工夫が必要。スクロールがおかしい。時々遅くなるか、ただ「外れる」だけだ。

2.ウィンドウにボタンがない。直感的にウィンドウを閉じようとするが、十字がない）。

3.ウィンドウをドラッグする方法にすぐに気づかなかった。一度押してから長押しする必要がある。単純な移動ハンドルがあればもっと便利かもしれない。

4.ウィンドウはダイナミックだが、サイズを変更する機能は明白ではない。どこをつかめばウィンドウを引っ張ってサイズ変更できるのかが明確でない。ウィンドウのハンドルの代わりに矢印が表示されるといい。

5.5.ウィンドウをドラッグするとき、上側のハンドル（ウィンドウを持つハンドル）がチャートの上側の境界 線を越えてしまうことがある。ウィンドウを閉じることもできない。ウィンドウをチャートの上端より上に上げられないようにする必要がある。

原理的にはそれほど重要ではない。しかし

 

1.了解。スクロールは、ウィンドウのドラッグハンドルと同じです。一度押して、もう一回押してホールドするんだ。そうすればすべてうまくいく。

5.ウィンドウが表示範囲から外れてしまった場合は、メインスクロールバーを 使う必要がある。そうすれば、可視範囲に戻すことができます。

1234567891011...21
新しいコメント