Discussion :

[abcdefg]

Bonjour, je souhaite lancer mon programme wxwidgets a partir d'un premier programme.
Comment faire pour l'appelé et l'initialise correctement ? merci.

[3DArchi]

Bonjour,
Ton premier programme est aussi une application wxWidgets ? A ce moment, je te conseille de t'intéresser à ::wxExecute et wxProcess.

[abcdefg]

Bonjour 3DArchi,

c'est pas un .exe que je cherche a lancer, c'est une wxApp.
Le problème c'est que j'ai déjà une wxApp !

J'utilise des méthodes de la RTTI wxWidgets dans mon programme qui doit être lancer. Quand je le lance seul tout fonctionne, mais j'ai une contrainte; le programme doit être lancé avec un programme fédérateur, du coup je me retrouve avec deux wxApp ! conflit !

Merci.

[3DArchi]

Bizarre. Je ne suis pas sûr que l'on puisse avoir plusieurs wxApp dans un même programme. Quel est l'objectif : récupérer l'existant pour construire une appli avec plusieurs existantes ? Faire du multi threading ?

[abcdefg]

C'est un service fait en wxWidgets donc avec une wxApp qui tourne en attente de commande. Quand une commande est reçu le service va charger mon deuxième programme (donc wxApp).


Admettons que je n'utilise plus les wxWidgets pour le code du service (lanceur) Comment faire pour initialisé/instancié une wxApp dans du code c++?

[3DArchi]

C'est un service fait en wxWidgets donc avec une wxApp qui tourne en attente de commande. Quand une commande est reçu le service va charger mon deuxième programme (donc wxApp).


Admettons que je n'utilise plus les wxWidgets pour le code du service (lanceur) Comment faire pour initialisé/instancié une wxApp dans du code c++?

