Développeurs ! Est-ce que vous testez au moins ce que vous créez ? - page 11

 

papaklass, c-4

Le modèle de réponse du serveur existant via OnTradeTransaction

cela me convient, et cela fonctionne dans mon EA, MAIS

mon premier message était qu'aucun message n'était retourné (du tout) du serveur,

que l'affaire a été conclue (la commande a été remplie par 1) et la deuxième erreur était

La deuxième erreur était qu'au lieu d'une réponse indiquant que l'ordre avait été placé, une réponse indiquant qu'il avait été partiellement exécuté (dupliqué).

Le problème ne venait pas du gestionnaire (je n'ai rien à lui reprocher) mais des réponses du serveur (une réponse ne venait pas du tout et l'autre était fausse).

Le modèle de travail avec les réponses du serveur dans mon EA n'est PAS basé sur la séquence des réponses du serveur, MAIS la réponse doit être et être correcte.

Voici ce qui s'est passé (photo du premier message) :

Le conseiller expert a placé un ordre avec un volume de 3.

La commande a été exécutée par un - les réponses du serveur sont correctes.

Puis le Conseiller Expert a modifié l'ordre - la réponse du serveur est ORDER_STATE_PARTIAL - et la réponse aurait dû être ORDER_STATE_PLACED.

Puis l'ordre a été exécuté une fois de plus sans aucun message du serveur.

Quelques jours plus tard (photo ci-dessous), j'ai répété cette séquence - le résultat a changé (les développeurs ont probablement corrigé quelque chose),

J'ai obtenu un message indiquant que la transaction a eu lieu (seconde 21:15:02.232), mais le message concernant la modification n'était toujours pas correct.

Il est également très inquiétant que trois réponses du serveur soient arrivées en même temps (21:14:53.049) !

Il est clair que tout fonctionne dans le même fil, et que les messages s'accumulent, mais tout de même..... J'empêche l'EA de fonctionner,

pour recevoir des messages.

 

papaklass !

Le fait est que les programmes *.ex5 s'exécutent dans un seul thread, si

il y aura beaucoup de manutentionnaires, ce sera encore pire.

 
papaklass:

Maintenant, j'ai vérifié spécifiquement l'opération OnTrade et OnTradeTransaction.

Trois gestionnaires OnTrade ou quatre gestionnaires OnTradeTransaction se déclenchent sur un ordre de transaction pour ouvrir une position sur le marché (un ordre de marché). J'ai besoin d'un seul gestionnaire OnPositionOpened pour le déclencher.

Pour fermer une position par un stop loss/stake profit, il y a 3 handlers OnTrade ou 3 handlers OnTradeTransaction déclenchés au lieu d'un seul OnPositionClosed. La redondance est évidente !

Ces réponses multiples des gestionnaires d'événements existants (OnTrade/OnTradeTransaction) ne donnent pas une réponse claire à la question : "Quel événement commercial s'est produit et quel est le résultat d'une opération commerciale? Cela soulève la question : "Pourquoi tous ces problèmes ?"

Avec un tel traitement redondant des événements commerciaux, des collisions de différents types peuvent facilement se produire, ce qui entraînera des erreurs, notamment lors de l'envoi massif d'ordres commerciaux par les clients.

Par conséquent, ce qui s'est passé dans votre cas ou dans celui de komposter (timeout) ne me surprend pas personnellement.

La façon dont les événements OnTrade et OnTradeTransaction sont implémentés m'a rappelé un épisode qui s'est produit il y a 20 ans... Je me souviens avoir lu des critiques de nouveaux jeux pour Spectrum, notamment un jeu mémorable, où il était écrit : "... le son dans le jeu est bon car vous pouvez le désactiver..." J'ai presque la même attitude envers les événements OnTrade et OnTradeTransaction, ils sont bons juste parce que vous ne pouvez pas les utiliser.
 
SWA:
La façon dont les événements OnTrade et OnTradeTransaction sont implémentés m'a rappelé un épisode d'il y a 20 ans... Je me souviens avoir lu des critiques de nouveaux jeux pour Spectrum, particulièrement mémorable était la critique d'un jeu, où il était écrit comme ceci : "... le son dans le jeu est bon car vous pouvez le désactiver...". J'ai à peu près la même attitude à l'égard des événements OnTrade et OnTradeTransaction : il vaut mieux ne pas les utiliser.

