Fehler, Irrtümer, Fragen - Seite 519
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
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.
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.
Können Sie die Zeiten nicht vergleichen?
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 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.
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?
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.
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.
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.