Encore moi avec une question.

Question de faire un follow-up pour ma dernière question, je suis parvenu à faire fonctionner DirectInput, tout va bien à ce niveau.

J´ai un petit problème avec mon application. De temps à autre ( je n´arrive pas à isoler une raison exacte), lorsque je la ferme ( alt + F4, c´est une application fullscreen et je n´ai encore rien programmé pour reconnaitre le keyboard), je reçois une erreur ( dans une message box avec uniquement un bouton " ok") qui dit:

Titre: Microsoft Development Environment
The following exception has occured:

InvalidOperationException: The object is currently in use elsewhere.

Il y a plusieurs conclusions que je peux tirer de cette erreur. Est-ce que quelqu´un a une idée plus précise de ce qui cause ça ( généralement parlant, supposant que plusieurs choses peuvent provoquer cette erreur) ?

Les deux hypothèses dont je dispose sont que j´essais de releaser une interface qui est en plein processus de dessin à l´écran ( ce qui m´a poussé à mettre des ->end(); dans ma procédure de cleanup et rien n´a changé) ou alors je ne fais pas mes releases au moment opportun ( ma procédure de cleanup est lancée après la réception du message WM_DESTROY -- je sais pas trop ce que je peux faire pour vérifier si le problème vient de là, j´ai essayé de lancer ma procédure avant d´unregisterer la classe de ma fenêtre plutôt que par les messages, rien n´a changé).

Une idée ?

c´est assez vague... essaye plusieurs trucs : mettre le debug output level au max dans les settings DX, ça te donnera plus d´infos sur le bug ( dans la fenetre debug output de VC++); ensuite s´il y a un n° d´erreur, tu as un outil de " error lookup" pour l´identifier. Ensuite, essaye de tracer ton code pour savoir où l´erreur se produit, ça pourrait aussi nous eclairer.
Tu peux aussi commenter tes allocations de ressources ( et créations de devices), vérifier que tout marche bien, et décommenter progressivement en gardant la parité init/cleanup, tu verras à quel moment tu rajoutes qqch qui foire.
En dernier lieu tu peux comparer ton code avec celui du wizard, mais c´est assez laborieux.

Si c´est une erreur DX, je dirai qu´il doit te manquer un release qq part : du coup l´application se termine et constate qu´un objet est toujours référéncé, et pourrait cracher ce genre d´exception.

essaye un peu tout ça pour mieux identifier le soucis, et donne nous les infos au fur et à mesure

Hmmm, merci bien pour la réponse, c´est vraiment très fastidieux de tout commenter, surtout pour un programme qui plante à la fermeture et de façon aléatoire ( des fois tout se passe sans erreur).

J´ai refais le tour du code, est-ce qu´il est possible que l´erreur vienne du fait que je release le device et le rendering device ( LPDIRECT3D9 et LPDIRECT3DDEVICE9) avant tout le reste ? Je fais faire quelques tests mais c´est vraiment difficile de juger de ce qui ne tourne pas rond.

" est-ce qu´il est possible que l´erreur vienne du fait que je release le device et le rendering device ( LPDIRECT3D9 et LPDIRECT3DDEVICE9) avant tout le reste ? "

OUI ! !

il faut releaser en ordre inverse si on veut etre propre ; ça devrait solutionner ton pb Bien vu, tu as eu la bonne intuition

Je suis un peu perplexe. J´ai changer l´ordre de mes releases et, malheureusement, le problème a persisté.

J´ai réussi à reproduire l´erreur en debugger ( wouhou ! ). L´erreur suivante a eu lieu:

Unhandled exception at 0x0048d8cc in GeoscapeSim3_1x.exe: 0xC0000005: Access violation reading location 0x00000000.

À la ligne

if( FAILED( g_pdiMouse->GetDeviceState( sizeof(DIMOUSESTATE), ( LPVOID)& ) ) )

