Bonjour
J'ai un petit probleme avec une application que je dois développer en java.
En fait cette application doit gérer le MDI.
Ce que je n'arrive pas à faire c'est un lien entre les différentes fenetre de l'appli (JInternalFrame) et le menu que j'ai créé et qui liste toutes les fenetres ouvertes un peu comme le menu documents ou fenetres de word).
J'ai besoin de ce lien pour pouvoir tenir à jour la liste des fenetres ouvertes.

tu fou une référence de chaque internalFrame dans une hashmap  

merci pour ta réponse :-)
une reference ? c possible ça ?
et une hashmap m'en suis jamais servi... ça consiste en quoi ?
dsl je débute

impeccable, ca répond à  une question que j'allais poser...

mais utiliser une table de hash, ca t'oblige à recreer ta fenetre, la hasher, et voir si t'a déjà une fenetre de ce type dans la table non ?
 
Edit : g rien dit : un iterator suffira ...
 
celà dit je vois tjs pas l'intéret de la table de hash sur une bete collection genre ArrayList, ou même mieux un Set (qui empeche les doublons)...
 
tu fous tes fenetres dans la collection, et tu l'itères en testant un attribut donné (comme le titre de la fenetre dont on peut supposer qu'il est unique) pour voir si elle est pas ouverte...

s'il ve recuperer sa frame en une instruction ?
 
 
avec ton arrayList,t'auras forcement une boucle ce sera plus long.
 
blueman_82>> une hashMap en gros c'est une clé => un objet
 
la en l'occurence:
uneCléUniqueCorrespondantAUneFrame=>InstanceDeTonInternalFrame

oui mais il l'a récupère comment la clé ?
 
il crée une fenetre, la hash, la fout dans la map selon ce hash...
 
ensuite il la sort comment ? faut connaitre le hash, et il le retrouve où ? je croyais qu'on se servait des hashmap parce que par ex en hashant quelques attributs, on avait un hash avec une dispersion correcte, et que du coup, on pouvait facilement refabriquer le hash pour récupérer ce qu'on avait mis dans la table...

euh, tu confondrais pas un peu deux notions là?
 
j'imagine que l'idée de very (j'ai pas lu tout le topic) c'est d'assigner un "nom" à une frame... tu as besoin du hash pour récuperer un objet dans une hashmap, mais juste de la clé, qui peut etre completement arbitraire par rapport à l'objet que tu lui associs. D'ailleurs faudrait parler d'une Map et nom d'une HashMap.. le coup du hash c'est une bidouille internet à l'implementation HashMap de Map (qu'il est, certes, interessant de connaitre si on veut bien utiliser HashMap et/ou bien choisir son implementation de Map en fonction de l'utilisation qu'on en aura)

c possible...
 
je croyais que ct le hash moi la clé...
 
en gros : mettons que l'objet toto aie 2 attributs : un int et le nom ...on surcharge hash pour dire que c par ex le hash du int + le hash du nom, et ca donne un bo hash qui sert de clé pour retrouver toto dans la table...
 
et du coup, sachant les valeurs des attributs int et nom, on peut refaire le hash, et récupérer toto...c pas comme ca que ca s'utilise une hashmap ? (y'a un topic de benou je crois là dessus, et c ca qu'il dit si j'ai bien suivi)...

