Erreurs, bugs, questions - page 1702

Nouveau commentaire
 
Dmytro Zelenskyy:

OK, comment convertir correctement un double en int avec le signe intact (le nombre n'a pas d'importance, s'il est en dehors de la limite, il faut le limiter en int).

Convertir en long.
 
fxsaber:
Répondez et fermez-la immédiatement.

J'avais besoin de pouvoir me supprimer (l'indicateur) au cas où il y aurait une copie en cours d'exécution, même avec des paramètres d'entrée différents. Pour ce faire, je devais découvrir le manche de moi-même. Malheureusement, à l'époque, je ne savais pas que c'était impossible dans MQL dans 100% des cas. J'ai donc décidé d'essayer un truc pas très malin.

J'ai parcouru toutes les poignées. S'il coïncide avec le hasard que j'ai écrit dans mon indicateur avant de le vérifier, cela signifie automatiquement que le handle m'appartient et que je peux me supprimer, si nécessaire.

C'est à partir de ces considérations qu'a été écrit un code aussi inoffensif, qui a provoqué une réaction aussi ambiguë, mais évidemment négative, de la part des développeurs. Tu vois, tu ne peux pas faire ça. Qu'avez-vous fait ? Eh bien, je lis la valeur de mon tampon à travers le CopyBuffer. C'est illégal ? !

La réponse des développeurs ne ressemble en rien à un "vous ne pouvez pas faire ça". Il n'est dit nulle part que c'est "illégal".

Si vous pensez avoir absolument besoin de ce "code inoffensif", utilisez-le. Ajoutez simplement IndicatorRelease(handle)) à OnCalculate() après avoir lu le tampon. Vous n'avez pas besoin de vérifier à chaque tique qu'il s'agit de "votre" indicateur, n'est-ce pas ?

C'est ainsi que l'indicateur résout votre problème et cesse d'être "invisible" :

#property indicator_separate_window
#property indicator_buffers 1
#property indicator_plots   1

double Buffer[];

int handle=INVALID_HANDLE;
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnInit()
  {
   ::SetIndexBuffer(0,Buffer,INDICATOR_DATA);
   handle=ChartIndicatorGet(0,1,ChartIndicatorName(0,1,0));
  }

#define  TOSTRING(A) #A + " = " + (string)A + "\n"
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
int OnCalculate(const int rates_total,
                const int prev_calculated,
                const datetime &time[],
                const double &open[],
                const double &high[],
                const double &low[],
                const double &close[],
                const long &tick_volume[],
                const long &volume[],
                const int &spread[])
  {
   if(handle!=INVALID_HANDLE)
     {
      Buffer[rates_total-1]=MathRand();

      double BufferCopy[];

      if(CopyBuffer(handle,0,0,1,BufferCopy)>0)
         Print(TOSTRING(BufferCopy[0])+TOSTRING(Buffer[rates_total-1]));
         
      if(IndicatorRelease(handle)) 
         handle=INVALID_HANDLE;
     }

   return(rates_total);
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnDeinit(const int Reason)
  {
   if(handle!=INVALID_HANDLE)
      IndicatorRelease(handle);
   return;
  }


Que la communauté sache qu'il est possible de créer de cette manière une exécution incontrôlée de n'importe quel code en arrière-plan, même sur le terminal sans graphiques. Voici une petite astuce. Le fait de le considérer ou non comme un bogue est probablement une question de terminologie. Si j'ai bien compris, les promoteurs ne sont pas en mesure de changer quoi que ce soit à l'architecture ici. C'est pourquoi il y a une telle colère. Je ne peux pas expliquer cette réaction d'une autre manière.

Il n'y a pas de "colère" dans la réponse du servicedesk. Il y a un malentendu sur votre motivation à exagérer régulièrement les problèmes que vous rencontrez.

Les développeurs sont capables de changer les choses. Mais ils sont généralement très prudents quant aux suggestions visant à "supprimer et interdire" un comportement, même non documenté, s'il n'est pas sans ambiguïté nuisible. Ce "hack" est plutôt spécifique, mais peut-être que quelqu'un l'utilise.

Peut-être y aura-t-il encore des modifications dans le terminal à ce sujet, mais ce n'est certainement pas un problème gigantesque et la priorité de cette question est minime.

Personne ne s'exprimera de toute façon. Un tel râteau serait bien reflété dans l'aide.

Il s'avère que vous êtes bien conscient que ce "grave bug" du terminal n'intéresse que vous.

Concluons l'affaire à ce stade. Les détails techniques ont tous été discutés, tandis que les émotions sont inutiles dans ce fil.

 
Anton:

Il n'y a rien du genre "ce n'est pas autorisé" dans la réponse des développeurs. Il n'est dit nulle part que c'est "illégal".

Si vous pensez que ce "code inoffensif" est absolument nécessaire pour vous, utilisez-le. Ajoutez simplement IndicatorRelease(handle)) à OnCalculate() après avoir lu le tampon. Vous n'avez pas besoin de vérifier à chaque fois qu'il s'agit de "votre" indicateur, n'est-ce pas ?

Non, bien sûr, ce n'est pas nécessaire.

C'est ainsi que l'indicateur résout votre problème et cesse d'être "invisible" :

