win ? ouvrir les fichiers avec une seule instance de l'application - Page 1

yop,

bon le sujet n'est pas spécialement bien placé dans le sens où je ne sais même pas si la solution est spécifique à windows ou pas (je suppose que oui, mais vu que je sais pas par où commencer chercher... ^^)
je voudrais faire en sorte qu'une fois qu'un type de fichier a été associé avec mon application, quand j'ouvre un fichier de ce type et que l'application était déjà lancée, ça y ouvre le fichier plutôt que de lancer une deuxième fois l'application. quelqun saurait comment on code ça ?

mci

En principe c'est à l'application de gérer ça, puisque le système ne fait que lancer l'appli avec une commande.
Donc si c'est toi qui a codé l'application, ou que tu as accès au code source, ça se règle en vérifiant si l'application a déjà été lancée puis en faisant savoir à l'application initialement lancée qu'elle doit charger le ficher (Le principe est valable quelle que soit la plateforme, mais la réalisation diffère certainement beaucoup)... Et à ce moment là le topic serait mieux placé en partie programmation, mais la solution est relativement simple
Par contre si tu n'as pas accès au code de l'application et que ce genre de fonctionnalité n'est pas prévu dans l'application, bah tu peux pas *simplement*. Donc il faut avoir recours à un plugin, dans le meilleur des cas, sinon écrire un petit wrapper atour de l'application pour gérer ce que tu veux... Mais la solution dépend quoi qu'il arrive énormément de l'application.

Yoshi Cristal (./2) :
En principe c'est à l'application de gérer ça, puisque le système ne fait que lancer l'appli avec une commande.
Donc si c'est toi qui a codé l'application, ou que tu as accès au code source, ça se règle en vérifiant si l'application a déjà été lancée puis en faisant savoir à l'application initialement lancée qu'elle doit charger le ficher (Le principe est valable quelle que soit la plateforme, mais la réalisation diffère certainement beaucoup)... Et à ce moment là le topic serait mieux placé en partie programmation, mais la solution est relativement simple

C'est effectivement le cas, c'est cette solution en question qui m'interesse, et c'est aussi pourquoi j'ai précisé que le topic était très probablement mal placé ^^ (mais il n'y a pas de partie "programmation" générale, ou en rapport avec un système d'exploitation)

