Séquence d'exécution de Init() et DeInit() - page 24

Nouveau commentaire
 
fxsaber:
L'exemple que vous avez retravaillé n'était pas parfaitement adapté au problème posé. Vous pouvez montrer un autre exemple qui n'aura pas de solution par UninitializeReason.

C'est tout, je mets fin à ce dialogue. Quel est l'intérêt de discuter des façons de se gratter l'oreille ? S'il n'y a pas d'autre solution, vous pouvez utiliser votre code, mais l'universalité n'est pas toujours la solution idéale.

Par exemple, il ne viendrait à l'idée de personne de faire appel à un bûcheron pour couper un framboisier. Votre code est donc comparable à une équipe de bûcherons pour couper un framboisier.

Salutations Alexei.

 
Je ne comprends pas, si l'ancien DeInit et le nouveau OnInit sont exécutés dans des threads différents, quel est le problème avec OnInit qui attend simplement que DeInit se produise et se termine. Utiliser une variable globale comme un sémaphore.
 
Aleksei Radchenko:
Je ne comprends pas, si l'ancien DeInit et le nouveau OnInit sont exécutés dans des threads différents, quel est le problème avec OnInit qui attend simplement que DeInit se produise et se termine. Utiliser une variable globale comme un sémaphore.
Sur un seul graphique, tous les indicateurs ne fonctionnent que sur un seul fil.
 
Alexey Viktorov:

Quel est l'intérêt d'utiliser un exemple primitif d'un double temps ?

Utilisez plutôt un exemple de code virtuellement correct.

Alexey, cet exemple a été créé pour que même un loser puisse le comprendre. C'est pourquoi j'ai écrit que c'est primitif. Désolé, il n'a pas été conçu pour les bonnes notes.

J'ai vu un petit chien aboyer aux camions qui passaient ce matin. Elle vous envoie son amour.

 
Nikolai Semko:

Alexei, cet exemple a été créé pour que même les sous-performants puissent le comprendre. C'est pourquoi j'ai écrit que c'était primitif. Désolé, il n'a pas été conçu pour les bonnes notes.

J'ai vu un chien aboyer aux camions qui passaient ce matin. Elle vous envoie son amour.

Tu aboyais avec elle ?

Que peut-on comprendre de l'exemple où il n'y a pas de vérification de l'existence de l'objet avant sa création ? Des réclamations contre les développeurs qui n'ont pas permis d'écrire n'importe comment, avec des erreurs grossières ? J'écrirai comme je le veux et les développeurs doivent me fournir toutes les conditions pour cela. Les développeurs doivent prévoir toutes les erreurs possibles que je pourrais commettre à l'avenir. C'est ça ? N'aspirez pas le problème là où il n'existe pas.

 
Alexey Viktorov:

Que peut-on comprendre de l'exemple où il n'y a pas de contrôle d'un objet avant sa création ? Réclamer aux développeurs qu'ils ne permettent pas d'écrire comme bon leur semble, avec des erreurs grossières ?


Alexey, vous semblez être complètement à côté de la plaque. Lisez les sources primaires, s'il vous plaît.
Voici une citation :" Si un objet a été créé auparavant, une tentative est faite pour modifier ses coordonnées. "

Je comprends qu'il est de bon ton, dans les grands travaux, de mettre des chèques de toutes sortes. Mais dans ce cas, ce contrôle n'a pas de sens. Car s'il n'y a pas d'objet, ObjectCreate le créera, et s'il y en a un, il modifiera simplement ses coordonnées. Dans cet exemple très primitif, le but était de montrer le fait de supprimer un objet par Deunit of old TF, ce qu'il démontre parfaitement.
Votre "hit-and-run" ne concerne rien. C'est probablement une tentative d'attirer l'attention sur vous.
Et si vous voulez des lignes de code superflues, dénuées de tout sens, afin d'entraîner vos doigts, je vous recommande une excellente ressource "Keyboard Solo".

 
Alexey Viktorov:

Tu as sauté avec elle ?

Que pouvez-vous comprendre de l'exemple où il n'y a pas de contrôle d'un objet avant sa création ? Des réclamations contre les développeurs parce qu'ils n'ont pas fait en sorte qu'il soit possible d'écrire ce que l'on veut avec des fautes grossières ? J'écrirai comme je le veux et les développeurs doivent me fournir toutes les conditions pour cela. Les développeurs doivent prévoir toutes les erreurs possibles que je pourrais commettre à l'avenir. C'est ça ? N'aspirez pas le problème là où il n'existe pas.


