Erreurs, bugs, questions - page 1970

Nouveau commentaire
 
pavlick_:

C'est-à-dire mettre la couleur de l'objet à clrNONE, puis lire la couleur de l'objet.

lire la couleur d'un autre objet
 
A100:
lire la couleur d'un autre objet

Oui, merci. J'y ai corrigé les noms, mais l'erreur est toujours là.

 
pavlick_:

donne à l'objet la couleur clrNONE, puis lit la couleur de l'objet, la compare avec clrNONE - elles ne correspondent pas.

Alert("clr == clrNONE ?  ", (color)clr == clrNONE); // true

clrNONE - tous les bits de 4 octets sont remplis de uns.

ulong clr - tous les bits de 8 octets sont remplis de uns.

 
pavlick_:

Oui, merci. J'y ai corrigé les noms, mais l'erreur est toujours là.

En fait, dans ObjectGetInteger, au lieu de

void ObjectGetInteger( long& x ) { x = clrNONE; }

il va

void ObjectGetInteger( long& x ) { x = -1; }

solution : écrire x au lieu de x partout.

(color)x
 
fxsaber:

clrNONE - tous les bits des 4 octets sont remplis de uns.

ulong clr - tous les bits de 8 octets sont remplis de uns.

Il y a une sorte d'erreur ici, je pense.

1. clrNONE est un nombre positif de 4 octets puisque Alert( long(clrNONE) ) == 4294967295 (s'il était négatif (signe de la couleur), il passerait en moins)

2. Nous l'avons converti en long dans SetInteger, la valeur n'a pas pu changer.

3. Pourquoi est-ce que j'obtiens un nombre non primaire dans SetInteger ?

Soit la couleur à l'intérieur de la borne est convertie en un type signé, int par exemple, et croît ensuite lorsqu'elle est convertie en long, soit quelque chose d'autre.

 
Encore une fois, merci beaucoup à vous tous. Je suis presque sûr que la couleur intérieure est coulée à la signature, avec coulage inversé et erreur. Eh bien, c'est aux développeurs d'écrire un ObjectGetInteger() valide, cela ne prend que quelques caractères : ObjectGetInteger() { return long((uint)internal_clr) ; }
 
S'agit-il d'une erreur (tableaux différents) ou non ?
void OnStart()
{
  short Data[] = {1};
  short Data2[];
  
  StringToShortArray(ShortArrayToString(Data), Data2);
//  StringToShortArray(ShortArrayToString(Data), Data2, 0, ArraySize(Data)); // так массивы совпадут
  
  ArrayPrint(Data);  // 1
  ArrayPrint(Data2); // 1 0
}
 
fxsaber:
S'agit-il d'une erreur (tableaux différents) ou non ?
non, juste un dernier 0 ajouté.
 
Комбинатор:
Non, ça ajoute juste un 0 final.

Ajout d'une ligne au-dessus - spécifié pour copier la longueur de la ligne. Ça a commencé à correspondre. C'est-à-dire qu'il s'avère que le paramètre d'entrée count = -1 ajoute zéro à la fin, tandis que count = StringLen n'ajoute rien. Nyuansyk !

 
fxsaber:

C'est-à-dire qu'il s'avère que le paramètre d'entrée count = -1 ajoute zéro à la fin, tandis que count = StringLen n'ajoute rien. Nuncie !

Eh bien, en mql, les chaînes de caractères sont des chaînes nulles, c'est-à-dire un ensemble de caractères avec un '\0' à la fin. StringLen ne tient pas compte de ce 0, alors que la conversion en tableau tient compte de la longueur totale.

Demandez aux développeurs les raisons de cette différence. Mais je ne peux pas dire que c'est trop pénible.

1...196319641965196619671968196919701971197219731974197519761977...3184
Nouveau commentaire