Page 7 sur 18Précédent 1 ... 4, 5, 6, 7, 8, 9, 10 ... 18 SuivantDémarrage variable| Nouveau Start.exe

[dedenimes]

Ca semble parfait, et très puissat. Décidément, je tiens de plus à cet ensemble start.exe + AeTray qu'à d'autres solutions de lanceurs, même si plus simples à personnaliser.
Les versions futures semblent vraiment top, je les attends avec hâte. J'ai d'ailleurs acheté une clé dédiée pour les tests de lanceurs et de programmes gravitant autour (du genre de cafe), donc si vous avez besoin d'un beta-testeur, n'hésitez pas.
Amicalement

[Tuxmouraille]

dit moi Tuxmouraille, ton start.exe, est ce que tu la fini?

Avec un peu de retard, non je ne l'ai pas finit. Toutes tes propositions sont les bien venues.

N'y a-t-il pas moyen d'envoyer un message WM_CLOSE avec SendMessage() à la fenêtre que vous souhaitez fermer dans votre script NSIS ? Je ne connais pas du tout le language de script de l'installeur de nullsoft mais comme il y a moyen d'utiliser les API natives. Un mix avec FindWindow() devrait faire l'affaire.

Et puis WM_CLOSE est moins goret que de tuer violement la pauvre appli au travers de son processus.

J'ai trouver comment envoyer ces messages. Pourrais tu m'en dire plus? Par exemple comment faire pour trouver la fenêtre destinataire?

[Tuxmouraille]

Petite explication de start.ini:

ExecuteProg1= indiquez ici le nom de l'exécutable à lancer

LaunchIt1= indiquez ici si vous voulez le lancer, true pour le lancer (avec ou sans demande voir plus bas), false pour ne pas le lancer. Cette partie permet de ne plus lancer une application sans avoir réécrire le fichier. Pas encore disponible.

ExecuteProgToStop1= si vous choisissez d'utiliser la fonction de fermeture de Start.exe, c'est à dire qu'il va fermer toutes les applications qu'il a lancer au début. Ceci en appelant Start.exe avec la commande -close. Vous indiquez ici le nom de l'exécutable à terminer.Cet exécutable n'est pas forcement le même que le premier. Par exemple si vous lancez le Kiosk ExecuteProg est FramaKiosk.exe qui est le lanceur du Kiosk (comme PortableFirefox est celui de firefox), mais une fois le kiosk lancer l'exécutable qui affiche le kiosk est k-meleon.exe, c'est donc lui qu'il va falloir terminer.

WorkDir1= le chemin, relativement a Start.exe du dossier contenant ExecuteProg

Parameter1= un paramètre à passer à ExecuteProg

AskForIt1= demande à l'utilisateur si il souhaite lancer l'application ou pas. True pour demander, false pour ne pas demander. Si c'est false l'application sera lancée sans demander.

MessageToShow1= si vous souhaiter personnaliser le message précédent, écrivez le ici. Si non ce sera la message par défaut: "Voulez vous lancer %ici la valeur du champ ExecuteProg%?

Les fonctions actuelles:
- affichage d'une icône de notification dans la barre de tache avec un message ballon (merci de me corrigé, je ne connais pas le terme français)
- lancement simultané de plus de 5 applications
- possibilité de lancer les applications avec une commande
- possibilité de ne pas lancer toutes les applications, et utilisant une boite de dialogue qui demande si on veux lancer l'application, et possibilité de personnaliser le message.
- possibilité de tuer un processus à l'aide de la commande closeprocess
- possibilité de tuer toutes les applications lancées par Start, en le lassant avec le paramètre -close.

Les prochaines:
- ajout de la fonction pour ne plus lancer une application LaunchIt, sans avoir à réécrire le fichier de configuration.
- gestion des chemins absolus
- installation de paquet par glisser-déposer du paquet sur Start.exe. Utile pour les mise à jour.
- possibilité d'avoir plusieurs fichiers de configuration, un principal start.ini utiliser en double cliquant sur Start.exe et des secondaires utilisables par glisser déposé sur Start.exe.

Si j'arrive à porter le code sur AutoHotKey ou un autre plus pratique pour les boites de dialogue:
- interface d'administration des profils par raccourcis clavier + double clic sur Start.exe. Pour répondre à la demande de enigmatiqk.
- interface d'ajout-suppression de paquet.

[Téthis]

N'y a-t-il pas moyen d'envoyer un message WM_CLOSE avec SendMessage() à la fenêtre que vous souhaitez fermer dans votre script NSIS ? Je ne connais pas du tout le language de script de l'installeur de nullsoft mais comme il y a moyen d'utiliser les API natives. Un mix avec FindWindow() devrait faire l'affaire.

Et puis WM_CLOSE est moins goret que de tuer violement la pauvre appli au travers de son processus.

J'ai trouver comment envoyer ces messages. Pourrais tu m'en dire plus? Par exemple comment faire pour trouver la fenêtre destinataire?

J'ai utilisé ce code pour implémenter ça dans lua :

Code: Tout sélectionner

int
lua_FindWindow (lua_State *L)
{
   HWND hwnd;
   DWORD dwProcessID = 0;

   const char* lpClassName = NULL;
    const char* lpWindowName = NULL;

   if (lua_isstring (L, 1))
      lpClassName = luaL_checkstring (L, 1);

   if (lua_isstring (L, 2))
      lpWindowName = luaL_checkstring (L, 2);

   hwnd = FindWindow (lpClassName, lpWindowName);
   if (hwnd == NULL)
   {
      lua_pushnil (L);
      lua_pushnil (L);
      return 2;
   }

   GetWindowThreadProcessId (hwnd, &dwProcessID);

   lua_pushinteger (L, (DWORD) hwnd);
   lua_pushinteger (L, (DWORD) dwProcessID);
   return 2;
}