À ce sujet, j'ai récemment reçu une réponse de votre collègue.

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie

Erreurs, bugs, questions

Slawa, 2016.09.07 17:17

fxsaber:

IndicatorRelease après iCustom doit être fait ?

Pour quoi faire ?

Ne le faites pas. Ne pas faire après IndicatorCreate soit

Je n'ai pas obtenu de réponse.

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading

Bugs, bugs, questions

fxsaber, 2016.09.07 17:27

Après ne signifie pas immédiatement. Mais si vous n'avez pas à le faire, quand le feriez-vous?

Il n'y a pas de "colère" dans la réponse du servicedesk. Il y a un malentendu sur votre motivation à exagérer régulièrement les problèmes auxquels vous êtes confrontés.

La motivation est purement égoïste. Je veux que tout fonctionne de manière prévisible, conformément à la documentation. Les bugs sont ennuyeux, c'est le résultat.

Les développeurs sont en mesure de changer. Mais ils sont généralement très prudents quant aux suggestions visant à "supprimer et interdire" un comportement même non documenté, à moins qu'il ne soit clairement nuisible. Ce "hack" est plutôt spécifique, mais peut-être que quelqu'un l'utilise.

Peut-être que des modifications seront encore apportées au terminal à ce sujet, mais ce n'est certainement pas un problème gigantesque et la priorité de cette question est minime.

Je suis d'accord sur la priorité.

Il s'avère que vous êtes bien conscient que ce "grave bug" du terminal n'est intéressant que pour vous.

Terminons la question à ce stade. Tous les détails techniques sont discutés, mais les émotions sont inutiles dans ce fil.

Non, ils ne commentent pas pour une autre raison. Peu importe la gravité du bug. Mon "sérieux" concernait les bugs que vous pouvez DÉJÀ fabriquer et mettre dans le même Marché. Et ensuite être confronté au fait que le VPS n'a pas assez de ressources informatiques. Bref, vous voyez l'idée.
 
Vladimir Pastushak:

Je n'en ai pas besoin de cette façon, j'essaie de faire beaucoup de travail pour me faciliter la vie à l'avenir.

J'ai résolu mon problème de la façon suivante : dans le parent, tout est protégé et l'héritage passe sous la protection puis la substitution.

Si le parent est protégé, alors il n'y a pas besoin de faire de l'héritage de protection (vous pouvez laisser public aussi). Seulement maintenant, ce que vous vouliez depuis le début n'est pas clair. Si vous avez besoin de cacher les méthodes du parent à l'intérieur de la classe (et non à l'extérieur comme je le pensais), alors quel est l'intérêt de la protection ? Vous avez besoin d'une primitive ici.
 
Alexey Navoykov:
Seulement maintenant, ce que tu voulais à l'origine n'est plus clair.
On dirait qu'il suffit de se débarrasser des méthodes indisponibles dans la liste pop-up.
 
Sergei Vladimirov:
On dirait qu'il suffit de se débarrasser des méthodes indisponibles dans la liste pop-up.
Les inaccessibles n'apparaissent donc pas, n'est-ce pas ?
 
Sergei Vladimirov:
On dirait qu'il suffit de se débarrasser des méthodes indisponibles dans la liste popup.

Non seulement cela, mais j'ai réécrit les classes d'objets graphiques pour moi-même et à partir d'une classe dans laquelle toutes les propriétés des objets sont décrites, je fais maintenant facilement et de manière compréhensible (du moins pour moi) des descendants du type Bouton.

En outre, à partir de ces éléments simples, je peux en construire de plus compliqués avec une probabilité d'erreur minimale, une rapidité et une simplicité maximales (du moins, pour moi).

Vous allez peut-être me donner un coup de pied amical et dire que la bibliothèque standard a tout, mais je vous le dis tout de suite, ce n'est pas tout et c'est incompréhensible. J'ai l'habitude de travailler avec ce que je comprends parfaitement, et pour comprendre comment tout cela fonctionne, il faut l'essayer soi-même...

 
Alexey Navoykov:
Les inaccessibles n'apparaissent donc pas, n'est-ce pas ?

Non, ils le font.

C'est la même chose en studio, d'ailleurs.

 
Sergei Vladimirov:

Non, ils le font.

Alors Metakvots devrait faire attention à cela. Pourquoi montrer des méthodes inaccessibles. Après tout, tout est caché pour la section protégée comme il se doit. Donc il devrait en être de même ici.
 
Sergei Vladimirov:

Non, ils le font.

C'est la même chose en studio, d'ailleurs.

Il est étrange que votre liste apparaisse après un point. Dans mon éditeur, cela fait longtemps que je dois commencer à taper après un point. Une liste n'apparaît après un point qu'après deux caractères (c'est ainsi que l'éditeur est configuré - pour faire apparaître une liste après deux caractères). C'est très bien si vous connaissez les noms des méthodes souhaitées. Problème, si vous ne le savez pas - vous devez ouvrir le fichier de classe et lire ce qu'il contient.

C'est le genre d'intelligence... Il y a longtemps...

1...169516961697169816991700170117021703170417051706170717081709...3184
Nouveau commentaire