Qu'y a-t-il de si terrible à essayer de créer un objet existant ? Va-t-il disparaître ?
 
Dmitry Fedoseev:

Qu'est-ce qui pourrait arriver de si terrible si nous essayons de créer un objet existant ? Va-t-il disparaître ?

Dimitri, vous me semblez être un programmeur cultivé. On ne vous a pas appris les règles de l'étiquette en programmation ?

Pour le reste, vous pouvez écrire comme dans l'ancienne mql4 avec la possibilité de dépassement de tableau et d'autres hypothèses. Vous obtenez une erreur en réponse... Eh bien, signalez le retour... continuons, nous n'avons pas le temps... Et puis nous rencontrons un problème qui ne vaut rien dans un langage plus strict et nous commençons à nous plaindre aux développeurs...

Le Christ est ressuscité.

 
Nikolai Semko:


... Le but de cet exemple très primitif était de montrer que Deunit supprimait l'objet de l'ancienne TF, ce qu'il démontre parfaitement. ...

Le fait de l'échec est démontré dans le contre-exemple. Tu n'as pas besoin d'aspirer le problème là où il n'existe pas. Mettez un contrôle sur la raison de la désinitialisation et l'objet n'est pas supprimé, il change juste ses coordonnées.
 
Alexey Viktorov:
Le fait de l'échec est montré dans l'exemple de réponse. Il n'est pas nécessaire d'aspirer le problème là où il n'est pas présent. Vous vérifiez la raison de la désinitialisation et l'objet n'est pas supprimé, il change juste ses coordonnées.
//Часть твоего кода:
void OnDeinit(const int reason)
  {
   if(UninitializeReason() != REASON_CHARTCHANGE)      // Что ты здесь сделал? - ЕСЛИ ПРОИСХОДИТ СМЕНА ТФ, ТО НИЧЕГО НЕ ДЕЛАЕМ. Бред! 
                                                       // И зачем здесь использовать функцию UninitializeReason(), когда можно уже существует переменная  reason?
    {
     ObjectDelete(0,"InitDeinit");
     ChartRedraw(0);                                   // Не нужная функция в данном случае, т.к. она обычно применяется после изменении свойств объктов. Объект удалится и так. 
     Print(__FUNCTION__, "  InitDeinit удалён");       // А где ж твоя любимая проверка, вдруг не удален.
    }
  }

Mon exemple a été créé pour montrer le problème d'une séquence ambiguë de l'unité de la nouvelle TF et de l'unité de l'ancienne TF, et non comme une solution.

Vous avez juste contourné le problème, vous ne l'avez pas résolu.
Dans mon exemple, il est juste important que dans l'Unité de l'ancien TF l'objet soit supprimé dans tous les cas, y compris lorsque le TF est modifié, et que dans l'Unité du nouvel objet il soit créé à nouveau.

Si la séquence est d'abord Deunit de l'ancienne TF, puis Unit de la nouvelle TF, comme cela devrait être logiquement. L'objet est ensuite supprimé, puis recréé.

Si la séquence est d'abord l'Unité du nouveau TF et ensuite la Deunité de l'ancien TF, alors l'objet est simplement modifié lorsque vous essayez de le créer dans l'Unité, car il n'est pas encore supprimé. Et ensuite, il est supprimé par le Deunit de l'ancien TF. C'est le bug.

C'était le but de cet exemple - montrer ce que peut rencontrer tout programmeur qui n'a pas lu cette branche et qui n'est pas au courant de cette "fonctionnalité".
Cet exemple n'a pas été conçu comme une solution. Des variantes de la solution sont présentées ici et ici. Je pense que je vais aussi ajouter une solution plus tard, mais sans utiliser les variables et fichiers globaux du terminal et pour que cette solution fonctionne même si plusieurs indicateurs identiques sont définis dans une fenêtre. Avez-vous essayé de résoudre ce problème ? Ou bien vous n'êtes capable que de trouver des erreurs dans le code d'autrui, surtout quand elles n'existent pas.

Ne soyez plus stupide !

1...171819202122232425262728
Nouveau commentaire
Raison: