Clic maintenu déplacé avec viewer

**cmail** · 16/04/2014, 12h29

Sur cette page de test , je perds la fonction du clic enfoncé déplacé (pour déplacer la carte) quand je suis sur mon kml départemental (ou kml des fleuves). Celui-ci est toujours présent quand je suis sur la carte ign.
Comment réactiver cette fonction sur les kml ?

**jrenard** · 17/04/2014, 17h09

On est sur le coup, le temps de faire quelques essais sur le code de cette page de test et on essaie de revenir avec une solution satisfaisante.

**Viglino** · 19/04/2014, 19h23

Bonjour,

Le problème vient du Control.SelectFeature, il faut préciser qu'il ne doit pas garder l'évènement clic pour lui lorsqu'on clique sur un objets (en particulier un polygone).
Il faut ajouter aux options du OpenLayers.Control.SelectFeature :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

handlersOptions:{feature:{stopDown:false}}

Ou de façon plus radicale modifier la valeur par défaut d'OL : OpenLayers.Handler.Feature.prototype.stopDown= false;

@+

**cmail** · 20/04/2014, 14h31

Bonjour Jean-Marc, (Je crois que je t'ai appelé Marc la dernière fois!

)
1/ A mes premiers essais, OpenLayers.Handler.Feature.prototype.stopDown= false; répond à ma question.
2/ Par contre ta première réponse me laisse perplexe. A moins que je me plante dans l'écriture, j'ai écrit dans mon code sur ma page d'essai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 var clickCtrlOpts = OpenLayers.Util.extend(viewer1.getMap().getPopupDefaults('KML'), {
			onSelect : clicCommune,
				autoActivate : true,
		handlersOptions : {
				feature : {
					stopDown : false
				}
			}
		});
clickCtrl = new OpenLayers.Control.SelectFeature([layerCommune1, layerEau1], clickCtrlOpts);

Ce qui correspond bien à ta proposition. Non? Et pourtant cela n'est pas ici opérationnel, mais je dois avoir fait une erreur ailleurs...

**Viglino** · 21/04/2014, 10h40

Bonjour,

Oui c'est bien cela (voir ici http://www.developpez.net/forums/d10...polygones-kml/).
Par contre, l'API ajoute automatiquement un SelectControl aux couches KML (qui lui n'a pas l'option stopDown=false).
Il faut désactiver le comportement par défaut de l'API.
Il me semble qu'il faut ajouter "preventDefaultBehavior : true" à la création du layer KML, au même niveau que les formatOptions :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

viewer1.getMap().addLayer("KML",nom,href,opt,{formatOptions :{extractStyles : true}, preventDefaultBehavior : true });

@+

**cmail** · 21/04/2014, 18h44

Par contre, l'API ajoute automatiquement un SelectControl aux couches KML (qui lui n'a pas l'option stopDown=false).

OK.

Il me semble qu'il faut ajouter "preventDefaultBehavior : true" à la création du layer KML, au même niveau que les formatOptions :

Très juste. J'avais négligé... Mais à mes premiers essais, ce paramètre est seulement nécessaire sur 1 seul des kml chargés. A confirmer par un plus grand nombre de possibilités...

**cmail** · 24/04/2014, 11h34

Je reprends cette discussion sous un autre aspect (sujet étroitement lié): la gestion du curseur lors du clic maintenu-déplacé.

En faisant appel à OpenLayers.Handler.Feature.prototype.stopDown= false; on perd le css "cursor: move" quand on fait le clic maintenu. Par contre quand on paramètre preventDefaultBehavior : true, on le retrouve bien, mais on perd alors le "cursor: pointer" sur les features cliquables

Et je m'y perds un peu pour rationaliser le tout, surtout en faisant appel à OpenLayers.Handler.Feature.prototype.stopDown= false; que je privilégie...

**cmail** · 12/05/2014, 10h47

Encore un constat autour du clic maintenu déplacé:
Sur vos exemples officiels, par exemple http://depot.ign.fr/geoportail/api/d...ortalLike.html, après l'utilisation des outils de mesure (longueur et surface), on perd le clic maintenu déplacé. Ce n'est pas logique et normal. Non?

**jrenard** · 12/05/2014, 16h40

Bonjour Christian,

On ne perd pas vraiment le clic maintenu-déplacé, car il suffit de re-sélectionner l'outil main pour le récupérer (ce qui est somme toute logique: si l'outil de déplacement n'est pas sélectionné, le déplacement n'est pas possible).

Mais derrière cela se cache peut-être la suggestion suivante: lorsque l'on décoche un outil de mesure ou de recherche, l'outil main devrait être re-sélectionné par défaut, de manière à ce qu'au moins un outil soit sélectionné ?

