Discussion :

[yan]

utilise qmake :

Code :

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

qmake -tp vc

va te generer ton vcjproj à ouvrire avec visual. ET ca marche sans problème

[troumf]

la commande qmake est inconnue dans le command prompt de VS...est-ce que QtBuilder aurait du l'inclure ?

j'ai finalement réussi a compiler lier le programme ogre_qt mais j'attends d'avoir eclairci certains point pour en faire part à la communauté

[yan]

Ps: ne pas oublier de rajouter dans le PATH système le repertoire bin de Qt

[troumf]

hum j'ai pensé que cela signifiait d'ajouter le bin dans tools->options-> projects and solutions->VCDirectories

j'ai pas bon ? qu'est-ce que le PATH systeme ?

[yan]

hum j'ai pensé que cela signifiait d'ajouter le bin dans tools->options-> projects and solutions->VCDirectories

j'ai pas bon ? qu'est-ce que le PATH systeme ?

la variable d'environnement nomé PATH

1- appuye sur les touches windows+pause
2- va dans avancé
3- variable d'environnement
4- modifier la variable PATH en ajoutant le répertoire bin de Qt. Tous les répertoire sons séparé par un ;

[troumf]

Mais où il m'emmène ?

hum excuse mon ignorance, j'avais jamais été amené à me balader dans les variables d'environnement. Merci pour cette découverte, mieux vaut tard que jamais.

[yan]

Mais où il m'emmène ?

hum excuse mon ignorance, j'avais jamais été amené à me balader dans les variables d'environnement. Merci pour cette découverte, mieux vaut tard que jamais.

ca marche maintenant?

[troumf]

oui oui j'arrive a lancer un qmake -tp vc.

je verrai pour le reste demain, après cette journée éprouvante.
merci pour tout vraiment, sans toi je serais encore à installer Qt (ou presque)

bonne nuit

[troumf]

Tout marche (presque) parfaitement à présent :

effectivement, après avoir compilé Qt avec QtBuilder et ajouté "C:\Qt\4.4.0\bin" à la variable d'environnement PATH,

un "qmake -tp vc", avec le command prompt de Visual studio dans le dossier où sont placés le .pro, les headers (dans le tuto : ogrewidget.h) et les sources (main.cpp et ogrewidget.cpp), crée un .vcproj, mais fait même mieux : il ajoute au projet les fichiers qui seront générés lors du build par le meta-object compiler "moc", qui existent car on utilise la macro Q_OBJECT dans la définition d'une classe (nécessaire quand on utilise des signals ou des slots).
(certains moins ignorants que moi trouveront sûrement ça normal)

petite chose : dans les input du linker, toujours dans les project properties, sont ajoutés, en mode debug, les fichiers c:\Qt\4.4.0\lib\QtGuid4.lib et c:\Qt\4.4.0\lib\QtCored4.lib (en release, les mêmes sans le 'd' avant le 4). Ces fichiers (se terminant par "d4") n'ont pas été généré par QtBuilder sur mon pc et donc n'existe pas. Peut-être est-ce dû à des cases non cochés dans les configurations de QBuilder. Je ne peux donc pas générer en Debug mode (enfin si, en enlevant les 'd' dans les noms de fichiers mais bon... ).

du coup, "ya plus qu'à" (petite blague autodérisoire) lancer le Build en release mode et la compilation liaison se passe bien.

pour l'exécution, ne pas oublier d'ajouter le fichier Plugins.cfg (pour ogre) dans le dossier de l'executable. personnellement, j'ai mis tous les dll Ogre (release) et tous les dll de Qt dans le dossier release et je l'ai mis en working directory dans les project properties->debugging.

reste une toute petite chose : lorsque je ferme l'appli (qui marche bien, ce qui n'est pas négligeable, c'est quand meme l'aboutissement du tuto), ya une ch'tite violation d'acces qui provoque un message d'erreur, du genre de ceux qu'on voit quand il y a des pointeurs morts...

maintenant que ça marche à peu près, je vais essayer d'embarquer MON appli Ogre...

[IrmatDen]

reste une toute petite chose : lorsque je ferme l'appli (qui marche bien, ce qui n'est pas négligeable, c'est quand meme l'aboutissement du tuto), ya une ch'tite violation d'acces qui provoque un message d'erreur, du genre de ceux qu'on voit quand il y a des pointeurs morts...

Intéressant :s
C'est avec le code du tuto sans retouche ou avec retouche(s) ?

Edit: je demande parce que je ne l'ai pas et je suis avec une config proche de la tienne (VC++2005 Express, Qt 4.3.0 et 4.3.1 et le SDK Ogre 1.4.5 et 1.4.8)

[troumf]