Tout ce qui lua_* est relatif au "moteur" lua, cela sert à récupérer dans la stack les variables passées ("valeurs" de lpClassName et lpWindowName) et à passer les résultats au travers de la pile (nil, nil ou le handle de la fenêtre et l'ID processus).

Ce qui est important est de voir que l'on peut récupérer un handle sur une fenêtre (soit à partir du nom de sa classe ou de la fenêtre) et récuperer à partir de celui-ci l'ID du processus qui possède la fenêtre. Respectivement avec FindWindow et GetWindowThreadProcessId.

On peut ensuite envoyer un message WM_CLOSE à la fenêtre avec SendMessage (hwnd, WM_CLOSE, 0, 0);.

Le nom de classe de fenêtre est récupérable avec des outils spécialisés comme winspector (j'utilise mon debugger :p).

J'ai vu qu'il y avait un plugin (system.dll) pour nsis permettant d'utiliser les api natives.

[Tuxmouraille]

@enigmatiqk: j'ai eu cette erreur, sur un compte invité:

Code: Tout sélectionner

Script : E:\bin\removedrive\script.vbs
Ligne : 2
Caract: 1
Erreur: Permission refusée: 'GetObject'
Code : 800A0046
Source : Erreur d'execution Microsoft VBSript

[enigmatiqk]

merci pour voos retour, de mon coté, je viens de remarqué une grosse eerreur sur ma derniere version, j'ai voulu faire un truc propre sans prendre la peine de le testé ... snif ...
voici ce que l'on ma ramené:

je comprend pas du tout ... je vais me renseigner ...

Code: Tout sélectionner

un windows xp pro avec droits restreint (pc du boulot) mais où on est quand même un peu admin.

script.vbs
ligne 9
caract 5
erreur non trouvé
code:80041002
source swbemobjectex

Ca c'est déjà beaucoup plus grave ... une permission refusée ... pour vous dire ... getobjet me permet d'avoir access aux processus -_-, alors la je suis perdu ... peut être changer de langage ... snif

Code: Tout sélectionner

un compte invité:

Script : E:\bin\removedrive\script.vbs
Ligne : 2
Caract: 1
Erreur: Permission refusée: 'GetObject'
Code : 800A0046
Source : Erreur d'execution Microsoft VBSript

ps: moi aussi j'atend une version final du start.Exe ^^ (et j'aime bien le coup du .ini en parametre ^^)

[EDIT]
la premiere erreur à l'air de venir d'un truc plutot important, d'apres le peu que j'ai trouvé et l'anglais que j'ai lu (houla), tout betement, un .vbs est en quelque sorte compilé/executé sur la machine ... hors j'ai l'impression que ta machine n'avais pas de disponible, l'objet que j'utilise ...

je pense vraiment que je vais changer de langage ... je penche sur le c++ car aucun prerequis (vb => librairie vb, .net => framework), si d'autres personnes ont des idées ...

[Tuxmouraille]

Et compiler les scripts?

[Tuxmouraille]

Tout ce qui lua_* est relatif au "moteur" lua, cela sert à récupérer dans la stack les variables passées ("valeurs" de lpClassName et lpWindowName) et à passer les résultats au travers de la pile (nil, nil ou le handle de la fenêtre et l'ID processus).

Ce qui est important est de voir que l'on peut récupérer un handle sur une fenêtre (soit à partir du nom de sa classe ou de la fenêtre) et récuperer à partir de celui-ci l'ID du processus qui possède la fenêtre. Respectivement avec FindWindow et GetWindowThreadProcessId.

On peut ensuite envoyer un message WM_CLOSE à la fenêtre avec SendMessage (hwnd, WM_CLOSE, 0, 0);.

Le nom de classe de fenêtre est récupérable avec des outils spécialisés comme winspector (j'utilise mon debugger :p).

J'ai vu qu'il y avait un plugin (system.dll) pour nsis permettant d'utiliser les api natives.

J'ai pas tout pigé. C'est un peu du chinois pour moi, je suis autodidacte en programmation.
Pour le plugin system, je le connais et l'utilise (pompage du code de Haller) mais ne comprend pas son fonctionnement.
Il existe déjà dans NSIS la commande FindWindows et SendMessage mais pas GetWindowThreadProcessId.

[enigmatiqk]

Et compiler les scripts?

c'est possible, mais pas gratuitement ... donc je pense pas que ca rentrerais ... et puis l'utilité de faire ca en vbs, c'était d'avoir le code directemenet et de le changer a la volée

[Téthis]

Ok, tant mieux qu'il y ait déjà des appels aux API.

Pour GetWindowThreadProcessId, voila la définition

[/code]
DWORD GetWindowThreadProcessId(
HWND hWnd,
LPDWORD lpdwProcessId
);[/code]

si lpdwProcessId = 0 (NULL car il s'agit en fait d'un pointeur) alors l'API retourne le PID. Pour l'utiliser, il faudrait définir l'appel à l'API tel que c'est fait dans l'exemple system.nsi et ses includes (*.nsh). Cette valeur de PID est optionnelle car, en principe, l'envoi du message WM_CLOSE ferme proprement l'application. Mais ça peut être utile avant d'éjecter la clef de savoir si le processus est bien clos.

J'ai bien essayé de faire joujou avec nsis et system mais ma motivation pour étudier des utilitaires non multi-os est de plus en plus réduite. Je ne suis arrivé à faire grand chose à part une boite de dialogue qui ne m'affichait pas la valeur souhaitée.