Erreurs, bugs, questions - page 2189

[Aleksey Vyazmikin]

Si le script est appelé souvent - à plusieurs reprises après l'exécution - le décalage horaire cesse de fonctionner, c'est-à-dire que les commandes pour cette action sont sautées

   long handle=ChartID(); 
   if(handle>0) // если получилось, дополнительно настроим 
     { 
      ChartNavigate(handle,CHART_END,-2000); 
     } 

[Artyom Trishkin]

Aleksey Vyazmikin:

Si le script est appelé souvent - à plusieurs reprises après l'exécution - le décalage horaire cesse de fonctionner, c'est-à-dire que les commandes pour cette action sont sautées

Il s'agit d'une commande asynchrone.

[Aleksey Vyazmikin]

Artyom Trishkin:
Il s'agit d'une commande asynchrone.

Alors comment vérifier qu'il fonctionne ?

[Artyom Trishkin]

Aleksey Vyazmikin:

Alors comment vérifier que ça marche ?

Par le fait du déplacement.

[Aleksey Vyazmikin]

Artyom Trishkin:
Sur le fait du déplacement.

Je vois, c'est-à-dire que la suggestion est d'attendre le décalage, s'il ne se produit pas, alors répéter la commande de décalage, n'est-ce pas ?

[Artyom Trishkin]

Aleksey Vyazmikin:

Je vois, donc la suggestion est d'attendre le décalage, et si cela ne se produit pas, de répéter la commande de décalage, n'est-ce pas ?

Nous devons réfléchir à la manière de prendre en charge le déclenchement de commandes asynchrones et aux pièges à éviter.

Supposons que nous ayons un certain nombre de barres visibles avant de lancer une commande - nous les mémorisons. Jusqu'à ce que le nombre change, la commande n'a pas fonctionné. Quand ça change, ça marche.

Et si elle n'est pas modifiée ? Quand décidez-vous que la commande est perdue dans la file d'attente et répétez la commande ? Et si, après avoir répété la commande, la précédente a fonctionné et que nous en avons une autre en attente, il y aura une équipe supplémentaire.

En général, nous devons expérimenter. Je ne peux pas penser à tout en même temps...

[Aleksey Vyazmikin]

Artyom Trishkin:

Vous devez réfléchir à la manière de prendre en charge le déclenchement de commandes asynchrones et aux pièges à éviter.

Disons que nous avons un nombre de barres visibles avant que l'ordre ne soit donné - nous l'avons mémorisé. Jusqu'à ce que le nombre change, la commande n'a pas fonctionné. Quand ça change, ça marche.

Et si elle n'est pas modifiée ? Quand décidez-vous que la commande est perdue dans la file d'attente et répétez la commande ? Et si après avoir répété la commande, la commande précédente a fonctionné, et que nous en avons une autre dans la file d'attente - ce sera une équipe supplémentaire.

Eh bien, ça va demander un peu d'expérimentation. Je n'arrive pas à en trouver un tout de suite...

Compris - affaire difficile - je vais y réfléchir, merci.

[Artyom Trishkin]

Aleksey Vyazmikin:

Compris - affaire difficile - je vais y réfléchir, merci.

Si vous vous basez uniquement sur le fait du décalage, le graphique peut aussi être décalé à la main - c'est un trou dans la logique...

[Alexey Viktorov]

Artyom Trishkin:

Si vous vous fiez uniquement au déplacement, le graphique peut aussi être déplacé à la main - il y a un trou dans la logique...

Après trois minutes d'expérimentation, j'en suis arrivé à la conclusion que le décalage vient de...

et non à partir de la position actuelle.

[Artyom Trishkin]

Alexey Viktorov:

Après trois minutes d'expérimentation, je suis arrivé à la conclusion que le déplacement provient de

et non à partir de la position actuelle.

Et alors ? Le nombre de barres visibles change. Il serait préférable de vérifier quand le graphique se déplace avec la souris. Vous pouvez l'attraper. Et s'il y a un déplacement du graphique avec l'action de la souris, alors ce n'est pas une fonction.