Tous les Os que je connaissent travaille par �l�ment graphique non
recouvrant (soit un �l�ment graphique est � cot� d'un autre, soit il
est
dedans mais jamais � cheval).
Ce que je citait comme exemple pour les OS c'est par exemple des bo�tes
de dialogues les unes sur les autres: si un petit bout de bo�te est
visible entre deux autres, comment l'OS sait-il que si l'on clique l�
il faut aller chercher cette bo�te ?
Un �l�ment graphique se conna�t, conna�t son p�re et conna�t ces fils.
Ici je n'ai aucune hi�rarchie: ce sont une s�rie d'�l�ments graphiques
qui sont entre eux sur un m�me composant Swing (ce ne sont pas des
composants en eux-m�me)
Quand un clic survient, l'OS conna�t la fen�tre cliqu�e (il maintient
la
liste des fen�tres � l'�cran et l'ordre d'affichage).
La fen�tre conna�t ces fils et d�termine celui qui a �t� cliqu�
Elle lui demande de d�terminer l'�l�ment cliqu�.
Le Fils de la fen�tre regarde ces fils et d�termine celui qui a �t�
cliqu�,
etc...
Cet r�cursivit� s'arr�te quand un �l�ment n'a pas de fils cliqu�, c'est
alors lui qui re�oit l'�v�nement de clic.
Voil� en gros le principe (chaque OS a des subtilit�s).
Je vois, mais en fait ca ne s'applique pas � mon cas =)
Pour le programmer en java, c'est pareil, tant qu'il n'y a pas de
recouvrement.
En cas de recouvrement, il faut pouvoir d�terminer parmis les fils
possible
celui qui est le plus pertinent. Cela d�pend de ton programme et pose
souvent probl�me.
Cas classique un segment tout petit. Ton interface permet de
s�lectionner
les points de contr�le (les extr�mit�s) pour modifier les extr�mit�s,
et le
segment en lui m�me pour le d�placer sans modifier sa longueur et son
angle.
A priori les points de contr�le sont prioritaire � la s�lection du
segment.
Pour pouvoir s�lectionn� les point de contr�le on accepte une erreur
de 4
pixels (cliqu� sur un pixel parmis 1600x1200 n'�tant pas �vident du
tout).
Si ton segment fait moins de 8 pixels, on ne pourra jamais le
d�placer, on
s�lectionnera invariablement les points de contr�le et jamais le
segment.
Pour g�rer les formes tu peux utiliser l'API AWT (voir java.awt.Shape
et sa
m�thode contains(Point2D p).
Ok
Tu peux aussi utiliser la notion de couche d'�l�ment (� la sauve
z-buffer si
tu as fait de la 3D), mais c'est complexe � g�rer et si tu as beaucoup
de
donn�es c'est tr�s peu pertinent.
En fait je crois que c'est n�anmoins la meilleure solution � mon
probl�me
En cartographie, il est fr�quent de d�couper la carte en tuile et de
d�terminer la tuile cible du clic et de ne travailler que sur les
�l�ment de
la tuile. Cela �vite de monter en m�moire les routes, les chemins, les
rivi�res, les for�ts, les laces,... proches de Marseille alors que le
clic
c'est fait sur Lille.
Des "tuiles" ? Quezako ?
Voil� un bref aper�u de la technique. Maintenant cela d�pend beaucoup
de ton
projet.
A+
--------------------------------------------------------------------
Erik Mazoyer, Chef de projet
HyperOffice
6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex
T�l. 01 41 96 96 76
Fax 01 41 96 96 77
M�l [EMAIL PROTECTED]
-----Message d'origine-----
De : Aurelien Mazurie [mailto:aurelien.mazurie@;free.fr]
Envoy� : jeudi 24 octobre 2002 11:17
� : [EMAIL PROTECTED]
Objet : Une vieille �nigme (pour moi en tout cas)
Bonjour � tous,
Je programme depuis maintenant pr�s de 10 ans mais il y une chose,
utilis�e dans tous les OS ayant une GUI depuis la nuit des temps, que
je ne sais toujours pas faire (enfin, disons que j'ai trouv� un moyen
d�tourn� de le faire): c'est le fait de savoir quel objet affich� �
l'�cran (objets qui peuvent se recouvrir, partiellement ou totalement)
est sous le curseur de la souris (pour que, lorsque l'utilisateur
clique, l'on sache � quel objet envoyer le message).
A l'�poque o� j'avais programm� un jeu utilisant ce genre de
fonction
j'avais r�solu le probl�me en cr�ant un �cran virtuel o�, d�s lors
qu'un objet �tait affich� dans l'�cran r�el, il laissait une emprunte
de pixel d'une couleur donn�e (ie. si une bo�te de dialogue �tait �
afficher, je dessinai dans l'�cran virtuel un rectangle au m�me
endroit, avec une couleur unique: par exemple la couleur 1 si c'�tait
l'objet n�1). Ensuite, � chaque clic de souris il me suffisait de lire
la couleur du pixel aux coordonn�es correspondantes dans l'�cran
virtuel, et je connaissait l'ID de l'objet � modifier en cons�quence.
Ca marchait tr�s bien pour un �cran de petite taille (320x200, le
bon
vieux mode 13h...) et pour le nombre d'objets � g�rer (256 couleurs,
donc 255 objets + noir), mais d�j� � l'�poque je me demandait comment
faisait les OS comme Windows 3.1 pour faire la m�me chose.
Or j'ai aujourd'hui � faire quelque chose de similaire en Java: j'ai
plusieurs objets � l'�cran (dessin�s dans un BufferedImage), qui
peuvent se recouvrire mais que je veux pouvoir s�lectionner � la souris
sans passer par une d�tection de "l'objet le plus proche par sa
position par rapport � celle du curseur". En r�sum�, il faut que je
r�solve cette tr�s vieille �nigme pour moi et apprenne comment font les
OS de la plan�te pour r�gler ce probl�me...
J'ai trouv� une librairie �crite en Java qui fait ca, et qui sert �
afficher des donn�es g�ographiques (dans les exemples on a ainsi une
carte d'un pays, et la souris allume les diff�rentes r�gions
lorsqu'elle passe dessus); mais les sources sont tellement grosses que
je ne suis pas parvenu � trouver la m�thode utilis�e...
Quelqu'un sait-il comment on r�alise cet exploit quotidien ?
Aur�lien Mazurie
