Fermer une fenêtre d'une autre application

Réponses

• schlum Membre

  juin 2007 22:59 modifié #2

  tell application "iTunes" to close window "iTunes"
  
• System

  juin 2007 juin 2007 modifié #3

  dans 1182603382:

  
  

  tell application "iTunes" to close window "iTunes"
  

  
  

  
  
  Ha.. j'ai cherché pendant 1 heure avec AppleScript... et j'ai pas tenté ça..
  J'avais essayé des trucs du genre "tell application "iTunes" to close window end tell" et ça ne marchait pas
  
  Merci schlum 
• schlum Membre

  juin 2007 22:59 modifié #4

  C'est parce qu'il faut lui dire quelle fenêtre  :P
  window 1 ou window "iTunes"
• elf Membre

  juin 2007 22:59 modifié #5

  Il dois bien y avoir un moyen de le faire en Cocoa / Carbon non? Car l'AS c'est lourd lent et pas joli (bon je troll là  :P).
• schlum Membre

  juin 2007 22:59 modifié #6

  Euh... Tu sais que même dans ton Framework Cocoa chéri, il y a des AppleEvents ?  :P
  Quand on glisse des documents du Finder sur une application (mode droplet) ou sur son icône dans le Dock, à  ton avis, ça passe comment ? 
• elf Membre

  juin 2007 22:59 modifié #7

  Ouaip, je connais les AE. D'ailleur je les hais, ces trucs pourris qui nous vienne de MacOS9 et de sa vielle Toolbox. J'me rapelle encore avoir à  les utiliser il y a 5ans sous OS9. C'était horrible et immonde, je pigais absolument rien de ce que je fesais et j'était un train de crier à  l'aide à  mon oncle qui lui savais plus ou moins ce qu'il fesais. Euh, +- parce que il passais les 50% du temps dans la doc, et les autres 50% à  se demander pourquoi son AE marchais pas. Je ne sais pas si c'est devenu plus facile à  écrire sous OSX, mais je n'ai plus eu à  les utiliser depuis.
  
  Enfin bref, l'AS est un language de script qui envoie des AE, mais il faut que le processeur l'interprete et c'est assez lent souvent.
  
  
• schlum Membre

  juin 2007 juin 2007 modifié #8

  En même temps, si c'est juste pour fermer une fenêtre, pas besoin que ça soit un foudre de guerre...  ;D
  Je ne pense pas qu'on puisse "communiquer" entre applications sans AppleEvents.
  (Sauf cas spécifique bien sûr... Quand on a codé les deux applis et qu'on a mis un système de "pipe" au autre queue par exemple)
• System

  juin 2007 22:59 modifié #9

  dans 1182679589:

  
  (Sauf cas spécifique bien sûr... Quand on a codé les deux applis et qu'on a mis un système de "pipe" au autre queue par exemple)
  

  
  
  Heureusement qu'on sait de quoi tu parles  :P
• AliGator Membre, Modérateur

  juin 2007 22:59 modifié #10

  Et puis quand tu compiles ton AppleScript dans un script compilé, et que tu rajotues ce dernier à  ton appli Cocoa, pour demander ensuite d'executer donc cette version pré-compilée, ben y'a plus la perte de temps du préprocessing du script
  
  Mais c'est clair que pour un cas comme ça franchement c'est ridicule de parler de perte de temps pour une action de ce genre où on n'est pas à  un quart de seconde près et où en plus le script est on ne peut plus simple
  
  Sinon pour info, les différents moyens de communiquer entre applications : Interprocess Communication
• schlum Membre

  juin 2007 22:59 modifié #11

  dans 1182683283:

  
  

  dans 1182679589:

  
  (Sauf cas spécifique bien sûr... Quand on a codé les deux applis et qu'on a mis un système de "pipe" au autre queue par exemple)
  

  
  
  Heureusement qu'on sait de quoi tu parles  :P
  

  
  
  Effectivement, ça c'est de la perle !  :kicking:
• Mala Membre, Modérateur

  juin 2007 22:59 modifié #12

  Je suis choqué! 
  
  PS: pour la peine, je viens de mettre objective-cocoa sous contrôle parental. 
• System

  juin 2007 22:59 modifié #13

  dans 1182683512:

  
  Sinon pour info, les différents moyens de communiquer entre applications : Interprocess Communication
  

  
  
  J'utilise NSDitributedNotification pour mon appli du moment :
  

  <br />[[NSDistributedNotificationCenter defaultCenter] addObserver:self<br />							 selector:@selector(changeData:)<br />								 name:@&quot;com.apple.iTunes.playerInfo&quot;<br />							&nbsp;  object:nil];<br />
  

  
  changeData: est appelée à  chaque fois que iTunes change de track
• schlum Membre

  juin 2007 22:59 modifié #14

  Yep, mais pour ça, il faut que l'application ait été conçue pour.
  Or iTunes n'écoute pas les notifications qui lui disent de fermer la fenêtre (à  part les Apple Events  )
• System

  juin 2007 22:59 modifié #15

  dans 1182696259:

  
  Yep, mais pour ça, il faut que l'application ait été conçue pour.
  Or iTunes n'écoute pas les notifications qui lui disent de fermer la fenêtre (à  part les Apple Events  )
  

  
  En gros iTunes est un salaud...
• schlum Membre

  juin 2007 juin 2007 modifié #16

  Non, c'était une plaisanterie pour dire que gérer une communication entre deux applications sans passer par les AppleEvents, il faut être soit chanceux, soit assurer soi-même le développement des deux applications...
  iTunes est codé pour envoyer des notifications lors de certains événements, mais je doute qu'il soit codé pour écouter toutes les notifications perso qui passent et essayer de les comprendre :P
  
  D'où la communication standardisée via les AppleEvents...
  
  D'ailleurs, je serais étonné si "NSDistributedNotificationCenter" n'avait rien à  voir avec ces fameux AppleEvents !  ???
• schlum Membre

  juin 2007 22:59 modifié #17

  Après test, non, ça n'utilise pas les AppleEvents...
  
  "nextEventMatchingMask:untilDate:inMode:dequeue:"
  
  Il y a donc une queue quelque-part (je récidive, désolé !  ;D)
• elf Membre

  juin 2007 22:59 modifié #18

  dans 1182710233:

  
  

  dans 1182696259:

  
  Yep, mais pour ça, il faut que l'application ait été conçue pour.
  Or iTunes n'écoute pas les notifications qui lui disent de fermer la fenêtre (à  part les Apple Events  )
  

  
  En gros iTunes est un salaud...
  

  
  
  Non, en gros t'es paresseux... :P