Fehler, Irrtümer, Fragen - Seite 519

 
tol64:
Nennen Sie ein Beispiel für eine der vielen Aufgaben, bei denen eine mehrfache Prioritätensetzung erforderlich sein kann.

Es macht nicht viel Sinn, Beispiele aufzulisten, weil es vielleicht jetzt nicht viele davon gibt, aber viele Aufgaben werden im Laufe der Entwicklung dieses oder jenes Codes in der Zukunft auftauchen und sich als Problem und als weiteres Beispiel anhäufen. Wenn Sie jetzt nicht darum bitten, sie einzuführen, werden Sie in einem halben Jahr ohnehin das Bedürfnis danach verspüren.

Bisher ist in diesem Zusammenhang nur ein einziges, aber konkretes Problem aufgetaucht: Nach dem weichen Zeichnen von verstreuten Linien ist es nicht möglich, sich überschneidende grafische Objekte in logisch absteigender Reihenfolge ihrer Wichtigkeit (die Wichtigkeit steht in direktem Zusammenhang mit der relativen Seniorität der einzelnen Zeitrahmen) direkt aus einem Diagramm zu löschen, ohne das Kombinationsfeld"Liste der Objekte" aufzurufen. Ich möchte es so: unter allen Umständen, programmatisch (durch die Einstellung der visuellen Priorität Eigenschaft auf einen benötigten Wert) die Objekte aus verschiedenen TFs würde unter ähnlichen gruppiert werden (d.h. nicht unbedingt durch Überlappung, sondern auch durch Quetschung zwischen ihnen) in aufsteigender Reihenfolge der Bedeutung, so dass die oberste wäre die wichtigste, und bei der manuellen Parsing in umgekehrter Reihenfolge könnte man zu weniger wichtigen in der Reihenfolge zu bekommen. Und all dies würde auf wissenschaftliche Weise geschehen, mit der Programmierung einer sequentiellen Abstufung durch eine Eigenschaft, und nicht mit Tricks, wie z.B. wer später erstellt wurde und wer an der Spitze steht (denn bei Aufgaben der grafischen Gestaltung gibt es viele Fälle, in denen Objekte aus verschiedenen TFs nicht in einer strikten, geraden Reihenfolge generiert werden, sondern nur ein Durcheinander), was zu Chaos in der visuellen Vorrangstellung führt. Und auch OBJPROP_ZORDER hilft hier nicht weiter, denn die programmatische Einstellung der Zugriffsreihenfolge auf ein Objekt sorgt nur für eine Priorität bei der Auswahl mit der Maus, aber das gewünschte Objekt wird oft durch das oberste überschrieben, was man aber sofort sehen will, ohne tief in Unterfenster wie "Objekteigenschaften" etc. zu gehen. Denn je angenehmer die Arbeit mit einer grafischen Oberfläche ist, desto übersichtlicher ist sie und desto weniger muss man tun, um etwas herauszufinden oder eine letzte - gezielte - Manipulation mit ihr vorzunehmen.

 
papaklass:
Und warum können wir Objekte nicht vergleichen? Die Linien auf verschiedenen TFs haben einen bestimmten Preis. Vergleichen Sie also den Preis. Wenn die Preise gleich sind, dann ziehen Sie die (Ihrer Meinung nach) wichtigste Linie. Dies wird die Prioritätensetzung sein.

Zunächst möchte ich Sie darauf hinweisen, dass zum Beispiel ein Objekt wie die Vertikale Linie keinen Preis hat. Es gibt nur die Zeit. Wenn jedoch beide Linien die gleiche Zeit haben und von verschiedenen Zeitrahmen stammen, könnte die Linie des jüngsten Zeitrahmens zuletzt gesetzt werden und die Linie des älteren Zeitrahmens optisch überlagern. Natürlich ist es möglich, Objekte zu benennen (z. B. durch Hinzufügen des Zeitrahmennamens am Ende des Objektnamens) und sie dann zu vergleichen, aber das hilft nur bei der Suche nach angehefteten Objekten und nicht in der Reihenfolge ihrer ursprünglichen Positionierung.

Es gibt also vorerst nichts, um die Sichtbarkeitspriorität einfach und schön nach dem Willen des Benutzers und nicht nach dem Diktat objektiver Umstände auf dem Markt einzustellen, noch dazu bei gleichzeitigem "zufälligen" Abhören verschiedener TFs.

 
papaklass:
Können Sie die Zeiten nicht vergleichen?
Es ist das Gleiche!
 
x100intraday:

Da sie nicht passt, bezieht sich diese Eigenschaft auf den Aspekt der Auswahl eines grafischen Objekts mit der Maus und nicht auf die Reihenfolge, in der es gerendert wird.

Dann schlage ich vor, eine Anfrage an die CD zu schreiben, denn imho sollte die Reihenfolge der Auswahl mit der Reihenfolge der Visualisierung übereinstimmen - sonst ist es völlig unintuitiv. Ausgewählt werden sollte das, was sich auf der "Oberfläche" befindet. Die Z-Reihenfolge ist angeblich dazu da, dass Objekte ihre Priorität von der Reihenfolge, in der sie erstellt werden, "abkoppeln" können.
 
