créer un numéro magique - page 2
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
Mon Dieu, tu as battu ma vitesse d'édition :)). Je l'ai modifié. J'ai oublié de préciser que c'est une GlobalVariable.
Et que se passe-t-il si vous devez continuer une session à partir d'un terminal DIFFERENT (parce que votre ordinateur est mort par exemple)... ? Vous aurez toujours besoin d'une couche de persistance (les GV sont stockées dans le terminal - côté client). L'idée derrière un numéro magique "automatisé" est d'obtenir un numéro unique pour chaque expert, sans avoir besoin d'une couche de persistance...
Parce qu'alors vous devez garder un niveau de persistance pour cette magie. Que se passe-t-il si votre terminal redémarre ? La magie serait différente...
J'ai lu quelque part que les valeurs de GlobalVariable existent environ 14 jours après le dernier accès. De plus, si cette technique se maintient, nous avons l'avantage supplémentaire de retrouver l'heure de la commande par son numéro magique.
Qu'en pensez-vous ?
Et que se passe-t-il si vous devez poursuivre une session à partir d'un terminal DIFFERENT (parce que votre ordinateur est mort par exemple) ? Vous auriez encore besoin d'une couche de persistance (les GV sont stockés dans le terminal - côté client). L'idée derrière un numéro magique "automatisé" est d'obtenir un numéro unique pour chaque expert, sans avoir besoin d'une couche de persistance...
Cela casserait probablement le GV, mais les secondes tiendront et il est unique aux secondes IMHO...
Cela casserait probablement le GV, mais les secondes tiendront et c'est unique aux secondes IMHO...
C'est unique ; pas de désaccord là-dessus. Mais encore une fois - disons que l'ordinateur tombe en panne. Vous emmenez votre expert sur un autre ordinateur avec un autre terminal, vous vous connectez sur le même compte et vous continuez avec le même expert. Si l'expert est conçu correctement, cela ne devrait pas poser de problème, sauf que l'expert attribuerait maintenant une magie DIFFÉRENTE aux ordres qu'il traite. Il est donc évident que cela ne fonctionnera pas.
J'ai lu quelque part que les valeurs de GlobalVariable existent environ 14 jours après le dernier accès. En outre, si cette technique se maintient, nous avons l'avantage supplémentaire de récupérer l'heure de la commande par son numéro magique.
Qu'en pensez-vous ?
Je pense 30... Mais quoi qu'il en soit, elles restent côté client avec le terminal spécifique.
p.s. Si vous ne l'avez pas encore fait, jetez un coup d'oeil à ce fil -> https://www.mql5.com/en/forum/120034. Il traite du même problème et propose de nombreuses idées intéressantes...
... sauf que maintenant l'expert assignerait une magie DIFFERENTE aux ordres qu'il traite. Donc, évidemment, cela ne fonctionnera pas.
Je ne comprends pas...
- Je pensais que le but était d'attribuer un numéro magique différent pour chaque transaction générée ? Ce n'est qu'une fois qu'un ordre est accepté par le courtier que le OrderMagicNumber() est fixé et peut être récupéré.
Si la transaction précédente par l'ancien terminal client 'mort' a généré avec succès le OrderMagicNumber, alors le prochain même expert ou un expert différent dans un terminal différent ne générera pas le même nombre magique.
- IMHO - en utilisant vos termes : Le temps est persistant sans avoir besoin d'être superposé, Il n'y a jamais deux temps identiques... :)))
- Merci pour les liens, je les ai lus. Je n'ai rien contre les nombres magiques générés de manière complètement aléatoire, mais je préfère encore un nombre magique qui est quelque peu logique et qui a d'autres utilisations...
- Peut-être que la technique se brisera si vous avez 2 ou plusieurs ordres acceptés à une fraction de seconde sur des terminaux différents. ce qui, je suppose, est peu probable...
Je ne comprends pas.
- Je pensais que le but était d'attribuer un numéro magique différent pour chaque transaction générée ? Ce n'est qu'après l'acceptation d'un ordre par le courtier que le OrderMagicNumber() est fixé et peut être récupéré.
Si la transaction précédente par l'ancien terminal client 'mort' a réussi à générer un OrderMagicNumber, alors le prochain expert, identique ou différent, dans un terminal différent , ne générera pas le même numéro magique.
- IMHO - en utilisant vos termes : Le temps est persistant sans avoir besoin d'être superposé, Il n'y a jamais deux temps identiques... :)))
- Merci pour les liens, je les ai lus. Je n'ai rien contre un nombre magique qui est généré pour être complètement aléatoire, mais je préfère encore un nombre magique qui est quelque peu logique et qui a d'autres utilisations...
- La technique se brisera si vous avez 2 ou plusieurs commandes acceptées à une fraction de seconde sur des terminaux différents. ce qui est peu probable, je suppose...
Non... C'est pour l'ensemble de l'expert. Ainsi, si vous utilisez plusieurs experts sur le même compte, ils n'interféreront pas les uns avec les autres. Personnellement, je n'aime pas ou n'utilise pas non plus de système automatisé. J'utilise une gamme de nombres magiques pour chaque expert plutôt qu'un seul nombre magique, car je stocke des informations dans la magie. Quoi qu'il en soit, ce fil de discussion explique comment définir automatiquement un numéro magique unique pour chaque expert.
J'apprécie votre opinion. Je ne l'ai peut-être pas expliqué très clairement, mais relisez mon message concernant cette technique. Elle concerne l'ensemble de l'expert
(et par conséquent chaque expert, chaque transaction, chaque terminal, automatiquement) ... d'où l'utilisation de l'appel WindowsExpertName() récupérant son ID et le concaténant avec un compteur GlobalVariable chaque fois que l'expert du même nom est attaché à différents graphiques & TimeCurrent().
Veuillez y réfléchir un peu plus... Soit ça tient, soit ça ne tient pas. Si vous ou d'autres personnes trouvent que c'est facilement cassable, alors je devrais probablement repenser à cela aussi... :)))
Gordon,
J'apprécie votre opinion. Peut-être que je ne l'ai pas expliqué trop clairement, mais relisez mon post concernant cette technique. Elle est destinée à l'ensemble de l'expert... d'où l'utilisation
de l'appel WindowsExpertName() et sa concaténation avec un compteur GlobalVariable chaque fois que l'expert avec le même nom est attaché à différents graphiques.
S'il vous plaît, réfléchissez-y un peu plus... Soit ça tient, soit ça ne tient pas. Si vous ou d'autres personnes trouvent que c'est facilement cassable, alors je devrais probablement repenser à cela aussi... :)))
Quoi qu'il en soit, après l'avoir relu. Voici les problèmes que je vois avec elle :
- Quel est le numéro d'identification ? Un numéro unique codé en dur pour chaque expert ou quoi ? Il est facile de s'assurer que les experts n'ont pas le même nom, il est plus difficile de s'assurer qu'ils n'ont pas le même numéro, surtout s'il est codé en dur.
- La persistance. La persistance. Persistance. Encore une fois, comment continuer une session depuis un autre terminal. Où est sauvegardé l'intervalle de temps, par exemple ?
- L'utilisateur peut s'amuser avec les GV manuellement (mais cela ne sera probablement pas un problème dans la plupart des cas...).
Edit : peut-être que la trame temporelle n'est pas un bon exemple...
Je vais mettre quelques codes...