Ce qui signifie que le message WM_DESTROY est envoyé alors que le game loop n´est pas terminé ( parce que je n´obtiens pas le devicestate de la souris comme ça en dehors du game loop).

Je dois donc déplacer mon cleanup, la question qui s´impose étant où je peux mettre ça et réussir à refaire mon test après, puisque l´erreur n´a pas toujours lieu .

J´ai placé ma fonction de cleanup à la fin complètement de mon programme, après avoir unregisteré ma class de fenêtre en me disant qu´ainsi c´était certainement la dernière chose qui serait lancé, m´assurant que le prog serait hors du game loop. Ça *semble* fonctionner.

Merci de ton aide LGV !

Je reviens sur ce que j´ai dis, le problème est toujours là .

Je vais arrêter de faire un petit rapport à chaque fois ici puisque ça devient tranquillement du spam .

Un peu comme moi je fais quoi

Koyo-K : on est drolement avancés...

Un fois le msg WM_DESTROY reçu, est-tu sûr que ton appli ne retourne plus dans la main loop ?
Au passage, essaye de modifier légèrement ta boucle de messages pour cleaner sur WM_EXIT, et sur WM_DESTROY tu fais juste un " PostQuitMessage(0);"

pour avoir plus d´infos sur le soucis, utilise les macros DXTRACE_ERR ou V ( DX 9.0c) sur tous les retour ; par exemple ta ligne douteuse devient :

HRESULT hr;
if( FAILED( hr = g_pdiMouse->GetDeviceState( sizeof(DIMOUSESTATE), ( LPVOID)& ) ) )
{
DXTRACE_ERR("mouse:GetDeviceState", hr);
}

ce qui devrait te donner des codes d´erreurs

si rien de tout ça ne te débloque, tu peux toujours m´envoyer ta source a iqxnyelw@ephemail.net ( valable 48 heures) pour que j´essaye d´y jeter un oeil.

Hmmm et bien je vois pas comment le programme pourrait retourner dans la boucle, je fais le cleanup clairement hors de celle-ci. J´ai 3 test conditionnel ( if) qui vérifie que D3D, l´input ( DirectInput), et les sprites sont initialisés avant de déclarer une variable MSG et d´entrer dans mon while de game loop. La procédure de cleanup est lancée à la sortie - en dehors - de ses quatres ´embranchements´.

Es-tu sûr pour WM_EXIT ? Parce que d´aussi loin que je puisse voir, ça n´existe pas ( ce n´est pas dans mon MSDN et ça produit une erreur à la compilation).

Pour le error tracing, je vais devoir tester ça... le problème étant que l´erreur est difficile à reproduire ( surtout avec le cleanup placé à la fin du programme, hors de WM_DESTROY... ce qui semble vouloir indiquer que le problème est lié à ça).

DirectX 9.0c ? ! Nooon, beaucoup de choses ont changé ? Je vais jeter un oeil à ça, si des trucs ont évolué de façon notable, je vais simplement envoyer mon framework à la poubelle et le refaire pour la nouvelle version ( je dis ça en considérant la summer update qui a complètement boulversé le draw de ID3DXSprite ) .

Avant de te déranger en t´envoyant mon code ( j´apprécie beaucoup le geste mais ça me semble être bouffe-temps comme solution, ce n´est pas un gros programme mais il est long à lire quand même ) , je vais refaire complètement le tour dudit code et de mon framework - particulièrement si la version 9.0c de DX change des choses importantes pour moi -. Je fais peut-être quelque chose au mauvais endroit, je n´ai pas copié intégralement les tutorials qui viennent avec MSDN ( bien que de gros morceaux soient similaires).

Entre temps, il est très tard ici donc je vais redonner des nouvelles d´ici un certain nombre d´heures .

Merci beaucoup pour ton aide !

oui, le DX 9.0c change pas mal de choses ; le framework de base ( projet vide compilant une appli qui tourne) qui vient avec a completement change et n´a plus rien a voir avec la version precedente ; de plus il y a un partie de code pour GUI en moins de 10 000 lignes : ca peut servir.
Donc ouais, tu peux essayer de porter ton code sous la nouvelle version, p-e qu´en reecrivant tu verras le soucis