marketeer:
Dann schlage ich vor, eine Anfrage an den SR zu schreiben, denn imho sollte die Reihenfolge der Auswahl mit der Reihenfolge der Visualisierung übereinstimmen - sonst ist es völlig kontraintuitiv. Was hervorgehoben werden sollte, ist das, was sich an der "Oberfläche" befindet. Die Z-Reihenfolge soll dazu dienen, dass Objekte ihre Priorität von der Erstellungsreihenfolge "abkoppeln" können.
Auch hier ist die Auswahlmöglichkeit für Sie kein Problem, und Sie können sie als Priorität festlegen. Die Rendering-Priorität ist schlecht. Und "die Reihenfolge der Auswahl sollte mit der Reihenfolge der Wiedergabe übereinstimmen" ist eine zweifelhafte Schlussfolgerung. Die Ordnung von irgendetwas verdankt sich niemandem von selbst. Es sollte möglich sein, nach dem Ermessen des Benutzers Objekten, die dies für eine einfache Wahrnehmung/Zugang/Handhabung/etc. benötigen, eine beliebige Priorität zuzuweisen. Vielleicht gibt es einen Verrückten, der in einem Zwischengeschoss wohnt und mit seinen Flossen am Kopf schläft - die offensichtliche Reihenfolge wird für ihn nicht funktionieren, aber für diesen Verrückten sollte es auch eine Option geben, Objekte nach seinem Ermessen zu priorisieren.
 
papaklass:
Das Problem besteht meines Erachtens darin, dass die eine Leitung die andere blockiert. Sie müssen Prioritäten setzen, um die (für Sie) wichtige Linie in den Vordergrund zu rücken. Wenn die Zeiten aller Zeilen unterschiedlich sind, spielt die Priorität keine Rolle, da sich die Zeilen nicht überschneiden. Sie interessieren sich für die Zeitpunkte, an denen sich die Linien überschneiden. Das ist der Punkt, an dem du zählst - die Zeiten der Zeilen, wenn die Zeiten gleich sind. Oder habe ich Ihr Problem missverstanden?
Jetzt ist alles richtig, außer "Highlight". Nicht das Hervorheben, sondern das gezielte Sehen, da die obersten überlappenden Objekte verworfen werden. Beim visuellen und manuellenHandel mit Fibo-Zeitzonen muss der Händler beispielsweise nichts hervorheben, sondern nur sehen, welche Linien übergeordnet und welche von geringerer Bedeutung sind. Und der Indikator ist ein Dummkopf, er weiß nicht, welcher zuerst und welcher später eingeordnet werden soll, denn kritische Daten aus Zeitrahmen kommen unerwartet, Indikatoren und Markierungen werden neu aufgebaut, daher erhält das Diagramm unregelmäßige Daten, die eine gewaltsame Anordnung erfordern.
 
x100intraday:
Auch hier ist die Hervorhebung gut und die Priorität kann eingestellt werden. Die Rendering-Priorität ist schlecht. Und "die Reihenfolge der Auswahl sollte mit der Reihenfolge der Wiedergabe übereinstimmen" ist eine zweifelhafte Schlussfolgerung. Die Ordnung von irgendetwas verdankt sich niemandem von selbst. Es sollte möglich sein, nach dem Ermessen des Benutzers Objekten, die dies für eine einfache Wahrnehmung/Zugang/Handhabung/etc. benötigen, eine beliebige Priorität zuzuweisen. Vielleicht gibt es einen Spinner, der auf einem Zwischengeschoss wohnt und mit herunterhängenden Flossen schläft - für ihn wird die offensichtliche Reihenfolge nicht funktionieren, aber für diesen Spinner sollte es auch eine Möglichkeit geben, das Objekt mit der höchsten Priorität einzustellen, das er für am logischsten hält.

Warum "wieder"? Verstehen Sie es selbst nicht? Ich habe eine funktionierende Version vorgeschlagen, die einzig logische: zorder ändert die Reihenfolge von Auswahl und Sichtbarkeit, denn niemand würde auf die Idee kommen, etwas auszuwählen, das unter normalen Bedingungen nicht sichtbar ist. Wenn es nicht offensichtlich ist - versuchen Sie ruhig, "Gewichte", "Prioritäten" und andere fehlende Funktionen zu fördern.

 
marketeer:

Ich habe eine praktikable Option vorgeschlagen, die einzig logische: zorder ändert sowohl die Reihenfolge der Auswahl als auch die Sichtbarkeit, denn niemand würde auf die Idee kommen, etwas auszuwählen, das normalerweise nicht sichtbar ist.

Es wäre durchaus logisch, einer Eigenschaft in Verbindung mit der Sichtbarkeit eine Auswahlpriorität zuzuweisen. Hauptsache, sie wird umgesetzt.
 

Zwischengespeicherte Indikatoren wollen im Prinzip nicht neu berechnet werden, wenn ein externer Parameter geändert wird.

Beispiel: Ich lasse den Indikator mit Parameter A laufen, erhalte die Daten, ändere den Parameter von A auf B, die Daten ändern sich nicht, ich entferne den Indikator.

Führen Sie den Indikator mit Parameter B aus. Die Daten sind dieselben wie bei Parameter A.

Ich lösche den Indikator, schließe das Terminal und warte, bis der Prozess beendet ist.

Terminal öffnen, Anzeige mit Parameter B sofort starten.

Ich erhalte (korrekte Berechnung für Parameter B) völlig andere Daten.

 
Mit Stand von heute 16.09.2011 habe ich 496 build/dated 25.08.11/ und angeblich ist 507 bereits verfügbar - warum wird es nicht rechtzeitig aktualisiert?