Bon alors la solution comme je l'ai dis c'est de vérifier (au démarrage et donc avant création des fenêtres, c'est mieux, sinon ça complique la vie ^^) si une autre instance de ton application existe, puis de lui transmettre un message.

Sous Windows: (Linux je sais pas )
Pour regarder si une autre instance de ton application existe, tu peux comme le suggère la documentation de Windows, créer un Mutex (et me demande pas ce que c'est même après lecture de la doc je comprends toujours pas...). Mais sans aller si loin, tu peux te reposer sur la simple présence d'une fenêtre dans le système.
Sous Windows les fenêtres sont identifiés par leur handle (HWND), par leur titre, et par leur classe de fenêtre. Ce qui est intéressant ce n'est certainement pas le titre, puisque ça ne donne absolument aucune information fiable sur la fenêtre... La classe de fenêtre par contre est bien plus intéressante, et assez fiable (si on prend un nom de fenêtre relativement peu courant et qu'aucun rigolo ne s'amuse à utiliser le même dans son application).

Pour trouver le handle d'une fenêtre en fonction de la classe, on utilise FindWindow[Ex] (la version sans le Ex devrait suffire), et si ça retourne NULL on en déduit qu'aucune fenêtre de cette classe n'a été créée donc l'appli n'a pas encore été lancée. Si ça retourne un handle, alors on suppose que c'est une fenêtre ouverte par notre application et on lui transmet le message en utilisant PostMessage ou SendMessage (SendMessage attend l'autre processus, donc "plante" si l'autre a planté, mais pas PostMessage), avec pour un numéro de message défini par quelque chose du type WM_USER, WM_USER + 1, WM_USER + 2, etc... (Puisque ce n'est pas un message windows standard)

Par contre dans le cas de comunnication inter-processus, tu ne peux pas transmettre de pointeurs puisqu'il n'y a pas partage de mémoire.
Mais dans le cas de l'ouverture d'un fichier tu n'a qu'une chaîne de caractère à transmettre, donc le plus simple est d'utiliser un Atom global, qui va partager ta chaîne à travers tout le système. (cf MSDN pour la documentation des 2-3 fonctions associées)
Bon par contre la taille est limitée à 255 caractères, donc tu devra peut-être avoir recours à la mémoire partagée (cherche GlobalAlloc sur MSDN ça devrait aller) mais le principe est le même.

Bref le seul truc à faire ensuite c'est dans ta procédure de fenêtre (je sais pas avec quoi tu code, mais normalement c'est accessible pour Delphi, C/C++ et Windows Forms) de gérer le message avec le numéro que tu aura choisi (c'est mieux d'en faire une constante) et c'est fini. (Bon bien sûr la mémoire globale il faut pas oublier de la libérer sinon ça fait une jolie fuite )

En C ça donne ça => http://goldencrystal.free.fr/vrac/UniqueInstanceDemo.7z (c'est juste une dizaine de lignes commentées éparpillées dans le fichier principal)

sw33t mci (FindWindow et PostMessage, c'est tout ce dont j'avais besoin, ça devrait aller sans problème ^^)

Le mieux dans l'absolue reste effectivemetn de faire:

1 -> Au démarrage l'application cherche a creer un MUTEX nommé ayant un nom unique a ton application (par exemple "nomapplication_monmutex") et si la creation echoue (donc qu'un mutex du meme nom existe deja) ton application suivre avec 2bis
2 -> La création n'échoue pas et ton application creer un pipe ou une boite a message (peut importe, en gros une IPC qui marche) avec un nom du genre "nomapplication_monipc"
3 -> Ton application fait tout ce qu'elle a à faire... *fin*

(4 -> (mais c'est du "bon sens") a la fin de l'application, on lache/libere le mutex bien entendu)

2bis -> Ton application cherche a ce connecter a l'IPC "nomapplication_monipc"
3bis -> si la connection n'echoue pas (et dans ce cas, gueuler sur l'utilisateur hein ^^) tu envoie un message via l'IPC pour indiquer à l'instance principale de l'application qu'elle a quelques chose a faire (ouverture de fichiers entre autres)

Je déconseille la recherche de fenetre et postages de messages car, ce n'est pas super secure (pas forcement qq'un qui veux se faire passer pour ton appli, juste que tu peut avoir des recherches "fausses") et que si a un moment ou un autre la fenetre qui est recherché n'est pas (encore) présente, ça foire...

Et pour la culture, un mutex, c'est une forme de drapeau que seul un processus a la fois peut prendre. Et tout ceux qui font la demande pour le prendre se retrouve sur une file d'attente et sont en pause jusqu'a obtention de celui-ci (ceci est bien sur le comportement par défaut, on peut bien sur mettre des timeouts sur l'attente d'un MUTEX) mutex signifiant Mutual Exclusion. Cela permet par ex de proteger l'accés a un périphérique ou un seul accés concourant peut etre effecté, genre imprimante, tu lance l'impression, tu tente l'acquisition du mutex, des que tu le prend tu envois les infos sur l'imprimante, et quand tu as fini, tu relache le mutex pour permettre aux autres de faire leur boulot.

Heu il doit y avoir qqc de prevu dans windows, sans avoir recourt aux semaphores.
Je vois mal chaque Appli redéfinir tout cela. Il doit falloir chercher dans les APIs

Et non windows ne propose rien de tel, et c'est "normal". En C#/VB.net il on un "setting" pour faire ça, mais ça reviens a ce dont je parle plus haut


Ha oui aussi j'oubliais pour le pbm du parcours de fenetres, la limite de taille d'un message pour les WM_USER risque de poser pas mal de soucis avec les LFN... alors que les IPC tel messagebox ou pipe n'ont pas ce genre de limites, et evitent d"utiliser de la mémoire partagé ou un des "seul" moyen simple de lire/ecrire dessus de maniere fiable demande d'utiliser des mutex & co, et n'est pas evenementiel contrairement au PIPE/MessagesBox & co