Errori, bug, domande - pagina 341
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
C'è la necessità di inviare dati pre-elaborati a un indicatore già in esecuzione. Ho deciso di usare il testo dell'oggetto grafico come memorizzazione globale dei dati. Capisco che lo scopo degli oggetti grafici è diverso e se c'è qualche alternativa, sarò felice di sentirla.
Ma qui ho affrontato un'altra limitazione della lingua. La stringa stessa supporta una lunghezza di caratteri quasi infinita. Beh, probabilmente la limitazione si trova da qualche parte nella zona di limitazione degli array in generale. E la stringa passata come parametro di un oggetto grafico è limitata a 63 caratteri. Di conseguenza, passare un array come una stringa richiederebbe un mucchio di oggetti grafici (sì, ho dimenticato di dirvi che uso la crittografia, ecco perché le informazioni nelle stringhe prendono circa la stessa quantità di spazio del tipo originale). Ora con gli attuali 63 caratteri è possibile passare solo 15 coppie tempo/prezzo attraverso un oggetto.
Da qui la domanda: possiamo aspettarci che in futuro il linguaggio rimuova la limitazione sulla lunghezza del testo dell'oggetto grafico o ci sarà un meccanismo per passare dati nel thread indicatore?
Mi sono imbattuto nello stesso problema, quando ho generato un evento personalizzato. C'è un limite di 63 simboli, non tutta la stringa....
Ho dovuto scrivere una classe separata per incollare il messaggio da slices.... funziona ))))
Mi sono imbattuto nello stesso problema quando ho generato un evento personalizzato. C'è lo stesso limite di 63 caratteri, non tutta la stringa....
Ho dovuto scrivere una classe separata per incollare il messaggio da slices.... funziona ))))
Sì, se non ci fossero restrizioni, si potrebbero usare gli eventi per inviare array di dati.
Non sono ancora in grado di provare a passare l'handle di un oggetto attraverso un evento. E l'oggetto contiene tutti i dati necessari.
Se è rilevante in questo momento, provalo e riferisci più tardi.
// Sarebbe molto interessante avere una memoria condivisa controllabile all'interno del terminale. Almeno, solo per gli oggetti e gli array.
// E quando si dichiara tale oggetto, il modificatore condiviso determinerebbe il suo posizionamento in tale memoria.
Non riesco ancora a provare a passare l'handle dell'oggetto attraverso un evento. E l'oggetto contiene tutti i dati necessari.
Se è rilevante in questo momento, fai una prova e riferisci più tardi.
// Sarebbe molto allettante avere una memoria condivisa controllabile all'interno del terminale. Almeno, solo per gli oggetti e gli array.
// E quando si dichiara tale oggetto, il modificatore condiviso definirebbe la sua posizione in tale memoria.
Una sorta di memoria terminale globale disponibile per tutti i thread.
Il valore dell'handle viene passato correttamente, ma non esiste un tale handle nel thread desiderato. Pertanto, il valore non punta più all'handle corretto.
Qualcosa come una memoria terminale globale? disponibile per tutti i thread.
La soluzione più semplice per MQ sarebbe quella di dare i parametri della funzione
come parametri di una funzione invece delle variabili, che esistono ora come parametri. La soluzione ovviamente è unilaterale, dato che non ci sarà ancora modo di trasferire i dati tra gli EA, ma è sempre meglio di niente.
1. La soluzione più semplice per MQ sarebbe quella di dare array di dati come parametri di funzione invece di variabili, che esistono come parametri ora.
2. La soluzione è ovviamente unilaterale in quanto non ci sarà ancora la possibilità di trasferire i dati tra gli EA, ma è sempre meglio di niente.
1. Sì, forse.
2. Perché non è possibile? Copiatelo a voi stessi, prendetelo. E ciò che deve essere trasferito - trasferito attraverso il prossimo messaggio.