Dans ce cas, c'est à discuter.

**cmail** · 12/05/2014, 18h01

lorsque l'on décoche un outil de mesure ou de recherche, l'outil main devrait être re-sélectionné par défaut, de manière à ce qu'au moins un outil soit sélectionné ?

Oui. Si je ne dis pas de bêtise, comme l'outil main (qui donne accès au clic maintenu déplacé) est appelé au chargement de l'api, et que l'utilisateur moyen est habitué à cette ressource d'origine (sans vraiment faire le lien direct!), il est perturbé quand il quitte les outils de mesure (ou de recherche) de ne pas le retrouver automatiquement... Ce qui fut mon cas! D'autant plus que le déplacement par les touches du clavier reste toujours actif contrairement à ce que tu dis

si l'outil de déplacement n'est pas sélectionné, le déplacement n'est pas possible

...
Si vous n'accédez pas (hélas!) à cette demande, pouvez-vous me dire comment je dois mettre en place les conseils de Viglino et dans quelles surcharges, car mes essais ne sont vraiment pas concluants!

**jrenard** · 12/05/2014, 18h26

Envoyé par cmail

D'autant plus que le déplacement par les touches du clavier reste toujours actif contrairement à ce que tu dis [COLOR=#3E3E3E]...

Certes, la rigueur aurait dû me faire dire "si l'outil main n'est pas sélectionné, le déplacement à la main (ie. à la souris) n'est pas possible". Ce qui reste logique, n'est-ce pas ?

**mga_geo** · 13/05/2014, 10h07

Non ce n'est pas logique : la main est sélectionnée par défaut au chargement de l'api. Après déselection d'un autre outil, il faut revenir au mode par défaut.

**cmail** · 13/05/2014, 10h31

Un constat:
Après avoir sélectionné l'outil de recherche.
1/ Si on le ferme en recliquant sur l'icone "jumelle" on perd bien l'outil "déplacement à la main">> choix actuel de l'IGN.
2/ Mais si on le ferme en cliquant sur le x du panneau de recherche, l'outil "déplacement à la main" est sélectionné automatiquement. ++

Du point de vue d'un utilisateur rigoureux, il y a dans cette alternative une équivoque à régler. A vous de voir...
De mon coté, je pense que le "déplacement à la main" doit être systématiquement validé quand on ferme un outil.

(Cette approche de rationalisation permettrait aussi d'éviter la double (voire triple avec le bouton d'impression que je n'aborderai pas ici) approche d'utilisation des boutons d'outils, et qui n'est pas très ergonomique pour des utilisateurs lambda :
1/ les deux boutons "déplacement à la main" et "se rapprocher" sont sur le mode "exclusion alternative" : on passe de l'un à l'autre, mais le double clic sur ces boutons n'a aucun effet.
2/ Alors que les autres boutons (mesure et recherche) intègrent ce double clic pour l'ouverture et la fermeture des outils.)

Bref, de mon coté, sans préjuger sur vos décisions, comment opérer correctement pour remettre systématiquement le "déplacement à la main" quand je quitte les outils de mesure?

**jrenard** · 13/05/2014, 11h16

Envoyé par cmail

Un constat:
Après avoir sélectionné l'outil de recherche.
1/ Si on le ferme en recliquant sur l'icone "jumelle" on perd bien l'outil "déplacement à la main">> choix actuel de l'IGN.
2/ Mais si on le ferme en cliquant sur le x du panneau de recherche, l'outil "déplacement à la main" est sélectionné automatiquement. ++

Judicieuse remarque. Sur le fond, j'adhère à ton analyse : il y a une certaine incohérence dans le fonctionnement. Le mieux serait encore qu'on la corrige de notre coté.
On va voir ce qu'on peut faire.

**jrenard** · 16/05/2014, 14h34

Bonjour Christian,

Envoyé par cmail

Bref, de mon coté, sans préjuger sur vos décisions, comment opérer correctement pour remettre systématiquement le "déplacement à la main" quand je quitte les outils de mesure?

Je reviens sur ce point. En attendant que nous corrigions ça de notre coté, une façon de faire peut être la suivante : sur chaque outil (de mesure, de géolocalisation), ajouter une fonction onclick. Cette fonction teste l'état actif/inactif du bouton via son nom de classe (à savoir est-ce que le nom de classe se termine par "ItemActive" ou "ItemInactive"). Si l'état est actif, cela signifie que le bouton est en cours de déselection, et alors on force la réactivation de l'outil de déplacement à la main. Le code suivant, à répéter sur chaque bouton nécessaire en adaptant le nom d'id et le nom de classe (mais dans le nom de classe, en conservant toujours "ItemInactive") :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
// Activation du déplacement à la fermeture de l'outil
document.getElementById("OpenLayers.Control.Measure_601").onclick = function() {
	if (document.getElementsByClassName("olControlMeasurePathItemInactive").length!=0) {
		viewer.getMap().getControlsByClass("OpenLayers.Control.Navigation")[0].activate();
	}
};

**cmail** · 16/05/2014, 17h05

Merci Jeremy
A cet url le résultat de tes conseils qui m'amène quelques questions complémentaires (J'en profite!)

