L'iscrizione a OnBookEvent a volte cade - esiste una cosa del genere? - pagina 2
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
"basta che un esperto si disiscriva dal ricevere l'evento, e anche tutti gli altri esperti smetteranno di riceverlo"?
È solo un'ipotesi se ne vale la pena o no - nell'analogia di continuare che "basta che un EA si disiscriva dal ricevere un evento, e anche tutti gli altri EA smetteranno di riceverlo"? Non credo che possa esistere una cosa del genere, sarebbe (o è) un bug.
Per prima cosa, è facile da controllare. Lo farei io stesso, ma ho solo un account FORTS ed è chiuso nel fine settimana.
Ma se è così, la situazione si rivela divertente. Quando hai abilitato Expert Advisor e indicatore, le sottoscrizioni si sono attivate. Quando si disabilita l'Expert Advisor o l'indicatore, si è già scritto che le sottoscrizioni sono andate in crash. Questo suggerisce che la trasmissione funziona nella direzione opposta. Ora immaginate che qualcosa sia cambiato (per esempio la storia è cambiata e l'indicatore è stato ricalcolato). Ma sappiamo che OnInit e OnDeinit possono essere chiamati in modo casuale. A volte è corretto e a volte è viceversa. Cosa succede se il grafico chiama prima la nuova versione dell'indicatore e poi disinstalla quella vecchia? L'abbonamento cadrà. Ecco come sarebbe "cadere in silenzio". Vi consiglio di mettere delle stampanti in OnInit e OnDeinit per controllare la coda e il messaggio nel caso in cui le quotazioni delle azioni smettano di arrivare. Forse il problema si chiarirà.
Prima di tutto, è facile da controllare. Lo farei io stesso, ma ho solo un account su FORTS ed è chiuso nel fine settimana.
Non avete bisogno diCHARTEVENT_OBJECT_CREATE per controllare il punteggio.
Non c'è dubbio.
Non capisco. Puoi sempre mettere un contatore di link
Non capisco. Puoi sempre mettere un contatore di link
Non c'è un contatore. E se ci fosse sarebbe esplicitamente dichiarato nella documentazione circa la sua esistenza e l'ammissibilità della chiamata di coppia Add\Release solo - altrimenti il contatore sarà rotto e il significato della sua esistenza sarà perso
E se dite che avete bisogno di un contatore di riferimento... allora si potrebbe andare oltre e abolire del tutto le trasmissioni
Non c'è un contatore. E se ci fosse, sarebbe chiaramente indicato nella documentazione che esiste e che è permessa solo la chiamata accoppiata Add/Release - altrimenti il contatore sarà perso e il significato della sua esistenza sarà perso
e in questo momento la funzione di rilascio non ha senso perché la logica secondo cui chiunque può cancellarsi dal tuo evento non ha senso.
C'è un semplice suggerimento per non usare semplicemente la funzioneMarketBookRelease.
In teoria, questo sprecherebbe parte delle risorse del terminale e del server.
Ma in pratica... Ci saranno conseguenze reali da questo?
Bene, ora non ha senso la funzione di rilascio. perché la logica che chiunque può cancellarsi dal tuo evento è una logica senza senso
È inutile spiegare per i ricci, quindi scriverò per gli altri ;-).
La nozione di trasmissione di eventi è una cosa, ma i principi della chiamata a coppie delle funzioni di sottoscrizione e cancellazione di un evento è un'altra. Queste sono tecniche semanticamente indipendenti che non devono, e idealmente non dovrebbero, influenzarsi a vicenda. Lasciare che l'evento sia trasmesso (questo è stato probabilmente fatto per ragioni di efficienza, ma è molto controverso e può causare il problema attuale se implementato in modo errato). Questo significa che basta che uno si iscriva, perché tutti ricevano l'evento. Ma al contrario - uno deve cancellarsi e tutti vengono fregati - è già una specie di narrowcasting.
Del contatore di abbonati nella documentazione non si parla, anche se è molto importante (e la frase sulla trasmissione non è una spiegazione per il motivo di cui sopra). La trasmissione dovrebbe idealmente durare fino a quando il numero di abbonati non scende a 0. Altrimenti, è ovvio che i programmi MQL (compresi quelli di diversi sviluppatori) dovrebbero comunicare tra loro in qualche modo, per non danneggiare il loro lavoro, ma questa è una sciocchezza. Non conosco un solo esempio di software (in senso lato, non limitato a MT, Windows, ecc.) in cui l'abbonamento sia stato implementato in questo modo.
C'è questo passaggio su MarketBookRelease:
Обычно эта функция должна вызываться из функции OnDeinit() в том случае, если в функции OnInit() была вызвана соответствующая функция MarketBookAdd().
È, di nuovo, ambiguo. Potrebbe essere interpretato come avere il controllo sul numero di abbonamenti. Ma il software non permette interpretazioni private.
In sostanza, IMHO, l'implementazione è un rastrellamento (la verifica e l'oversubscription è richiesta a livello di MQL), la documentazione è oscura. L'affermazione che il codice maligno o del tutto cattivo può uccidere le sottoscrizioni degli altri anche con un contatore non è davvero rilevante. Tutti questi script potrebbero fare danni in un mucchio di altri posti nel terminale (ad esempio, cancellare gli oggetti di altre persone, uccidere i fermi sulle posizioni di altre persone, ecc, cosa che è già successa un milione di volte). Non ha senso parlare di queste vere e proprie manifestazioni di piggyback - non possono essere impedite da nulla se non dalla disciplina dell'utente, dalla correzione del codice degli altri utenti (se c'è) o dal controllo di una demo. Il problema ora è che il codice scritto correttamente non può essere eseguito correttamente ora.
Se facessimo questo meccanismo in modo corretto, naturalmente - il modello editore/sottoscrittore non è stato abolito. Certamente non influirebbe sull'efficienza.