Moi, par contre, j'utilise (avec succès) ces deux handlers !

Si, pour une raison quelconque, OnTradeTransaction ne fonctionne pas, je vérifie

dans OnTrade - très pratique car OnTradeTransaction,

et ensuite OnTrade.

 
Mikalas:

Moi, par contre, j'utilise (avec succès) ces deux handlers !

Si, pour une raison quelconque, OnTradeTransaction ne fonctionne pas, je vérifie

dans OnTrade - très pratique car OnTradeTransaction,

et ensuite OnTrade.

Personnellement, je trouve cette commodité discutable : perte de temps et surcharge du canal client-serveur avec des demandes d'informations exactes sur ce qui s'est passé sur le serveur. Il peut arriver que les informations durement acquises par le serveur ne soient plus à jour et fiables au moment où vous les obtenez.
Il serait vraiment pratique d'utiliser ces événements (du moins pour moi) si le Conseiller Expert générait une requête au serveur avec la fréquence nécessaire pour l'algorithme de trading comme ceci
bool TradeTransaction(TIME_REQUEST);
bool Trade(TIME_REQUEST);
// где временная метка может принимать значение к примеру TIME_REQUEST=TimeTradeServer или TIME_REQUEST=TimeGMT

Et le serveur répondrait immédiatement à une telle demande avec des informations complètes...

Cependant, en supposant qu'il existe des "raisons objectives insurmontables" qui rendent impossible la mise en œuvre d'une telle commodité, je fais avec ce que j'ai :)

 

Qui peut le faire... :)

À propos, téléchargez l'API Plaza II à partir du serveur d'échange et vous comprendrez d'où viennent les "jambes".

 
Mikalas:

S'il vous plaît, ne soyez pas grossier ! Au fait, il est déjà 10 heures !

Et vous avez le droit de ne pas lire du tout ce qui est écrit ici !

Quel est le sujet alors ? Juste pour crier ?

Si vous pensez qu'il y a une erreur, confirmez-la à l'aide de journaux et de codes (personne ne pourra déchiffrer vos photos).
Si vous voulez trouver une solution fiable, écoutez ce qu'ils disent (abandonnez le modèle événementiel et analysez l'état actuel).

J'utiliserais OnTradeTransaction ouOnTrade uniquement pour une réaction immédiate à un changement de situation commerciale. Mais l'ensemble du traitement serait placé dans un seul gestionnaire, comme le suggère Vasiliy(OnRefresh()).

Bonne chance !

 
komposter:

Quel est le sujet alors ? Juste pour crier ?

Si vous pensez qu'il y a une erreur, confirmez-la avec les journaux et le code (personne ne décodera vos photos).
Si vous voulez trouver une solution fiable, écoutez ce qu'ils disent (abandonnez le modèle événementiel et analysez l'état actuel).

J'utiliserais OnTradeTransaction ouOnTrade uniquement pour une réaction immédiate à un changement de situation commerciale. Mais tout le traitement serait placé dans un seul gestionnaire, comme Vasiliy l'a suggéré(OnRefresh()).

Bonne chance !

komposter !

Soit tu lis tout ce que tu as écrit, soit...

Tout ce que j'écris sur ces pages est MON droit en tant que participant au forum,

et tout ce qui est grossier est loin d'être approprié !

3. Quelle que soit la façon dont vous traitez l'erreur, si la réponse du serveur n'est pas ce qu'elle devrait être, le résultat sera le même : ERREUR !

4. Vous ne faites probablement pas de commerce vous-même.

 
Mikalas:
BURNING REMOTE est la réponse à une attaque flagrante ! Quelle que soit la question, c'est la réponse. Tu aurais pu être un héros... ))
 

pronych et ....

1.>> LUCKY REMOTE est la réponse à une attaque flagrante ! Quelle que soit la question, c'est la réponse. >> J'aurais pu être un héros... ))

Vous avez probablement la bonne perception du monde qui vous entoure...

2. Êtes-vous des programmeurs ou des "écrivains" ?

3. Que quelqu'un réponde à une question simple : Que doit répondre le serveur à la commande "Modifier la commande" ?

4. Pourquoi de la documentation alors ? Des articles ? Fermez les yeux et crachez ce que vous voulez ! C'est le CLIENT qui paie de toute façon (et c'est lui aussi qui doit être drainé) !

bool CheckMoney()
{
  return(ВАСЯ_ПУПКИН);
}
Raison: