Erreurs, bugs, questions - page 362

[Mykola Demko]

Lizar:
Le besoin d'une telle fonctionnalité augmentera au fur et à mesure que le nombre de types d'objets augmentera. Et cela deviendra nécessaire lorsque vous créerez des objets pour lesquels vous ne pourrez pas déterminer le nombre de points d'ancrage par leur type. Par exemple, il peut s'agir d'une sorte de polyligne. Mais pour l'instant ce n'est pas très critique, mais cela peut être exécuté comme un souhait dans le service Desk.

Pour l'instant, il est plus réaliste (si le besoin s'en fait sentir) de créer une fonction de commutation qui donnera le nombre de points d'ancrage par type d'objet.

Il suffit de faire ce tableau (MQL5 Reference / Standard constants, enumerations and structures / Object constants / Object types) en switch. Le paramètre d'entrée de la fonction sera ObjectGetInteger(chart_id,name,OBJPROP_TYPE).

Il n'y a pas de dangers cachés puisque tous les types sont rigidement liés à des points d'ancrage. Mais si les objets avec un nombre variable de points apparaissent, alors il y aura un besoin urgent d'une telle fonctionnalité.

[---]

Urain:

Maintenant, la façon la plus réaliste (si vous en avez besoin) est de créer une fonction de commutation qui donnera le nombre de points d'ancrage en fonction du type d'objet.

J'ai demandé une propriété dans ObjectGet il y a longtemps.

il me semble que cela a à voir avec la logique même des entrailles de MT5.

Il passe probablement par tous les points et vérifie s'ils sont vides. Et si un point a un chiffre normal, il se construit.

Il n'y a donc pas de relation directe entre le type d'objet et le nombre de points d'ancrage.

C'est pourquoi vous avez noté à juste titre que vous devez faire le changement vous-même.

[Konstantin Gruzdev]

Urain:

Maintenant, la façon la plus réaliste (si vous en avez besoin) est de créer une fonction de commutation qui donnera le nombre de points d'ancrage en fonction du type d'objet.

Il suffit de faire ce tableau (MQL5 Reference / Standard constants, enumerations and structures / Object constants / Object types) en switch. Le paramètre d'entrée de la fonction sera ObjectGetInteger(chart_id,name,OBJPROP_TYPE).

Il n'y a pas de dangers cachés puisque tous les types sont rigidement liés à des points d'ancrage. Mais si nous obtenons de nouveaux objets avec un nombre variable de points, nous aurons vraiment besoin de cette fonctionnalité.

sergeev:

J'ai demandé une propriété dans ObjectGet il y a longtemps.

S'il y a des objets avec un nombre variable de points, une telle fonctionnalité sera extrêmement nécessaire.

Il passe probablement par tous les points et vérifie s'ils sont vides. Et si un point a un chiffre normal, il se construit.

Il n'y a donc pas de relation directe entre le type d'objet et le nombre de points d'ancrage.

Si le nombre de points est variable, cette fonctionnalité sera extrêmement nécessaire.

Oui, comme je l'ai écrit ci-dessus, je l'ai implémenté via un interrupteur. Il fonctionne sans aucun problème. Mais l'idée va plus loin, je veux plus de commodité et d'universalité.

À propos, je pense qu'il serait bon de laisser les utilisateurs créer leurs propres objets. Par exemple, il faudrait au moins permettre de fusionner les objets standard en groupes ayant une "marque" commune. Pour qu'il soit possible de se référer à un groupe d'objets comme à un seul. Ensuite, il y aurait des objets délicats comme les polylignes, les anneaux, les tores... et ainsi de suite. Et même les objets d'un certain tableau de bord pourraient être fusionnés. Et Ctrl-B ne produirait pas une feuille d'objets, mais des noms soignés de groupes d'objets, ou quelque chose de similaire. De même, le problème de la réception de 100 000 événements provenant d'objets modifiés dans le gestionnaire OnChartEven() serait résolu, car ces 100 000 objets pourraient être fusionnés en un groupe et ne recevoir qu'un seul événement CHARTEVENT_OBJECT_CHANGE. Dans l'ensemble, ce serait une beauté. Bien sûr, vous pouvez implémenter partiellement tout cela par le biais de classes, mais pas tout.

[Vladimir Gomonov]

Lizar:

........ Et Ctrl-B donnerait non pas une feuille d'objets, mais des noms soignés de groupes d'objets, ou quelque chose comme ça............

....... car ces 100 000 objets pourraient être réunis en un groupe et ne recevoir qu'un seul événement CHARTEVENT_OBJECT_CHANGE. En somme, une beauté.......

Rêvez, mais ne vous faites pas d'illusions.

:)

[Serge]

J'écris un indicateur pour afficher les chandeliers de plusieurs instruments à la fois. Après le démarrage et avant l'apparition des nouvelles barres, tout s'affiche correctement :

Mais après l'apparition de nouveaux bars, il y a un changement :

Et ChartRedraw ne m'aide pas. Cependant, si j'appuie sur le bon bouton-refresh, tout est en place. Pouvez-vous me dire comment éviter le décalage ?

[Mykola Demko]

Le double price; est-il normalisé automatiquement dans MqlTradeRequest (ce qui est peu probable) et si non, pourquoi n'y a-t-il toujours pas de normalisation dans la bibliothèque standard? (J'ai soulevé cette question il y a 9 mois).

Je me suis sorti de cette situation en faisant simplement des modifications dans la bibliothèque standard, mais vous savez que ce n'est pas le cas (elle est démolie lors de la mise à jour).

bool CTrade::PositionOpen(const string symbol,ENUM_ORDER_TYPE order_type,double volume,
                          double price,double sl,double tp,const string comment)
{
...
m_request.price       =price; // ??????????
...
}

Si je me trompe, alors indiquez dans quoi ?

[Renat Fatkhullin]

Nous n'effectuons pas la normalisation automatiquement, car nous ne sommes pas autorisés à modifier le prix du négociant pour ne pas être accusés d'arbitraire.

Vous devez normaliser le prix vous-même si vous utilisez le prix calculé. Lorsqu'un ordre est passé avec des prix Bid/Ask nets inchangés, la normalisation n'est pas nécessaire.

[Mykola Demko]

Renat:

Nous n'effectuons pas la normalisation automatiquement, car nous ne sommes pas autorisés à modifier le prix du négociant pour ne pas être accusés d'arbitraire.

Vous devez normaliser le prix vous-même si vous utilisez le prix calculé. Lorsqu'un ordre est passé avec des prix Bid/Ask nets inchangés, la normalisation n'est pas nécessaire.

Merci, j'ai trouvé ce que je voulais. J'ai dû normaliser même l'offre et la demande en 4.

[Renat Fatkhullin]

Urain:
Merci, j'ai trouvé ce que je voulais. Même l'offre et la demande ont dû être normalisées en 4.

En fait, dans MT4, vous n'avez pas besoin de normaliser l'offre et la demande. Ils sont toujours normalisés par défaut.

Si vous avez un exemple sous la main, montrez-le-moi.

[Mykola Demko]

Renat:

En fait, dans MT4, vous n'avez pas besoin de normaliser l'offre et la demande. Ils sont toujours normalisés par défaut.

Si vous avez un exemple sous la main, veuillez me le montrer.

Je n'ai pas d'exemple sous la main, c'était il y a assez longtemps (peut-être que les builds actuels sont corrects), il y avait autrefois de tels problèmes que j'obtenais des requotes dans MT4 même en demandant Bid et Ask, après la normalisation tout s'est amélioré, il y avait donc une règle pour normaliser toute demande. Et vous savez, l'habitude est une seconde nature.