Minuterie - page 6

 
Yurich:
Une interruption se produit lorsque OnTick est en cours d'exécution et qu'un événement plus important, tel que OnTimer, est arrivé. OnTick est mis en pause, le code OnTimer est exécuté, puis OnTick reprend son cours.
Oh, mon Dieu. C'est un rêve terrible.
 
pusheax:

OnTimer, OnTick, OnTrade... Ce sont les interruptions.

C'est ce que j'ai pensé au début. Mais il existe des variantes. Par exemple, nous ne pouvons pas marquer un OnTimer avec le mot interruptions et savoir qu'il sera appelé précisément au moment de l'occurrence de l'événement en interrompant le traitement de tout autre événement (selon le schéma à un seul fil de MSDOS - sauvegarder la pile, gérer les interruptions, récupérer la pile, passer le contrôle). Un tel schéma pourrait résoudre de nombreux problèmes en utilisant des méthodes plus simples. Par exemple, OnTick, appelé par ce schéma, est plutôt joli. Il y a des subtilités ici - le traitement des entrées répétées sera nécessaire (par exemple, deux ticks avec un petit écart), mais c'est soluble en général.
 
TheXpert:
Putain de merde. C'est un mauvais rêve.
En fait, Yurich a décrit les interruptions au sens classique du terme, pas la gestion des interruptions OnTick, OnTimer.
 
Par exemple, si quelqu'un définit Sleep(100000) dans le gestionnaire OnTick ; alors maintenantOnTimer, OnTrade n'ont aucune vie ?
 
TheXpert:
C'est dommage. Oui, c'est un rêve effrayant.

Non, ce n'est pas effrayant. Il existe d'anciens schémas testés et éprouvés pour éviter la frange.

Mais c'est toujours un rêve. Je ne crois pas que les développeurs le feront. Bien que les avantages soient indéniables.

Je pourrais, par exemple, exécuter des calculs en arrière-plan dans OnTimer, avec une petite fréquence (environ une fois toutes les 5 secondes) pendant la moitié de la période de la minuterie. Et il n'y aurait pas besoin de s'inquiéter de la gestion des ticks, qui pourraient simplement interrompre le calcul en arrière-plan, puis le remettre correctement à sa place. Et maintenant, il est plus facile de le mettre sur un graphique séparé que de le traiter correctement dans le même fil de discussion dans lequel les tics sont en train de s'enchaîner. Bien qu'il y aurait assez de temps pour tous dans le même fil.

 
pusheax:
Par exemple, si quelqu'un met Sleep(100000) ; dans le handler OnTick, est-ce queOnTimer et OnTrade n'ont aucune vie du tout ?

Les événements provenant de la minuterie et des nouveaux ticks seront ignorés. L'événement de transaction restera dans la file d'attente et sera traité.

Ne pas confondre les événements Tick, Trade et Timer et leurs gestionnaires OnTick, OnTrade et OnTimer.

 
pusheax:
Par exemple, si quelqu'un met Sleep(100000) ; dans le handler OnTick, qu'est-ce queOnTimer, OnTrade n'auront pas de vie du tout ?
Pour l'instant, c'est exactement ce que c'est. Mais le suicide n'est pas une chose difficile. C'est pire, quand il y a une boîte à messages sur mon écran, et que je suis en train de boire du thé dans la cuisine. Yurich soulève un bon point.
 
stringo:
En fait, Yurich a décrit l'interruption au sens classique du terme, pas la gestion des interruptions OnTick, OnTimer.

Je comprends ce qu'il a décrit.

Synchroniser les données et perturber l'accès dans une application monofilaire est le comble de l'idiotie.

 
MetaDriver:
C'est comme ça que ça se passe en ce moment. Mais le suicide n'est pas difficile. C'est pire quand il y a une boîte de messages sur l'écran et que je suis dans la cuisine en train de boire du thé. Yurich soulève un bon point.
Ah, maintenant je comprends, l'événement Timer lui-même se produira mais son traitement OnTimer sera retardé jusqu'à ce que OnTick soit terminé.
Документация по MQL5: Программы MQL5 / События клиентского терминала
Документация по MQL5: Программы MQL5 / События клиентского терминала
  • www.mql5.com
Программы MQL5 / События клиентского терминала - Документация по MQL5
 
pusheax:
C'est probablement comme ça que ça marche.
Si seulement :)
Raison: