Canvasでクラウドソーシングのプロジェクトを作る - ページ 4

新しいコメント
 
Vasiliy Sokolov:

アナトリーの記事の後、またプロフィールに同じ卵を作るのは、少なくとも変な娯楽だと思われるのですが。グラフィックは、MTではまったく話題になりません。

  • ユーザーにはグラフィカルなインターフェースは必要ない。その結果、GUIを監視することは不可能であり、その開発は決して報われることはないでしょう。
  • スキルを上げたいのであれば、すぐにどこか後輩に就職したほうがいい。だから、少なくとも、すぐにでもお金を稼ぎ始めて、少しずつスキルを上げていくことができる。
  • ターゲット層が狭すぎる。誰が図書館を必要としているのか？- 一握りのプログラマーを除いては、絶対に誰もいませんし、彼らは必要なライブラリはとっくにすべて書き終えているのです。例えば、私は自分のグラフィックライブラリを2つ持っています。

この場にいる人たちに教えるつもりはないが、いくつかアドバイスできることがある。ユーザーとの協働を学ぶ。彼らの心理を学ぶ。彼らのアイデアを監視する方法を学ぶ。そして、すぐに地に足をつけて、まったく違う方法で推論をするのです。私も、かつては特別で美しい考えを信じていましたが、このような無意味なことは、うまくいかないのです。ここで議論していることは、あなた以外の人には何の役にも立ちません。

+1

多くのトレーダーにとって必要なのは、美しさではなく、お金であり、少なくとも、月の第3相の価格計算の超スーパーテクノロジーを搭載したEAであり、それは、響きがよく、自慢でき、奇跡のテクノロジーに期待できるからです.........。

しかし、デモや実際の市場で妖精の光だけで働く人は必要ない人もいます :))) 。

 

Vladimir Pastushak:

そして、デモや現実の生活の中でしか動作しないビブルは、少数の人々が必要というか、少しバロ必要な人を必要とします)))。

もう一度言いますが、私たちはビブルを作らないんです。

私たちは問題を解決しているのです。

このスレッドは計測のためではなく、現実の問題を解決するためのものです。

ウラジミールさん、否定的な意見を言わずに観察するか、参加するか、どちらかにしてください。しかし、このスレッドでOOPや月の満ち欠けについて教わることはないでしょう。

 
o_O:

繰り返しになりますが、私たちは聖書を作るわけではありません。

私たちは問題を解決しているのです。

このスレッドは測定するためではなく、具体的な問題を解決するためのものです。

ウラジミールさん、ネガティブなコメントなしで見るか、私と一緒に見るか、どちらかです。しかし、このスレッドでOOPや月の満ち欠けについて教わることはないでしょう。

OOPの知識がないため参加できない。

私はただ、あなたの時間を節約しようとしただけです。

オブザーバー側に回る...。

 
Zorro:
入力欄の 問題は、用意されたものをどう使うか、いいアイデアがないことです。

IMHO 今はGUIキーボードを自作して初めて本格的なEDITが作れますが、言語対応は難しいでしょうし、マウスで入力するのも不便ですし...。

イベントやチャートを扱う際に、入力の邪魔にならないようにするために必要な追加機能は何ですか？

SDのリファインをお願いすることになります。

 
Vladimir Pastushak:

私は、そういうことがまったく理解できないのです。

a >> 0 << 0;                       //нет сообщения об ошибке
a.operator>>( 0 ).operator<<( 0 ); //error: правомерно 

どこをどう応用すればいいのか、全く分からないので、ドキュメントかどこかで教えてください...。

コードについて - サービスデスクにお問い合わせください。なんて言われるんだろう。教育や理解については、MQLはC++をお手本に書かれているので、関連するドキュメントに目を通してみてください、たくさんあります。基本的には、OOPに関する類似のスレッドがすでに作られていますが、そのような質問については、別のスレッドを立ち上げることができます。
 
Vasiliy Sokolov:

...グラフィックは、MTでは全く話題にならない・・・。

つまり、グラフィックだけではないのです。ここで提供されるものは、最高品質のグラフィカル・インターフェースを作成する能力を提供します。標準的なグラフィックオブジェクトのプリミティブに制限されているため、多くのことが不足していることに気付きます。また、非常に多くのグラフィックオブジェクトを 操作しなければならないので、場合によっては煩わしさを感じることもあります。

ある人は娯楽やゲームに時間を費やし、ある人は娯楽が興味深く有用なタスクの解決につながるのです。このフォーラムでは、多くの人がたわいもないおしゃべりのために時間を費やしています。

このフォーラムに参加できれば嬉しいのですが、今は自分のタスクがあります。)

 
親愛なるフォーラムのメンバーの皆さん、ここで実際に提案されている「非常に高品質な」グラフィカル・インターフェースの作成 がどのようなものなのかを理解することは非常に興味深いことです。正直なところ、まったく理解できない。
 
間違っていたら訂正しますが、課題の本質は、その詳細を絵で描くことを犠牲にして、できるだけ少ないグラフィックオブジェクトを使ってコントロールを 実装することなのでしょうか。その場合、例えばスライダーが完全に描画される場合はどうなるのでしょうか。少なくとも2つの相互作用するオブジェクトが必要です...
 
Реter Konow:

なるべく少ないグラフィックオブジェクトで

少ないどころか、まったくありません（ただし、bitmap_labelはすべての描画に使用されています）。

例えば、スライダーが完全に描画された場合、どのように機能するのでしょうか？少なくとも2つの相互作用するオブジェクトが必要です...

というのは、スライダー上のマウスのことでしょうか？

----

今のところ、ゾロ さんが書かれている、入力欄の 問題だけです。

チャートのイベントでは、すべてのキーコードが表示されません。 また、チャートはスペースキーとエンターキーを遮断します。

 
o_O:

が小さくなるどころか、まったくなくなってしまいました（すべてが描画されるbitmap_labelは除く）。

というのは、スライダー上でマウスが押された状態のことでしょうか？

----

今のところ、Zorro さんが書かれている、入力欄という 問題だけがあります。

チャートのイベントには、すべてのキーコードが表示されません。 また、チャートはスペースキーとエンターキーを遮断します。

マウスのことはあまり関係ありません。

基本的に「スライダー」コントロールの仕組みが理解できて いないので、完全に描画されています。

スライダーの主な機能は、2点A、B間の距離を、与えられた比率とステップを使用してカスタムパラメータの値に変換することです。

私の実装では、点Aと点Bは、スライダートラックのX座標（その原点）とスライダースライドのX座標という2つのオブジェクトの位置で表現されます。この関数は，2点間の距離を測定し，パラメータ値に変換する。

両者を合成して撮影した場合、A点とB点の位置関係はどうなるのでしょうか？この場合、これらの点はちょうど画像のピクセルになります。

点間の距離を測るために、画素はどのようにその座標を返すのでしょうか？

スライダーを動かすと、画像はどのように変化するのでしょうか？

スライダーの正確な位置（x座標に対する相対位置）をどのように返し、そのストローク限界を固定するのでしょうか？

また、スライダーがストロークの境界の外側に移動した場合、どのように位置を補正するのでしょうか。

これらの仕組みはすべて私の実装したスライダーで動作しており、この方法でオブジェクトの数を大幅に減らすことができることは理解していますが、提案されている技術は理解していません。

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