je comprend rien :-(
moi ce que je veux faire, c'est en quelque sorte lier un JmenuItem à une JInternalFrame. dans le but de quand je ferme une JInteralFrame ben ça supprime le JmenuItem correpondant
c'est reloux de pas etre bon en java lool

soit t'as mal suivi, soit il a mal expliqué, soit c'est moi qui te comprend pas

bon, ensuite

 
là, qu'est-ce qui se passe?
en (6), la map utilise la methode hashcode de String pour aller mettre "a" dans le seau qui va bien.
Pour recuperer "a", je ferai m.get("proute" ), et HashMap appelera de nouveau l'hashcode de String pour trouver le seau qui va bien, et ensuite me renverra "a" si ce qu'il trouve dans le seau est equals(), sinon il continue (bon, je reste volontairement flou sur l'histoire des seaux, faudrait relire, mais bref)
 
bref, idem pour les 2 autres cas, sauf que là ça sera forcement la methode hashcode de Toto qui sera utilisée, mais moi derriere pour recuperer le String "tralala" ou "d", je ferais m.get(b) ou m.get(c)
 
en clair, la methode hashcode, c'est pas un truc que tu utilises dans du code "business", c'est de la popote interne pour des trucs plus bas niveau... genre HashMap, donc.
 
 
   
 
(toute information contenue dans ce post est donnée sous reserve d'erreur non-contractuelle ... enfin un truc dans le genre)

-->blueman_82
 
heu, si j'ai suivi, tu veux qu'à n'importe quel instant t, t au max qu'une seule fenetre d'un type donné d'ouverte, c bien ca ? cad si t'a 3 fenetres titi toto tata, tu veux pas qu'on puisse ouvrir 2 titi en meme temps ?
 
ce sur quoi on discute, c le fait de ranger des références aux fenetres ouvertes dans une Collection, et l'idée c de vérifier si on a une référence à la fenetre avant de l'ouvrir : si oui, on va chercher la fenetre, sinon, on la crée, et range la référence dans le tableau...tout en pensant, avec des FrameEvent, à sortir la fenetre du tableau de ref qd elle est fermée

 
ce que tu veux me dire c qu'on peut mettre totalement n'importe quoi comme clé, la hashmap la hash, et rentre la valeur dans le bucket qui correspond à la clé...
 
question : que se passe-t-il si on rentre 2 trucs avec la meme clé ? (benou par le de sac de billes, ce qui implique que plusieurs choses peuvent se trouver dans la meme clé...ou alors qu'il stocke une collection comme objet correspondant à la clé)...
 
donc pour l'exemple courant, on dit que par ex on fait un getTitle() sur chaque frame, on peut ranger la frame selon sa clé "title", et donc pour récupérer la fenetre "toto", on va faire un get("toto" )... c ca ?

 
alors voila à quoi ressemble mon interface.
j'ai la possibilité via le mnu fichier d'ouvrir autant de fenetre que je veux.
à l'ouverture d'une fenetre, le menu Documents est aussi tot complété par un sous menu qui permet d'afficher la fenetre en question.
la difficulté du truc c'est de supprimer ses sous menu lorsque la fenetre "cible" a été fermée par l'utilisateur.

ahhhhhhhhhhhhh, tu veux faire comme le menu "Fenetres" en gros...
 
ben là c facile : tu colles un windowListener à tes internalFrame, et tu captures :  
 public void windowClosed(WindowEvent e) {
 
    }
 
cette méthode s'exécutera à la fermeture des fenetres...

à voir comment c'est implementé pour savoir comment il fait, mais le contrat dit que de toutes façons il vérifie avec un equals() avant de te renvoyer l'objet:

 
quand tu entres plusieurs object avec la même clé, seul les dernier reste.
quand tu entres plusieurs objets avec une clé differente, mais que ces clés ont un hashcode identique, tous ces objet restent dans la map, c'est juste anti-performant.
 
et donc pour l'exemple courant, oui.

 
oui biensur j'ai fait ça :-)
et j'arrive à fermer la fenetre sans soucis et récupérer l'event
mais le truc ce que je recupere pas l'objet jmenuitem pour pouvoir le supprimer à son tour

faut le foutre dans une collection quelconque, et tu le vire ensuite...par contre je sais pas si les menus ont un event pour forcer leur rafraichissement

nan ils ont pas d'event mais une methode pour supprimer un item quand tu passes l'objet en parametre

et ben tu utilises la hashmap comme l'a montré moinsmoins : en clé tu met le nom de la fenetre, et en objet le menuItem ...
 
du coup qd tu fermes une fenetre, tu récupères son titre, ca te donne le menuItem, et t'a plus qu'à le supprimer et à demander un refresh du menu (si c pas automatique après une suppression)

(sur l'event du menu tu recuperes le menuitem? )

(et sinon bah ce qu'a suggéré veryfree en premier, c'est de mapper la fenetre sur le menuitem, pas besoin d'une indirection sur le nom)

heu non pas du tout : je me demandais si qd on altérai un menu y'avait un event pour dire au menu qu'il avait changé (par ex qd t'altères une Table, le tablemodel a un event pour dire que les données ont pu changer, et qu'il faut faire un refresh)

 
cad concrètement ?
 
si g suivi son affaire, il veut que si on vire la fenetre, le menuitem saute aussi...

ha, visuellement.
euh je sais pas mais je crois que c'est "automatique"

map.put(frame, menuitem);
 
JMenuItem menuItemToRemove = map.get(frame);
menu.remove(menuItemToRemove);
 
 

lol je l'avais proposé en inversant...mais gt pas loin ...oui c pas con du tout en y réfléchissant

y'a des implementations de map bi directionnelles je crois, sinon.
(si on veut pas se faire chier, on agrege deux map et hop)

cad agéger ?

 
un truc dans la genre
 

c bien ce que je pensais...