Je ne suis pas sûr que le problème vienne de wxApp. Cela doit plutôt être lié à l'unicité de la boucle de message dans un thread. Ensuite, je ne sais pas s'il est possible de déclencher une boucle de message dans un service (au sens windows, c'est ça). Pourquoi tes wxApp ne sont pas des applications séparées ?

Sinon, je pense qu'il faudrait alors légèrement changer ton architecture pour faire avec wxApp un pont vers l'application courante (ou une chaîne avec plusieurs application). L'idée est que tu créés une interface abstraite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
class IAppliImpl :public wxEvtHandler
{
public:
   virtual ~MonAppli()=0;
   virtual bool OnInit()=0;
//...
};
wxDECLARE_SCOPED_PTR(IAppliImpl, IAppliImplSmartPtr);
// ne pas oublier le wxDEFINE_SCOPED_PTR dans le .cpp

Tu maintiens une seule wxApp :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
class MonAppli : public wxApp
{
public:
//...
    virtual bool OnInit();
 
private :
   IAppliImplSmartPtr mp_app_courante;
};
 
// dans le cpp
bool MonAppli::OnInit()
{
   mp_app_courante.reset(CreerApplication());
      // CreerApplication est une méthode qui implémente
      // une classe concrète dérivée de IAppliImpl.
   mp_app_courante->OnInit();
   SetNextHandler(mp_app_courante);
}

Idem pour toute les fonctions de wxApp que tu souhaites prendre en charge.

Ensuite chacune de tes wxApp actuelles, tu les changes en :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class Appli1 : public IAppliImpl 
{
   virtual ~MonAppli();
   virtual bool OnInit();
// ...
};
 
class Appli2 : public IAppliImpl 
{
   virtual ~MonAppli();
   virtual bool OnInit();
// ...
};
// etc...

Quand tu souhaites changer d'application, tu n'as plus qu'à remplacer mp_app_courante dans MonAppli.
Si tu souhaites avoir plusieurs application en même temps, alors au lieu d'utiliser un pointeur dans MonAppli, tu utilises une liste (ou un tableau)...

L'idée général qui me vient est celle là. A toi de voir si cela peut s'adapter à ton besoin. Ma question première étant toujours : pourquoi ne pas avoir des processus séparé ?

[abcdefg]

Salut 3DArchi.

Je ne suis pas sûr que le problème vienne de wxApp. Cela doit plutôt être lié à l'unicité de la boucle de message dans un thread

La boucle de message et crée quand on hérite de wxFrame ? Mes deux applications héritent de wxFrame, si je fais hériter la deuxième application uniquement de wxEvtHandler en passant le this
De la première application, ça pourrai résoudre mon problème ?

pourquoi ne pas avoir des processus séparé ?

Tu ve dire quoi par "separé" ? avec des threads ? si le problème viens de la pile de message ça ne résoud pas mon probleme.

[3DArchi]

Salut 3DArchi.

La boucle de message et crée quand on hérite de wxFrame ? Mes deux applications héritent de wxFrame, si je fais hériter la deuxième application uniquement de wxEvtHandler en passant le this
De la première application, ça pourrai résoudre mon problème ?

La boucle de message est dans wxApp. Les wxFrame sont 'branchés' pour recevoir les messages. Mais tu peux effectivement maintenir plusieurs wxFrame de niveau top dans ton appli et les créer/détruire comme tu veux.

Tu ve dire quoi par "separé" ? avec des threads ? si le problème viens de la pile de message ça ne résoud pas mon probleme.

Processus : comme à la base tu étais parti sur plusieurs application (wxApp), pourquoi ne pas avoir plusieurs applications, i.e. plusieurs exécutables ?

[abcdefg]

La boucle de message est dans wxApp. Les wxFrame sont 'branchés' pour recevoir les messages. Mais tu peux effectivement maintenir plusieurs wxFrame de niveau top dans ton appli et les créer/détruire comme tu veux.

Comment tu explique que si je ne crée pas de wxFrame dans mon OnInit() et que je lance un thread qui envoie un wxEvent vers wxApp en utilisant le passage du this ( wxApp --> wxThread ) je n'obtiens pas de résultat.

Alors que si je crée une wxFrame avant de lancer mon thread, je récupere bien l'wxEvent que je lance?

[3DArchi]

Comment tu poste ton évènement ?

[3DArchi]

Effectivement. Sous windows, le 'réveil' de l'application passe par l'envoi d'un message 'vide' vers la fenêtre top most. En l'absence, la boucle de message reste bloquée sur ... l'attente d'un message (au sens windows) !
En fait, ton évènement (wxEvent) est bien mis dans la file des évènements à traiter, mais l'application principale (wxApp::Run) ne sort pas de l'appel bloquant ::GetMessage (win32).
Dans ce cas très particulier, il faudrait probablement passer par un autre mécanisme : mutex&condition.

[abcdefg]

Ok merci pour cette reponse je comprends mieux,
par contre quand je deplace mon ex sur une autre machine mon programme genere une erreur a l'execution:

cette application n'a pas pu démarrer car la configuration de l'application est incorrect

J'ai pourtant mit toute les dlls des wxWidgets.
Vous avez une idée ? Merci.

[3DArchi]

Ok merci pour cette reponse je comprends mieux,
par contre quand je deplace mon ex sur une autre machine mon programme genere une erreur a l'execution:



J'ai pourtant mit toute les dlls des wxWidgets.
Vous avez une idée ? Merci.

Ici ? (ou ici)
ou la source...

[3DArchi]

Ok merci pour cette reponse je comprends mieux

Une autre solution est de construire une fenêtre mais de la garder cachée.

[abcdefg]

Une autre solution est de construire une fenêtre mais de la garder cachée.

Oui c'est pas propre mais c'est ce que j'ai fais.

[jfouche]

Salut
Télécharge dependency walker, et ouvre ton exe, tu verras ce qui ne vas pas.
--
Jérémie

[abcdefg]

La boucle de message est dans wxApp. Les wxFrame sont 'branchés' pour recevoir les messages.

Salut 3DArchi, je suis toujours avec la boucle de message, serai tu me dire par quel moyen la file de message des wxFrame est 'brancher' a celle du wxApp ?

Il y a t'il un moyen de crée une wxFrame n'importe où dans mon programme puis (dans un second temps) de brancher sa file de message avec la file principale ?

Si ma wxFrame n'est pas 'branché' a la file principale a t'elle sa propre file ?
Pour que ma petit classe utilise sa propre file de message un héritage de wxEvtHandler suffit' il ??
Merci.

[3DArchi]

Salut,
Je vais passer par le mode de fonctionnement Windows, mais j'imagine que côté MAC ou linux, cela doit suivre le même principe. In-fine le mécanisme devrait te permettre aussi de comprendre le fonctionnement de wxWidgets qui suit de toute façon le même principe.

Les files de messages
Sous windows, tu as des files (FIFO) de messages. Il existe deux types de files de messages : une unique file système et une file pour chaque thread utilisant l'I.H.M. En général, une application (et avec wxWidgets c'est fortement recommandé) n'a qu'un seul thread I.H.M. avec sa file de message : le thread principal.

