Errori, bug, domande - pagina 519
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Dare un esempio di uno dei tanti compiti in cui può essere necessaria una priorità multipla.
Non ha molto senso elencare esempi, perché forse non ce ne sono molti ora, ma molti compiti sorgeranno nel processo di sviluppo di questo o quel codice in futuro e si accumuleranno come un problema e come un altro esempio. Se non chiedete di implementarlo ora, ne sentirete comunque il bisogno tra mezzo anno.
Finora in questo filone, solo un problema, ma concreto: dopo il disegno morbido di linee sparse è impossibile cancellare manualmente gli oggetti grafici sovrapposti in ordine logico decrescente di importanza (l'importanza è direttamente correlata all'anzianità relativa di ciascuno dei timeframe) direttamente da un grafico, senza chiamare la casella combinata"Lista degli oggetti". Mi piacerebbe così: in qualsiasi circostanza, programmaticamente (impostando la proprietà visual priority a un valore necessario) gli oggetti di diversi TF sarebbero raggruppati tra quelli simili (cioè non necessariamente per sovrapposizione, ma anche per schiacciamento tra loro) in ordine crescente di importanza, in modo che il più alto sarebbe il più importante, e al parsing manuale in ordine inverso si potrebbe ottenere in ordine al meno importante. E tutto questo sarebbe fatto scientificamente, con la programmazione della classificazione sequenziale tramite proprietà, non con trucchi come chi ha creato dopo e chi lo supera (perché nei compiti di markup grafico ci sono molti casi in cui gli oggetti di diversi TF sono generati non in un rigoroso ordine dritto, ma con un casino), che porta al caos nel primato visivo. E anche OBJPROP_ZORDER non aiuterà qui, perché l'impostazione programmatica dell'ordine di accesso a un oggetto fornirà solo una priorità di selezione con il mouse, ma l'oggetto richiesto sarà spesso sovrascritto dal più alto, ma quello che si vuole vedere immediatamente, senza andare in profondità nelle sotto-finestre come "Object Properties" ecc. Dopo tutto, più è piacevole lavorare con un'interfaccia grafica, più è chiara e meno si deve fare per scoprire qualcosa o per eseguire una manipolazione finale - mirata - con essa.
E perché non possiamo confrontare gli oggetti? Le linee su diversi TF hanno un prezzo definito. Quindi confronta il prezzo. Se i prezzi sono uguali, allora traccia la linea più importante (secondo te). Questa sarà la priorità.
Per cominciare, vorrei informarvi che, per esempio, un oggetto come la linea verticale non ha prezzo. C'è solo il tempo. Ma se entrambe le linee hanno lo stesso tempo e sono impostate da diversi timeframe, la linea dal timeframe più giovane potrebbe essere impostata per ultima e sovrapporsi visivamente alla linea da quello più vecchio. Naturalmente, è possibile dare un nome agli oggetti (per esempio, aggiungendo il nome del timeframe alla fine del nome dell'oggetto) e poi confrontarli, ma può aiutare solo per la ricerca di oggetti appuntati, e non nell'ordine del loro posizionamento iniziale.
Quindi, per il momento non c'è nulla per impostare la priorità di visibilità semplicemente e splendidamente a volontà dell'utente e non a dettatura di circostanze oggettive sul mercato, per di più a mercato simultaneo "casuale" ascolto di diversi TF.
Non puoi confrontare i tempi?
Poiché non si adatta, questa proprietà si riferisce all'aspetto della selezione di un oggetto grafico con il mouse, non all'ordine in cui viene reso.
Allora suggerisco di scrivere una richiesta alla SR, perché imho l'ordine di selezione dovrebbe essere lo stesso dell'ordine di visualizzazione - altrimenti è completamente controintuitivo. Ciò che dovrebbe essere evidenziato è ciò che è sulla "superficie". Lo zorder dovrebbe essere lì in modo che gli oggetti possano "slegare" la loro priorità dall'ordine di creazione.
Il problema, da quanto ho capito, è che una linea blocca l'altra. Avete bisogno di dare delle priorità per portare in primo piano la linea che è significativa (per voi). Se i tempi di tutte le linee sono diversi, allora la priorità non è importante perché le linee non si sovrappongono. Vi interessano i tempi in cui le linee si sovrappongono. Questo è il tuo punto di conteggio: i tempi delle linee quando i tempi sono uguali. O ho capito male il tuo problema?
Ancora una volta, l'evidenziazione va bene e la priorità può essere impostata. La priorità di rendering è pessima. E "l'ordine di selezione dovrebbe corrispondere all'ordine di resa" è una conclusione dubbia. L'ordine di qualsiasi cosa non deve niente a nessuno da solo. Dovrebbe essere possibile, a discrezione dell'utente, impostare qualsiasi priorità agli oggetti che la richiedono per una facile percezione/accesso/manipolazione/ecc. Forse c'è uno strambo che vive su un mezzanino e dorme con le pinne che gli pendono dalla testa - l'ordine ovvio non funzionerà per lui, ma per questo strambo, ci dovrebbe essere anche un modo per lui di impostare qualsiasi oggetto prioritario che considera il più logico.
Perché "ancora"? Non lo capisci anche tu? Ho suggerito una versione funzionante, l'unica logica: zorder cambia l'ordine di selezione e visibilità, perché nessuno penserebbe di selezionare qualcosa che non è visibile in condizioni normali. Se non è ovvio - vai avanti e prova a promuovere "pesi", "priorità" e altre caratteristiche mancanti.
Ho suggerito un'opzione praticabile, l'unica logica: zorder cambia sia l'ordine di selezione che la visibilità, perché nessuno penserebbe di selezionare qualcosa che non è normalmente visibile.
Gli indicatori cached in linea di principio non vogliono essere ricalcolati quando viene cambiato un parametro esterno.
Esempio: eseguo l'indicatore con il parametro A, ottengo i dati, cambio il parametro da A a B, i dati non cambiano, rimuovo l'indicatore.
Esegui l'indicatore con il parametro B, i dati sono gli stessi del parametro A.
Cancello l'indicatore, chiudo il terminale, aspetto che il processo si uccida.
Aprire il terminale, avviare subito l'indicatore con il parametro B.
Ottengo (calcolo corretto per il parametro B) dati completamente diversi.