Programmazione asincrona e multithread in MQL - pagina 25
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
Ho iniziato a rileggere l'argomento e Igor aveva già scritto su questo.
Questo è quello che stavo cercando di dire, Yuri, che abbiamo bisogno di allocare la memoria e registrare il flusso.
Igor dice che è necessario allocare e registrare, mentre tu dici che non devi fare nulla.
Ecco perché mi gira la testa. Il risultato è uno stallo.
Igor ha studiato all'università come specialista, e dovrebbe capirne di più di noi autodidatti.
Fin dall'inizio ero incline alla stessa idea - che la memoria deve essere allocata e inizializzata.
L'inizializzazione e l'allocazione della memoria è la chiave per una corretta codifica, perché non deve scorrere e non deve essere spazzatura.
Quindi la mia domanda a Igor, per favore, spiega come farlo in C++?
Non a parole, con un esempio, non ci capisco niente ))
BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } return TRUE; }Ho iniziato a rileggere l'argomento e Igor ha già scritto su questo.
È quello che stavo cercando di dire, Yuri, che dovremmo allocare la memoria e registrare il flusso.
Ho iniziato a rileggere il thread e Igor ne aveva già scritto.
Inizialmente ero incline alla stessa idea: allocare la memoria e inizializzare.
L'inizializzazione e l'allocazione della memoria è la chiave per una corretta codifica, perché non deve gocciolare e non deve avere rifiuti.
Quindi la mia domanda a Igor, spiega per favore come farlo in C++?
Stai magistralmente spingendo questo thread in cima alla discussione, cercando di attirare sempre più partecipanti al tuo problema ))))
Non prendere la corrispondenza fuori dal contesto:
- L'ho scritto nel contesto che se volete capire come funziona WinAPI, potete usare esempi già pronti sulla scrittura di dll = oltre 20 articoli su questa risorsa
- L'ho scritto in un contesto in cui si può arrivare a chiamate WinAPI pure, sostituendo i plugin che i programmatori di sistema hanno già scritto per voi
....
il punto della corrispondenza: iniziare a leggere e fare qualcosa, non scrivere e scrivere.... Capirete molto, capirete cosa e come funziona in Windows, ma questa conoscenza non sarà richiesta, davoi come dal programmatore di applicazioni solo lavoro meccanico - scelto il tipo di progetto, aggiunto il vostro codice, compilato = ottenuto il risultato - tutto il lavoro per voi hanno fatto centinaia o migliaia di programmatori di sistema. Qualsiasi modifica dei template e dei file include deve avere un senso - se non lo sai, con la scusa del "perché tanto codice, funziona già!" - Otterrete un bug non riproducibile e/o la mancanza di compatibilità OS/PC
Il post è per i creatori. Via i troll. Per le GUI, è bene mettere l'OnChartEvent in un thread separato.
Perché rompere il modello creato dagli sviluppatori? - Il modello del programma MQL è semplice e chiaro, ci sono eventi - ci sono punti di ingresso che processano questi eventi (OnTick(),OnInit()....OnChartEvent() )
c'è la possibilità di ottenere lo stato dell'ambiente di trading da qualsiasi programma MQL (anche gli indicatori possono vedere il profitto di un ordine aperto, ecc.) ed è possibile combinare Expert Advisor+script, Expert Advisor+indicatore utente sullo stesso grafico - si ottiene l'esecuzione asincrona dei programmi MQL, l'EA fa trading, l'indicatore visualizza la visualizzazione grafica - se le prestazionidel flusso degliindicatori utente non sono sufficienti (lavorano in un thread), allora naturalmente è un problema - è necessario utilizzare 2 EA su 2 grafici e organizzare l'interazione di essi
di nuovo - c'è un compito specifico, c'è un'implementazione, ho chiesto molte volte perché questa caratteristica è necessaria, ma finora non c'è una risposta - solo un ragionamento spaziale sulla visualizzazione 3D.... e non c'è nessuna discussione su dove ottenere delle DirectX per lavorare con il 3D ;)
imho, funziona! )))
Perché rompere il modello creato dagli sviluppatori? - Il modello del programma MQL è semplice e chiaro, ci sono eventi - ci sono punti di ingresso che processano questi eventi (OnTick(),OnInit()....OnChartEvent() )
c'è la possibilità di ottenere lo stato dell'ambiente di trading da qualsiasi programma MQL (anche gli indicatori possono vedere il profitto di un ordine aperto, ecc.) ed è possibile combinare Expert Advisor+script, Expert Advisor+indicatore utente sullo stesso grafico - si ottiene l'esecuzione asincrona dei programmi MQL, l'EA fa trading, l'indicatore visualizza la visualizzazione grafica - se le prestazionidel flusso degliindicatori utente non sono sufficienti (lavorano in un thread), allora naturalmente è un problema - è necessario utilizzare 2 EA su 2 grafici e organizzare l'interazione di essi
di nuovo - c'è un compito specifico, c'è un'implementazione, ho chiesto molte volte perché questa caratteristica è necessaria, ma finora non c'è una risposta - solo un ragionamento spaziale sulla visualizzazione 3D.... e non c'è nessuna discussione su dove ottenere delle DirectX per lavorare con il 3D ;)
imho, funziona! )))
Guarda. C'è un pulsante. Tu lo clicchi. L'OnChartEvent si mette in coda. Ma in questa coda c'è già OnTick, e a seguire c'è OnTime, e in essi c'è CopyRate per tutti gli strumenti, che, per un secondo, si blocca e va in loop per un mucchio di iterazioni del cazzo. Di conseguenza, se il pulsante, per esempio, deve aprire una finestra di dialogo, si ottiene un'interfaccia lenta. Non critico, naturalmente, ma non bello.
La GUI dovrebbe girare nell'EA principale e tutto il resto in un EA separato. Questo slave EA separato è posto suOBJ_CHART invisibile e interagisce con il percorso principale EventSendCustom().
Diventa qualcosa come un multithreading. L'ho implementato in questo modo.
Guarda. C'è un pulsante. Tu lo clicchi. OnChartEvent viene messo in coda. Ma in questa coda c'è già OnTick, e a seguire c'è OnTime, e in essi c'è CopyRate per tutti gli strumenti, che, per un secondo, si blocca e va in loop per un mucchio di iterazioni del cazzo. Di conseguenza, se il pulsante, per esempio, deve aprire una finestra di dialogo, si ottiene un'interfaccia lenta. Non critico, naturalmente, ma non bello.
Non conosco OnChartEvent OnTick e OnTime, ma gli sviluppatori hanno scritto che se EA era occupata e non ha elaborato l'evento, questo evento non crea una coda, cioè sarà solo un tick o un timer saltato ( OnChartEvent - non so, non ho controllato)
La logica degli sviluppatori è semplice qui, ogni evento è un'azione specifica dell'Expert Advisor, ma è questo evento che conosco con certezza e che ho controllato più di una volta (lavoro più in teoria in MT5, non so come funziona fisicamente ONTick):
Per quanto riguarda MT4 dirò in modo inequivocabile: tutte le operazioni di trading dovrebbero essere fatte solo attraverso tick in entrata, altrimenti in 9 casi su 10 si riceverà il rifiuto del server di elaborare le operazioni di trading,
cioè è stata implementata un'interfaccia con il pulsante BUY - secondo la nostra idea, si preme BUY e si invia immediatamente un ordine, ma non funzionerà direttamente, è necessario ricordare il comando dell'utente (idealmente, bloccare il pulsante in modo che non faccia yak)) e all'arrivo del tick, in OnTick() - inviare un ordine al server - questo funzionerà nel 99% dei casi, cioè è arrivato un tick - è possibile eseguire una richiesta di trade (non da nessuna parte in MQL)
E se introduciamo OnChartEvent in un flusso asincrono, otterremo blocchi reciproci del codice eseguito? - Per esempio, le statistiche di trading sono ottenute premendo il pulsante in OnChartEvent , e la stessa funzione (ultimo trade perdente) è usata in OnTick - sarà qualcosa di serio! - imho, non si può aggiustare tutto!
La GUI dovrebbe girare nell'EA principale e tutto il resto in un EA separato. Questo slave EA separato è posto suOBJ_CHART invisibile e interagisce con il percorso principale EventSendCustom().
Diventa qualcosa come un multithreading. L'ho implementato in questo modo.
Non conosco OnChartEvent OnTick e OnTime, ma gli sviluppatori hanno scritto che se EA era occupata e non ha elaborato l'evento, questo evento non crea una coda, cioè sarà solo un tick o un timer saltato ( OnChartEvent - non so, non ho controllato)
La logica degli sviluppatori è semplice qui, ogni evento è un'azione specifica dell'Expert Advisor, ma è questo evento che conosco con certezza e che ho controllato più di una volta (lavoro più in teoria in MT5, non so come funziona fisicamente ONTick):
Per quanto riguarda MT4 dirò in modo inequivocabile: tutte le operazioni di trading dovrebbero essere fatte solo attraverso tick in entrata, altrimenti in 9 casi su 10 si riceverà il rifiuto del server di elaborare le operazioni di trading,
cioè ho creato un'interfaccia con il pulsante BUY - secondo la mia idea, si preme BUY e immediatamente si invia un ordine, ma non funzionerà direttamente, è necessario memorizzare il comando dell'utente (idealmente, bloccare il pulsante in modo che non yak)) e all'arrivo di un tick in OnTick () - inviare un ordine al server - questo funzionerà nel 99% dei casi, cioè un tick è venuto - è possibile eseguire una richiesta di commercio (non da nessuna parte in MQL)
E se introduciamo OnChartEvent in un flusso asincrono, otterremo blocchi reciproci del codice eseguito? - Per esempio, le statistiche di trading sono ottenute premendo il pulsante in OnChartEvent , e la stessa funzione (ultimo trade perdente) è usata in OnTick - sarà qualcosa di serio! - imho, non si può aggiustare tutto!