Les messages
Les messages peuvent être générés par le système : l'appui d'une touche du clavier, les évènements de la souris, le déplacement des fenêtres, etc. Toutes ces actions génèrent un message qui est enfilé dans la file système. Le système possède sa propre boucle : elle sort le message, en détermine le destinataire et l'enfile dans la file des messages du thread ayant créé le destinataire. Nous verrons plus loin ce que fait le thread d'une application avec ce message. Et nous verrons aussi comment un programme envoi un message et comment ça marche dans ce cas.

Les boîtes aux lettres
Qui sont les destinataires des messages : les fenêtres jouent le rôle de boîte aux lettres. Par fenêtre il ne faut pas forcément comprendre quelque chose de visible sur l'écran (une frame, un bouton, un widget...) mais l'association d'un handler (HWND) et d'une procédure. Lorsque tu créés une fenêtre (au sens I.H.M.), un bouton ou un wxEvtHandler, wxWidgets créé un HWND et l'associe à une procédure spécifique au type d'objet que tu créés.

La boucle de message
Celle-ci doit être le cœur du thread principal. En résumant grossièrement, la boucle de message ressemble à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
tant que sans_fin
   Regarder s'il y a un message dans la file des messages
   S'il n'y a pas de message : gestion du Idle
   Sinon
      Extraire le message le plus vieux (file FIFIO)
      Eventuellement filtrer le message par l'application (wxApp::FilterEvent)
      Dispatcher le message vers son destinataire
   Fin si
Fin tant que

La boucle se termine en gérant spécialement le message WM_QUIT.
Dispatcher le message est fait par une fonction windows : DispatchMessage qui va invoquer la procédure associée au HWND destinataire du message.

Envoyer un message à une boîte aux lettres.
L'envoi d'un message nécessite de connaître le destinataire. Cela veut dire que tu dois avoir un objet de type wxEventHandler ou dérivant de wxEventHandler. Il existe deux mécanisme pour envoyer un message à un destinataire :
-> SendMessage (wxEvtHandler:: ProcessEvent) : le message n'est pas enfilé dans la FIFO, mais Windows appelle directement la procédure associée au HWND. En simplifiant, SendMessage ressemble à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Récupérer la procédure associée au HWND destinataire du message.
Appeler cette procédure avec le message.
Retourner la valeur retour.

Donc, si tu as une fonction qui appelle ProcessEvent, lorsque ProcessEvent retourne le message a été traité !
-> PostMessage (wxEvtHandler::AddPendingEvent) : le message est enfilé dans la FIFO du thread possédant le HWND destinataire. Le message sera traité dans la boucle des messages. Lors du retour de wxEvtHandler::AddPendingEvent, le message n'a pas été traité.