pour le coup du WM_EXIT, j´ai pu me manquer, ca fait longtemps que je n´ai plus ecrit de boucle de message :/

Bon ( je suis pas couché encore ! ) voilà qui règle la question alors, je vais voir à me refaire un framework et tout... en espérant avoir produit quelque chose avant la summer update 2k5 !

Merci !

au passage, je te le dis comme je le pense, tu devrais utiliser le framework fourni avec le SDK : c´est interessant au debut de faire le sien, creer ses fenetres, devices, etc. mais si on veut faire ca bien, c´est des milliers des lignes de beaucoup d´heures de " perdues". Les frameworks font toutes les verifs d´init qu´il faut pour gerer les cas tordus auquel on ne pense pas ( genre l´appli va s´afficher en overlay sur un 2e ecran, par exemple...), l´interface proposee est assez claire, ca te permet donc d´etre operationnel en qq instants, pour te concentrer sur ta realisation, et pas sur des inits a n´en plus finir.

Quand tu dis le framework fourni avec le SDK, est-ce que tu penses à l´exemple CreateDevice ou à ce que fait le wizard ? Parce que dans le premier cas, c´est pas mal ça que j´ai, mis à part quelques modifs que je fais ici et là. Dans le second cas, le wizard semble faire énormément plus de choses que ce dont j´ai besoin, le code est un vrai bordel réparti sur plusieurs fichiers . Je suppose que le Wizard est prévu pour créer une appli efficace mais c´est pas pratique quand on s´y retrouve pas.

Heum, quand je dis " réparti sur plusieurs fichiers", j´entends qu´il me semble que la répartition du wizard rajoute au bordel, pas qu´il n´est pas normal d´utiliser plusieurs . cpp différent ( au contraire).

je savais pas qu´il y avait une runtime pour DirX 9.0c ! J´ai bien fait de lire ce post !

Ouais, ça m´a surpris aussi .

non, je parle du code du wizard... et non ce n´est pas spécialement efficace, c´est juste une vraie init complète et sure des devices, avec qq utilitaires en plus ( macros, lecture de . X, etc.). Mais si tu regardes bien, la tres grande majorité du code checke les flags des CAPS du device, teste des valeur diverses, assure que si le mode demande n´est pas dispo un autre compatible est utilisé, etc. Comme je disais plus haut,si tu fais du multi-écran, cette inite complete le gerera, si tu te contentes du tuts en 20 lignes, t´es pas du tout garanti que ça passe si bien.
au passage dans DX 9.0c il n´y a plus de wizard, il y a un " empty project" qu´il suffit de dupliquer, et c´est BCP moins le " merdier" que le code du wizard du SDK antérieur.

Erm bheh les 2 sdk sont en conflit sur mon visual studio dans ce cas, j´ai encore un wizard qui fait de la merde .

Je vais jeter un oeil à tout ça. On aurait quand même pu s´attendre à ce que toutes ces joyeuses vérifs de compatibilité se fassent plus discrètes, à tout le moins il me semble.

Raaah ? t´as installé le nouveau SDK avec l´ancien encore sur la machine ? ? . ........ t´as de fortes chances que tes versions se bouffent le nez, que les infos de debug soient plus ou moins corrompues, et tout le merdier ; selon la plupart des post MVP sur les forum DX officiels, le mieux dans ce cas pour retrouver un env de dev saint, c´est de tout reinstaller, l´os y comprit... moi je te conseille d´essayer de desinstaller les deux SDK, passer un coup de clean sur la base de reg, et reinstaller le dernier SDK

sinon pour les verif, c´est normal qu´elles ne soient pas plus encapsulées ni cachées : c´est pratique pour nous pour tester rapidement ou faire une petite appli, mais pour un vrai developpement, toute l´init sera spécifique au projet