Un sous-atelier pour remplir les FAQ (questions fréquemment posées). Aidons nos camarades ! - page 14

[---]

TheXpert:
Et la bonne chose à faire, à mon avis, est de toujours demander au terminal les informations les plus récentes.

L'état des commandes (tableau) est interrogé au moment précis où elles doivent être traitées.

Je ne dis pas qu'on peut s'en passer, et qu'il n'est pas nécessaire d'obtenir un masiew au préalable. Et analyser immédiatement l'état des commandes à la demande après OrderSelect et filtrer les indésirables par magicien, symbole, etc.

Mais vous soutenez que le tableau des billets est une UG. Justifiez pourquoi.

-------------

Taras a suggéré l'option "ultra" lorsque toutes les informations sur la commande sont écrites dans le tableau. Je ne peux qu'être d'accord avec cela dans la mesure où toutes ces informations ne sont pas nécessaires. Et dans la version simplifiée, pour la plupart, seuls les billets sont nécessaires.

[TarasBY]

TheXpert:
Je ne le suggérerais pas. Le plus souvent, une série de billets n'est pas du tout nécessaire. Et la bonne chose à faire, à mon avis, est de toujours demander au terminal les informations les plus récentes possibles.

Dans un tableau, vous obtenez des informations, vivant conditionnellement 1 coche. De quelles autres informations "fraîches" avez-vous besoin ? J'utilise ma propre pratique, lorsque j'ai 2-4 comptes multidevises (je veux dire la démo) qui ne permettent pas de "déranger le serveur" pour des choses inutiles.

Et en général, il s'agit de votre et de mon point de vue personnel. Et l'utilisateur doit toujours avoir le droit de choisir - dont les arguments sont plus sensés. ;)

P.S. Et je n'ai donné que MA réponse à la question posée dans la FAQ. :)

[TheXpert]

OK, IMHO UG parce que IMHO il est correct d'avoir les informations les plus récentes sur les commandes. Et, à mon avis, vous pouvez vous passer d'un tableau d'ordres dans 95 % des cas.

Vous voulez... en rajouter, je donnais juste mon avis.

[---]

Disons-le comme ça :

- En termes de commodité et d'abstraction du modèle, il est préférable d'utiliser des tableaux.
- Pour accélérer le travail - sans tableaux.

La pertinence de l' information n'a rien à voir avec cela. Dans les deux variantes - avec ou sans tableaux - la pertinence est 100% fraîche.

[TarasBY]

sergeev:

-------------

Taras a suggéré l'option "ultra", où toutes les informations relatives à la commande sont écrites dans le tableau. Je ne peux être d'accord avec cela que dans la mesure où toutes ces informations ne sont pas nécessaires. Et dans la variante simplifiée, seuls les billets sont nécessaires.

Alexey ! Je suis loin de penser qu'en introduisant cette question dans la FAQ (Obtenir un tableau de tickets de "propres" commandes), vous vouliez dire à propos de "la position que toutes ces informations ne sont pas nécessaires" - comme pour jouer autour ?!
Ou ai-je mal compris quelque chose ?

[---]

TarasBY:
Alexey ! Je suis loin de penser qu'en introduisant cette question dans la FAQ (Obtenir un tableau de tickets de "propres" commandes), vous vouliez dire la "position que toutes ces informations ne sont pas nécessaires" - comme pour jouer avec ?!
Ou ai-je mal compris quelque chose ?

Pour une raison quelconque, vous avez inclus toutes les propriétés dans le concept de "votre billet" en plus du billet.

Mais j'ai définitivement fait de votre suggestion une extension de la fonction "juste un ticket".

On en a souvent besoin aussi, notamment pour analyser et comparer les données historiques des commandes.

[TarasBY]

sergeev:

Disons-le comme ça :

- En termes de commodité et d'abstraction du modèle, il est préférable d'utiliser des tableaux.
- Pour accélérer le travail - sans tableaux.

La pertinence de l' information n'a rien à voir avec cela. Dans les deux variantes - avec ou sans tableaux - la pertinence est 100% fraîche.

En ce qui concerne la seconde ("pour accélérer le travail - sans tableaux"), je ne me précipiterais pas trop vite.
La simple logique suggère qu'un accès supplémentaire au serveur pour obtenir des "informations fraîches" représente un temps supplémentaire. Et il ne peut pas rivaliser en temps avec la récupération des mêmes informations dans le tableau.
Il y a un expert de la vitesse du code - Victor (Vinin), son opinion serait intéressante !

[---]

TarasBY:
En ce qui concerne le second point ("pas de tableaux pour accélérer le travail"), je ne serais pas trop prompt à être catégorique.
La simple logique veut que l'accès supplémentaire au serveur pour obtenir des "informations fraîches" représente un temps supplémentaire. Et il ne peut pas rivaliser en temps avec la récupération des mêmes informations dans le tableau.
Il y a un expert en performance de code, Victor (Vinin), son avis serait intéressant !

Une fois de plus, lorsqu'on travaille avec des propriétés de commande, il n'y a pas de serveur à contacter !

Dans le commerce, la règle la plus importante est la pertinence (afin de ne pas devenir l'UG dont TheXpert a parlé).
Ainsi, si vous vous référez à la liste des commandes à chaque fonction et que vous créez un tableau à nouveau, cela provoquera certainement un ralentissement. Cela provoquera le remplissage du tableau.

Ainsi, nous pouvons économiser de l'argent sur l'actualisation des tableaux et la répétition d'OrdeSelect (déjà sur le ticket).

Si vous avez 1 ou 2 commandes en cours, le tableau n'est pas critique, mais si vous en avez 50 à 100, c'est déjà significatif.

[TarasBY]

J'en dirai plus : sur la base de mon concept de "réduction de la charge du serveur" (je l'appellerais plus précisément "optimisation de la vitesse du code"), je récupère tous les prix dans un tableau séparé (si j'en ai besoin pour plusieurs outils) au début de Start(). Et si j'ai besoin de faire une opération commerciale, je fais RefreshRates().

Je n'impose cette approche à personne, je vois simplement le raisonnement qui la sous-tend et j'utilise ce principe dans mes conceptions.

P.S. Ceci n'est pas pour initier une dispute sur ce sujet, c'est simplement un argument à ce qui précède.

[TarasBY]

sergeev:

Donc, si vous vous référez à la liste des commandes à chaque fonction et recréez le tableau à nouveau, cela entraînera certainement un ralentissement. A cause du remplissage du tableau.

J'ai dit ça ? Le tableau des ticks est rempli une fois par tick si l'EA travaille sur chaque tick. Et puis au lieu de l'échantillonnage habituel :

    for (int li_int = li_total - 1; li_int >= 0; li_int--)
    {
        if (OrderSelect (li_int, SELECT_BY_POS))
        {
        .......
        }
    }

Je sélectionne sur

for (int li_TIC = 0; li_TIC < gi_cnt_Tickets; li_TIC++)
{

}

ou :

    for (int li_SMB = 0; li_SMB < ArraySize (gsa_Symbols); li_SMB++)
    {
    }

selon que je me sens plus à l'aise avec telle ou telle fonction.
Je dois convenir que la rationalité de cette approche est plus perceptible dans les systèmes multidevises, qui sont minoritaires.