hmm sans retouche de ma part en tout cas sur les fichiers sources et le header, simplement le .pro:

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
TEMPLATE = app
CONFIG += console
TARGET = qt_ogre
DEPENDPATH += .
INCLUDEPATH += . C:\OgreSDK\include C:\OgreSDK\samples\include
 
win32:LIBS += -LC:\OgreSDK\lib
 
CONFIG(debug, debug|release) {
	LIBS +=  -lOgreGUIRenderer_d -lOgreMain_d -lCEGUIBase_d -lOIS_d -lode
}
CONFIG(release, debug|release) {
	LIBS +=  -lOgreGUIRenderer -lOgreMain -lCEGUIBase -lOIS -lode
}
 
# Input
HEADERS += ogrewidget.h
 
SOURCES += main.cpp \
		   ogrewidget.cpp

et le fichier plugins.cfg (relatif au release mode), puisque j'ai placé celui de ogre par défaut :

Code :

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

1
2
3
4
5
6
7
8
9
10
# Define plugin folder
PluginFolder=.
 
# Define plugins
Plugin=RenderSystem_Direct3D9
Plugin=RenderSystem_GL
Plugin=Plugin_ParticleFX
Plugin=Plugin_BSPSceneManager
Plugin=Plugin_OctreeSceneManager
Plugin=Plugin_CgProgramManager

lorsque je debug, la ligne qui pose probleme est la suivante, située dans le fichier crt0dat.c, fonction void __cdecl __crtExitProcess (int status) :

Code :

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

ExitProcess(status);

[IrmatDen]

lorsque je debug, la ligne qui pose probleme est la suivante, située dans le fichier crt0dat.c, fonction void __cdecl __crtExitProcess (int status) :

Code :

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

ExitProcess(status);

Là, c'est un peu trop bas niveau pour être intéressant

Ca doit être dans le destructeur que ça coince, je vois pas autre chose. Tu peux exécuter OgreWidget::~OgreWidget en pas à pas et me dire sur quelle ligne il crash stp ?

Edit: et tente en laissant uniquement le "delete ogreRoot;" aussi, ça ne crashera plus. Mais c'est vraiment étrange

[troumf]

Sir yes sir : tout se passe a merveille, même le delete ogreRoot... c'est après

[yan]

petite chose : dans les input du linker, toujours dans les project properties, sont ajoutés, en mode debug, les fichiers c:\Qt\4.4.0\lib\QtGuid4.lib et c:\Qt\4.4.0\lib\QtCored4.lib (en release, les mêmes sans le 'd' avant le 4). Ces fichiers (se terminant par "d4") n'ont pas été généré par QtBuilder sur mon pc et donc n'existe pas. Peut-être est-ce dû à des cases non cochés dans les configurations de QBuilder. Je ne peux donc pas générer en Debug mode (enfin si, en enlevant les 'd' dans les noms de fichiers mais bon... ).

1- c'est normal, Qtbuilder ne compile pas les deux en même temps. Il faut compiler une fois en release et une fois en debug.
2-il est déconseillé d'utiliser les version release en mode debug. Problème de crt ou je ne sais plus quoi.

[IrmatDen]

Sir yes sir : tout se passe a merveille, même le delete ogreRoot... c'est après

Voilà qui est original, je vais en perdre mon latin...

Question bête: aurais-tu des dlls Qt préparées avec VC++ et celle préparée avec MinGW dans le PATH (utilisateur et système, les 2 comptent) ?

[troumf]

voilà qui pourrait être un début d'explication.
peût-etre que l'erreur quand je debug n'est pas celle que j'ai quand j'exécute sans debugger.
pour en avoir le coeur net je vais compiler Qt en debug mode...

[yan]

Salut,
renome le repertoire des dll de mingw pour tester, au moins tu sera sur

[troumf]

Question bête: aurais-tu des dlls Qt préparées avec VC++ et celle préparée avec MinGW dans le PATH (utilisateur et système, les 2 comptent) ?

effectivement, dans Qt\bin que j'ai ajouté au PATH utilisateur (je suis seul à utiliser ce pc, ai-je eu tort?), il y a des dll (préparés par je ne sais qui).
les dll que j'ai placé dans le dossier release du projet proviennent de Qt\lib, qui sont a priori preparé par VS.

serait-ce donc ça ?

[IrmatDen]

Il ne faut en effet pas mélanger les 2 versions, tu ne sauras pas lesquelles sont utilisées (c'est arbitraire).
Mais vu que les dlls VS sont dans le même dossier, ce devrait être bon, j'ai un trou de mémoire sur l'ordre utilisé

[troumf]

j'ai déplacé tous les dll contenus dans Qt\bin ailleurs (a priori je suppose que ce sont ceux de MinGW). de cette façon, les seuls dll rentrant en compte sont ceux provenant de Qt\lib, supposés préparés par VS (enfin là c'est probable quand meme), que j'ai copiées dans release.

le message d'erreur n'a pas changé d'un poil.