Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
l'erreur 1 est une erreur normale...
dans le testeur, il ne se produit généralement pas (sauf si le code est courbe et modifie des paramètres d'ordre inchangés ou si le testeur peut générer des dérapages).
dans le marché réel ceci (avec un code de modification d'ordre correct) est possible quand vous changez les stops près du marché, surtout avec le slippage - le type de stop loss se déplace juste derrière le prix quand l'ordre se déplace vers le positif et à cause du slippage et du mouvement du prix, l'erreur se produit souvent et on sait pourquoi... bonne erreur...
Désolé, SellLimit nécessite une dist :
pas si (New_OOP < Bid) continuer; maissi (New_OOP-dist*Point < Bid) continuer;
Boris, ma méthode fOrderModify() prend en compte toutes les vérifications, tant sur STOPLEVEL que sur FRIZLEVEL. Ainsi, si l'une de ces conditions n'était pas remplie, la modification n'irait pas jusqu'au bout.
Vous avez tout à fait tort. La dernière erreur est encore remise à zéro dans de nombreuses fonctions importantes. Cela fonctionne aussi de cette façon dans WinAPI.
Ainsi, enregistrez le code d'erreur dans une variable locale dès qu'il se produit, et n'essayez pas de l'utiliser après avoir effacé cette variable système dix fois dans la masse de vos fonctions intermédiaires.
Eh bien, même si l'erreur était écrasée en option, la dernière serait toujours là. La dernière erreur serait toujours 1 dans mon cas. N'est-ce pas ?
Si je ne travaille même pas avec des erreurs de cette façon. Puis-je vous montrer ce que vous voulez dire par un exemple ?
Voici ma fonction de modification avec toutes les imprimantes, car je suis en train de la déboguer.(Ignorez les autres méthodes qu'il utilise).
Le serveur répond : "Qu'est-ce que tu veux, vieil homme ?".
Ou encore : Dites-moi ce que vous voulez, je vous donnerai peut-être ce que vous voulez.
Je n'ai reçu aucune critique ou un chaleureux "merci" russe. Triste, les filles...
Je n'ai reçu aucune critique ou un chaleureux "merci" russe. Triste, les filles...
Désolé, SellLimit nécessite une dist :
pas si (New_OOP < Bid) continuer; maissi (New_OOP-dist*Point < Bid) continuer;
Victor, votre premier message contenait déjà toutes les informations nécessaires. Vous envoyez simplement des ordres pour modifier un ordre sans nouvelles valeurs pour les paramètres de cet ordre.
Boris, supposons que c'est le cas... Assumant. Mais, si la fonction renvoie un ordre pour modifier l'ordre, le significantton doit être modifié. Et avec moi, ça ne change pas du tout. Même si nous regardons le journal dans le journal, ce que nous voyons est ceci :
Pourquoi la commande est-elle envoyée ? Si ses paramètres n'étaient pas corrects, la fonction se planterait... Et ici, c'est plutôt bien... ...il a été envoyé. Puis il s'est avéré qu'il y avait une erreur. Quelle est la logique derrière cela ?Quel est le rapport avec les erreurs ? J'ai mis une impression d'erreur juste avant la fonction de modification :
Et voici le journal de ce morceau de code :
Vous pouvez clairement voir qu'il n'y a pas d'erreurs avant la fonction de modification ! Quel est le rapport avec les erreurs ?