1/ Tout d'abord, pourquoi sur l'outil MeasurePolygon on constate quelques dysfonctionnements: le style se perd, la mesure ne s'effectue pas... Mais on retrouve bien le clic maintenu après.
2/ Comme les 2 OpenLayers.Control.Measure traités sont référencés par leur id, on introduit leur indice. Ce qui me chagrine un peu car en fonction des modifs incessantes, celui-ci peut changer... J'essaye donc de les attaquer (soit en getElementsByClassName, soit via jquery) par leur class olButton, mais cela ne répond pas. Ton retour me serait utile pour mieux comprendre leur ordonnancement.
3/ Tu nous dis :"En attendant que nous corrigions ça de notre coté...." Cela veut dire que dans la prochaine version, cela sera intégré? Pour savoir à quel moment j'enlèverai ces rustines....

**jrenard** · 16/05/2014, 17h13

Envoyé par cmail

1/ Tout d'abord, pourquoi sur l'outil MeasurePolygon on constate quelques dysfonctionnements: le style se perd, la mesure ne s'effectue pas... Mais on retrouve bien le clic maintenu après.

Je ne reproduis pas ce comportement. Ce qui me praît étrange, c'est que je ne reproduis pas non plus la récupération du clic maintenu après coup. M'as-tu bien donné la bonne url ?

Envoyé par cmail

2/ Comme les 2 OpenLayers.Control.Measure traités sont référencés par leur id, on introduit leur indice. Ce qui me chagrine un peu car en fonction des modifs incessantes, celui-ci peut changer... J'essaye donc de les attaquer (soit en getElementsByClassName, soit via jquery) par leur class olButton, mais cela ne répond pas. Ton retour me serait utile pour mieux comprendre leur ordonnancement.

Je suis entièrement d'accord avec toi, et je suis tout autant chagriné. Je me suis heurté aux mêmes problèmes en utilisant les noms de classe, et pour l'instant je ne vois pas comment contourner cela. D'où ma suggestion d'utiliser l'id, avec les contreparties négatives que cela engendre.

Envoyé par cmail

3/ Tu nous dis :"En attendant que nous corrigions ça de notre coté...." Cela veut dire que dans la prochaine version, cela sera intégré? Pour savoir à quel moment j'enlèverai ces rustines....

Je ne peux rien promettre. Je suis en train de fouiner un peu dans le code bas niveau pour essayer de cibler une correction. Mais pour l'instant je n'en suis qu'au stade de l'exploration.

**cmail** · 16/05/2014, 18h13

Je ne reproduis pas ce comportement.

Comme c'est étrange car je confirme :
1/ Sous chrome ou IE, ici, je n'ai pas la perte du style dans la mesure du polygone, mais la correction n'est pas prise en compte puisque le clic maintenu ne se retrouve pas. Tu dois avoir fait tes essais avec un de ces navigateurs. Non?
2/ Par contre sous FF, la correction est bien prise en compte pour les 2 outils, mais le style disparait (pas de trace bleue) dans la mesure du polygone. Je n'avais testé que sous FF.

Pour l'ancien 2. Je vais essayer de comprendre à tête reposée...

Pour l'ancien 3. Tiens moi au courant de tes prochaines avancées pour se coordonner au mieux...

**jrenard** · 21/05/2014, 12h21

Envoyé par cmail

Comme c'est étrange car je confirme :
1/ Sous chrome ou IE, ici, je n'ai pas la perte du style dans la mesure du polygone, mais la correction n'est pas prise en compte puisque le clic maintenu ne se retrouve pas. Tu dois avoir fait tes essais avec un de ces navigateurs. Non?
2/ Par contre sous FF, la correction est bien prise en compte pour les 2 outils, mais le style disparait (pas de trace bleue) dans la mesure du polygone. Je n'avais testé que sous FF.

J'ai beau faire des tests sous tous les navigateurs, de mon coté je réitère à chaque fois ce que je disais plus haut : aucune perte de style sur les polygones, et aucun retour au clic déplacement à la déselction de l'outil de mesure.