エラー、バグ、質問 - ページ 519

新しいコメント
 
tol64:
複数の優先順位付けが必要とされる多くのタスクの例を挙げてください。

今はまだ少ないかもしれないが、今後このコードやあのコードを開発する過程で多くのタスクが発生し、問題として、また別の例として蓄積されていくだろうから、例を挙げることにあまり意味はない。今、導入をお願いしなくても、どうせ半年もすれば必要性を感じるはずです。

それは、ソフト的に線を引いた後、重なったオブジェクトを重要度の高い順に削除することができないことです（重要度は、各タイムフレームの相対的な重要度に直接関係します）。どんな状況でも、プログラム的に（視覚的優先度プロパティを必要な値に設定することによって）、異なるTFからのオブジェクトは、類似したもの（つまり、必ずしも重なるだけでなく、それらの間に挟まることによっても）重要性の昇順でグループ化され、最上位が最も重要で、逆順の手動解析では、重要でないものから順に取得できるようにしたいのですが、このようにするとよいでしょうか？そして、これらはすべて、誰が後から作ったか、誰がそれを頂点とするかといったトリックではなく、プロパティによる厳密な連続グラデーションの設定によって、科学的に行われるでしょう（グラフィカル・マークアップ問題では、異なるTFからのオブジェクトが厳密な直接順序ではなく、めちゃくちゃに生成されているケースが多いため）、その結果、視覚的プライオリティはカオスになるのです。また、OBJPROP_ZORDERもここでは役に立ちません。なぜなら、プログラムによるオブジェクトへのアクセス順の設定は、マウスによる選択の優先度を提供するだけで、必要なオブジェクトはしばしば上位のものに上書きされますが、「オブジェクトプロパティ」などのサブウィンドウに深く入らずに、すぐに確認したいものだからです。結局のところ、グラフィカル・インターフェースで作業するのが快適であればあるほど、それが明確になり、何かを発見したり、最終的な-目的を持った-操作を行う必要がなくなるのです。

 
papaklass:
また、なぜモノを比較することができないのか？異なるTFのラインは価格が確定しています。だから、価格を比較する。もし価格が同じなら、最も重要な（あなたの考える）線を引いてください。これが優先順位になります。

そもそも、例えばバーティカルラインの ようなモノには値段がついていないことをお伝えしたいのです。あるのは時間だけです。しかし、両方のラインが同じ時間で、異なる時間枠から設定されている場合、最も若い時間枠からのラインが最後に設定され、視覚的に古いものからのラインと重なる可能性があります。もちろん、オブジェクトに名前を付けて（例えば、オブジェクト名の最後にタイムフレーム名を付けるなど）比較することは可能ですが、ピン留めされたオブジェクトの検索以外は役に立たず、初期位置の順にはならないかもしれません。

そのため、当面は、ユーザーの意志で、市場の客観的な状況の指示ではなく、シンプルかつ美しく可視性の優先順位を設定することはありません。さらに、異なるTFを聞く同時「ランダム」市場でも。

 
papaklass:
タイムを比較することはできないのですか？
同じです!
 
x100intraday:

合わないため、このプロパティはマウスでグラフィカルオブジェクトを選択する様子に関連し、レンダリングされる順序には関係しない。

なぜなら、選択する順番とビジュアライズの順番は一致させるべきで、そうでなければ、まったく直感的に理解できないからです。選ぶべきは、「表面」にあるもの。Zorderは、オブジェクトが作成された順番から優先順位を「アンバインド」するために存在すると考えられています。
 
marketeer:
というのも、選択順と可視化順は同じであるべきで、そうでなければ完全に直感に反してしまうからです。強調すべきは、「表面」にあるものです。zorderは、オブジェクトが作成順から優先順位を「アンバインド」できるようにするために存在するはずです。
もう一度言いますが、選択性で構わないので、優先的に設定してください。レンダリング優先順位が悪い。また、「選択順とレンダリング順は一致するはずだ」というのは怪しい結論です。何かの秩序は、それ自体では誰にも何の負い目もない。知覚／アクセス／操作などを容易にするために必要なオブジェクトには、ユーザーの判断で任意の優先順位を設定できるようにすべきです。中二階に住んでいて、ヒレを頭からぶら下げて寝ている変な人がいるかもしれません。その人には、当たり前の順番は通用しませんが、その変な人のために、自分の好きなようにオブジェクトの優先順位を決めるオプションも用意しておくといいでしょう。
 
papaklass:
私の理解では、一方のラインが他方のラインをブロックしていることが問題なのです。自分にとって）重要なラインを前面に押し出すためには、優先順位付けが必要です。すべての線の時間が異なる場合、線が重ならないので、優先順位は重要ではありません。線が重なる時間帯に興味があるのですね。それはあなたの数え方のポイントである、時刻が同じ時の行の時刻です。それとも、私があなたの問題を誤解していたのでしょうか？
これで、「ハイライト」以外はすべて正しく表示されるようになりました。ハイライトではなく、具体的には上に重なっているオブジェクトが破棄されるように見ています。例えば、フィボ・タイムゾーンを視覚的かつ手動で取引 する場合、トレーダーは何も強調する必要はなく、どのラインが優れていて、どのラインが重要度が浅いかを確認するだけでよい。そして、インジケータは間抜けなもので、どれを先に並べて、どれを後に並べればいいのかわからない。タイムフレームからの重要なデータが突然やってきて、インジケータやレイアウトが再構築され、したがって、チャートは激しい順序付けを要する不規則なデータを受け取るからである。
 
x100intraday:
今回もハイライト表示は問題なく、優先順位も設定できる。レンダリング優先順位が悪い。また、「選択順とレンダリング順を一致させるべき」というのは、怪しい結論です。何かの秩序は、それ自体では誰にも何の負い目もない。知覚／アクセス／操作などを容易にするために必要なオブジェクトには、ユーザーの判断で任意の優先順位を設定できるようにすべきです。中二階に住んでいて、ヒレを頭からぶら下げて寝ている変人がいるかもしれません。このような人には、当たり前の順番は通用しませんが、この変人には、自分が最も理にかなっていると思う優先オブジェクトを設定する方法もあるはずです。

なぜ「また」なのか？自分ではわからないのか？私は、唯一論理的な作業バージョンを提案しました。zorderは、選択と可視性の順序を変更します。通常の状態では、見えないものを選択しようとは誰も思わないからです。もしそれが明白でないのなら - どうぞ、「重み」「優先順位」など不足している機能を推進してみてください。

 
marketeer:

私は、唯一論理的な、実行可能な選択肢を提案しました。zorderは、選択順序と可視性の両方を変更します。なぜなら、通常は見えないものを選択しようとは誰も思わないからです。

視認性と連動して、あるプロパティに選択優先権を付与することは、極めて論理的である。ただ、それが実装されていればいいんです。
 

キャッシュされたインジケータは、原則として外部パラメータを変更した際に再計算されることを望んでいません。

例）パラメータAでインジケータを実行し、データを取得、パラメータをAからBに変更してもデータに変化がないので、インジケータを削除した。

パラメータBでインジケータを実行すると、データはパラメータAと同じになります。

インジケータを削除し、ターミナルを閉じ、プロセスが終了するまで待ちます。

ターミナルを開き、パラメータBでインジケータを一旦起動します。

パラメータBを正しく計算すると）全く異なるデータが得られる。

 
2011年9月16日現在、496 build/dated 25.08.11/を持っていますが、507はすでに利用可能なはずです。なぜ更新が間に合わないのでしょうか？
1...512513514515516517518519520521522523524525526...3185
新しいコメント