La procédure de traitement des messages d'une boîtes aux lettres
Lorsqu'un message arrive à cette procédure, wxWidgets gère les messages comme suit (cf description dans la doc wxWidgets) :

1. Pour les wxWindow, on commence par appeler les wxValidator associés. Si l'un deux traite le message, alors stop.
2. On cherche dans les tables d'évènements du wxEventHandler. Les entrées de cette table sont remplies soit dynamiquement par wxEvtHandler::Connect, soit statiquement par les entrées entre BEGIN_EVENT_TABLE et END_EVENT_TABLE. Si une entrée est trouvée et qu'elle traite le message : stop.
3. Le message est transmis à la chaîne des gestionnaires de messages associés. Ces gestionnaires se gèrent avec wxWindow:: PushEventHandler / wxWindow:: PopEventHandler. Si un des éléments de la chaîne traite l'évènement, alors stop.
4. Si la boîte aux lettres est une wxWindow et que le message est 'propageable' alors essayer la procédure du parent de la fenêtre. L'appel récursif des parents s'arrête pour les top frames (pas de parents) et les boîtes de dialogue (leur parent n'est pas sollicité).
5. Si l'évènement n'a toujours pas été traité, alors essayer avec wxApp (différent du filtrage !). L'application peut demander à gérer des évènements car elle a elle aussi une table d'évènements : on peut donc connecter (wxEvtHandler::Connect) ou ajouter des évènements à sa table (BEGIN_EVENT_TABLE / END_EVENT_TABLE).
A noter qu'à chaque étape, un gestionnaire peut traiter l'évènement et faire comme s'il ne l'avait pas traiter en utilisant wxEvent::Skip(true).

Donc, pour répondre à tes questions :

saurais tu me dire par quel moyen la file de message des wxFrame est 'brancher' a celle du wxApp ?

cetotomatix : la création d'une wxFrame créé la paire HWND/procédure qui sera ensuite appelée quand il le faut par la boucle de message.

Il y a t'il un moyen de crée une wxFrame n'importe où dans mon programme puis (dans un second temps) de brancher sa file de message avec la file principale ?

Oui et non. Dès sa création la frame est 'branchée' dans la boucle. Cependant, tu peux la désactiver en 1/La cachant (wxWindow::Show) 2/En ne la disablant (wxWindow::Enable) ou carrément au niveau du traitement de la boucle (wxEvtHandler::SetEvtHandlerEnabled).

Pour que ma petit classe utilise sa propre file de message un héritage de wxEvtHandler suffit' il ??

L'héritage wxEvtHandler suffit à créer un objet 'boîte aux lettres'. Tu rajoutes ensuite les évènements que tu veux gérer soit par wxEvtHandler::Connect soit entre BEGIN_EVENT_TABLE/END_EVENT_TABLE.

L'important et que tu n'as pas demandé est que l'envoi d'un message nécessite (je re-souligne !) que tu connaisse le wxEvtHandler destination.

[EDIT] : sur les messages et les files : MSDN

[abcdefg]

Bonjour 3DArchi, merci pour toute ces explications, ça ma aidé a y voir plus clair. Par contre en wxWidgets quand on veux faire du mode console tout ces mécaniste ne sont pas implémenté ? Merci encore.

[abcdefg]

Bonjour, j'ai une question a propos de l'exécution d'un programme, je poste là puisque le sujet et quasiment pareil.

Quand je lance mon .exe (wxWidgets) le message suivant s'affiche a l'execution:

« cette application n'a pas pu démarrer car la configuration de l'application est incorrecte »

J’ai installé vcredist_x86.exe qui devrait mettre a jours les librairies d'environnement, mais cet exécutable y fait rien. Par contre quand j'installe vc2005 mon programme s'exécute

1) Qu''est ce que vc2005 installe de si particulier pour que ça fonctionne ?
2) Comment je pourrai isoler les fichiers qui me permettrons d'exécuter mon programme sans installer vc2005 sur la machine client !!!!!

Merci d’avance.