2010-03-30 7 views
3

Dans un monde sain d'esprit, cela fonctionne comme prévu:Flash/AIR AS3: comparer les contenus Screen.screens

var array:Array = ['a','b','c']; 
trace(array.indexOf(array[0])); // returns 0 

Dans un monde fou, cela se produit:

trace(Screen.screens.indexOf(Screen.screens[0])); // returns -1 

... si Screen.screens est un Array des instances disponibles de Screen, pourquoi ce tableau ne peut-il pas donner un indexOf précis à l'un de ses propres enfants?

modifier - Pour prendre un peu plus loin, vérifier cela:

for each(var i:Screen in Screen.screens){ 
for each(var j:Screen in Screen.getScreensForRectangle(this.stage.nativeWindow.bounds)){ 
    trace(i, j, i == j); // returns false 
    trace(i.bounds, j.bounds, i.bounds == j.bounds); // returns false 
} 
} 

Au moins un Screen énumérés dans Screen.screens devrait être identique à un Screen dans Screen.getScreensForRectangle(this.stage.nativeWindow.bounds) - mais même si vous comparez les Screen.bounds, il ne correspond toujours pas, malgré les deux objets Rectangle ayant les mêmes dimensions!

Folie, mesdames et messieurs! Vous ne voulez même pas voir la solution que je mets ensemble (indice: il consiste à comparer les valeurs de Screen.bounds.toString() pour le contenu de Screen.screens)

+0

Je sais, "l'écran, l'écran, les écrans de points d'écran de points d'écran." Mais je voulais donner un vrai exemple. –

Répondre

2

Ceci est une estimation éduquée, mais depuis Screen.screens est en lecture seule, et (?) modifier le tableau qu'il retourne n'a aucun effet, je pense que c'est un pari assez sûr qu'en interne, chaque fois que vous l'appelez Flash génère et retourne un nouveau tableau d'objets Screen (plutôt que de garder un ensemble interne d'objets Screen et vous donnant accès à eux). Lorsque vous appelez:

Screen.screens.indexOf(Screen.screens[0]) 

vous faites deux accès séparés à Screen.screens, donc si chacun de ces appels renvoie un tableau différent des objets, il est facile de voir pourquoi vous ne trouvez aucune correspondance - parce que la méthode indexOf tests pour === égalité, donc deux objets Screen différents ne correspondent pas, même si elles contiennent des informations sur le même écran physique.

La solution consiste à récupérer une copie de la matrice d'écrans et à l'utiliser. Cela fonctionne bien:

var scr:Array = Screen.screens; 
trace(scr.indexOf(scr[0])); // returns 0 
+0

Nice - Je parie que vous avez tout à fait raison, c'est ce qui se passe. Est-ce que cela fait suite à une sorte de pratique courante, je me demande? Parce que bien que la partie de tableau en lecture seule ait du sens, je m'attendrais à ce que ce soit un tableau qui soit mis à jour derrière les scènes chaque fois que les écrans sont changés, au lieu de reconstruire le tableau chaque fois qu'il est demandé ... merci, c'est juste ce que je voulais. –

+0

Je pense qu'il faut généralement se méfier des tests d'égalité des objets ... si une API vous donne une référence au même objet que la dernière fois, ou un nouvel objet, c'est finalement un détail de l'implémentation de l'API qui est toujours le plus sûr ne pas avoir de dépendance. Après tout, vous ne vous inquiétez pas vraiment si vous avez deux références au même objet, ce qui vous intéresse, c'est si elles se réfèrent au même écran physique ... ce qui est difficile à déterminer dans ce cas, mais sémantiquement, vous voyez ce que je veux dire. ;) – fenomas

+0

Mais pour répondre à votre question, généralement je suppose que quelque chose comme Screen, qui est juste un morceau de propriétés informationnelles, est susceptible d'être un objet jetable. Quelque chose comme NativeApplication.openedWindows, qui vous donne des objets NativeWindow très complexes, pourrait être plus susceptible de donner des références à un objet persistant.Et après un test rapide, il semble que c'est le cas. Mais mieux vaut ne pas compter dessus si vous pouvez l'éviter, bien sûr .. – fenomas