tri listview ( debug - release )

Question

Bonjour a tous,

J'explique mon probleme :

A titre pédagogique, j'ai crée une application (sans mfc avec VC 6), ou j'ai crée des listviews.

Je rempli les listviews de données directement sans les enregistrer dans des structures, je sais ce n'est pas une bonne méthode mais cette application à pour but de m'apprendre la prog win32.

J'ai alors implémenté le tri en utilisant la macro 'ListView_SortItems'.

En mode debug cela fonctionne tres bien sur toutes les colonnes.

Passant en release, je m'apercois que mon tri n'est correct que sur la premiere colonne.

Apres avoir regarder sur le net et sur ce forum, en autre la source de Vecchio56, je me rend compte d'une chose tres importante qui est le parametre LPARAM de la structure LVITEM qui a pour but, si j'ai bien compris, de pointer sur la donnée désirée.
Ce pointeur sera ensuite utilisé dans le cadre du tri orchestré par la macro.

Mes questions sont les suivantes :

 -  On est donc obligé, si l'on désire trier la listview, de sauvegarder toutes les données ds des structures adaptées ?

 - Alors en debug le compilo se charge de créer les structures pour le tri ?

 -  Est-ce que j'ai bien compris ?

Merci pour votre aide 

+++

cosmobob · Answer

'Est-ce que j'ai bien compris ?' -> non :)
en debug le compilo ne cree pas de structures.
au moment ou tu inseres un item avec lvm_insertitem, tu remplis le champ lparam de l'item en question.
la fonction de comparaison utilisée qd tu fais un sortitem va prendre en parametres les lparam des items qu'elle est en train d'ordonner.
le lparam peut correspondre a un pointeur, un entier, ce que tu veux... c'est ta fonction de comparaison qui va l'utiliser.
si tu ne veux pas sauvegarder les donnees ds des structures, utilises lvm_sortitemsex. les lparam qui seront passés dans ta fonction de comparaison seront alors les index des items ds la liste view (et tu peux alors tout avoir en faisant des getitem...)
va voir la : msdn LVM_SORTITEMSEX

la seule chose que fait la version debug, c'est inserer les infos de debogage ds l'exe (pour pouvoir suivre son execution pas a pas)

si ca marche en debug et pas en release, c'est du a une mauvaise utilisation de la mémoire... ca ne fait pas les memes effets car en debug ya des infos de debogage un peu partout.

voila, si ca a pu t'eclairer... 
a+ ;)

cosmobob · Answer

bon le lien est mauvais;)
c'est lui le bon : msdn LVM_SORTITEMSEX

cosmobob · Answer

tiens j'ai une question.
l'exe que t'avais mis sans source, et qui a été retiré, il était de qui ? vu que tu dis que t'es en train d'apprendre comment tout ca marche, donc c'est pas toi qui l'avais fait.
t'avais chopé la source, et la tu le refais toi meme pour piger, ou ... ?

3psilon · Answer

Decidement c toi qui m'aide a chaque fois ;)

Merci pour l'info, je vais tester avec LVM_SORTITEMSEX.

Si tu veux voir la difference sur le tri des listviews , entre le debug et la release, j'ai fais la source suivante :

http://www.cppfrance.com/code.aspx?id=24766

Justement cette source fais partie de mon soft qui lui est un peu plus gros.
Et si si, ce soft est entierement de moi, je travaille dessus depuis qq temps, et en fait des que j'apprends un nouveau truc qui peut lui servir alors je l'implemente.

Mais en fait, je débute avec VC 6 depuis qq temps, et mon erreur a été de travailler au fil des versions que en mode debug, et maintenant je me retrouve avec des erreurs en release.
Bon les plus grosses erreurs sont corrigées, ben en fait il ne reste plus que le tri des listviews à corriger.

Merci encore

+++

Bye

3psilon

cosmobob · Answer

ben alors tu peux ss doute répondre a ma question!
comment on fait pr changer individuellement la couleur d'une ligne donnée d'une listview ?
jme demande
a+ ;)

3psilon · Answer

Il faut sous classer l'affichage des items de la listview.

Dans le NOTIFY, tu spécifies :

....
case IDC_LIST: 
{
LPNMLISTVIEW pnm;
pnm = (LPNMLISTVIEW)lParam;

if(((LPNMHDR)lParam)->code == NM_CUSTOMDRAW)
{
SetWindowLong(hDlg, DWL_MSGRESULT,(LONG)ProcessCustomDrawNet(lParam));
return TRUE;
}
....


Ou ProcessCustomDrawNet sera ta fonction qui affichera les items.
Dans mon exemple, suivant le texte contenu d'un des subitems la couleur du texte sera differente.



LRESULT ProcessCustomDrawNet (LPARAM lParam)
{
    LPNMLVCUSTOMDRAW lplvcd = (LPNMLVCUSTOMDRAW)lParam;
switch(lplvcd->nmcd.dwDrawStage) 
    {
        case CDDS_PREPAINT :
{						// Avant le commencement du cycle d'affichage
// Notification pour chaque item de la liste
return CDRF_NOTIFYITEMDRAW;
}
            
        case CDDS_ITEMPREPAINT:		// Avant Affichage de l'item Parametrage de la couleur du texte de l'item
{

char szTemp[96];
LVITEM LvItem;
LvItem.iSubItem = 5;
LvItem.pszText = szTemp;
LvItem.cchTextMax = 96;
 
SendMessage(hList,LVM_GETITEMTEXT, lplvcd->nmcd.dwItemSpec,(LPARAM)&LvItem); // recupère le texte

if (strcmp(szTemp,"CLOSE_WAIT")==0){
 lplvcd->clrText   = RGB(255,0,0);
 return CDRF_NOTIFYITEMDRAW;
}
if (strcmp(szTemp,"TIME_WAIT")==0){
 lplvcd->clrText   = RGB(255,0,0);
 return CDRF_NOTIFYITEMDRAW;
}
if (strcmp(szTemp,"FIN_WAIT1")==0){
 lplvcd->clrText   = RGB(255,0,0);
 return CDRF_NOTIFYITEMDRAW;
}
if (strcmp(szTemp,"FIN_WAIT2")==0){
 lplvcd->clrText   = RGB(255,0,0);
 return CDRF_NOTIFYITEMDRAW;
}
if (strcmp(szTemp,"CLOSING")==0){
 lplvcd->clrText   = RGB(255,0,0);
 return CDRF_NOTIFYITEMDRAW;
}
if (strcmp(szTemp,"ESTABLISHED")==0){
 lplvcd->clrText   = RGB(20,150,0);
 return CDRF_NOTIFYITEMDRAW;
}
if (strcmp(szTemp,"LISTENING")==0){
 lplvcd->clrText   = RGB(80,80,250);
 return CDRF_NOTIFYITEMDRAW;
}

lplvcd->clrText = coltx;

           break;
}

}
    return CDRF_DODEFAULT;

}



Dans ce bout de code, j'affiche les connexions réseaux en cours et suivant l'état de la connexion la couleur du texte variera.

+++

cosmobob · Answer

ok merci bcp bcp, jvais essayer ca !
j'ai trouvé ton msn ds le exe du premier Inxppect.exe, ca te gene si jtajoute ds mes contacts?
a+ ;)

cs_JCDjcd · Answer

En debug le compilo fait des operations en plus, comme par exemple remplir les mallocs de 0xfd, ect ...
Donc si ton programme se comporte differemment selon debug/release, il faut regarder du cote des operation sippementaires. Moi aussi ca m'ai arrivé se genre de desagrement pour les bitmaps, et il est vrai que c'est vraiment embetant, surtout quand on a l'habitude comme moi de travailler toujours en debug ....

3psilon · Answer

ok cosmobob ;)

En passant, si qq1 a un lien qui explique ce que fais concretement VC
quand il passe du debug a release cela m'interesse :) genre comme tu dis JCDjcd , remplir les malloc .. etc .. etc

Merci

cs_JCDjcd · Answer

Voila ce que j'ai trouvé vite fais dans l'aide de Visual:

****************************************************
Common Problems Switching from Debug to Release Build
Home |  How Do I

During development, you will usually build and test with a debug build of your project. If you then build your application for a release build, you may get an access violation.

The list below shows the primary differences between a debug and a release (non-debug) build. There are other differences, but the following are the primary differences that would cause an application to fail in a release build when it works in a debug build. 

Heap Layout

Compilation

Pointer Support

Optimizations 
See the /GZ (Catch Release-Build Errors in Debug Build) compiler option for information on how to catch release build errors in debug builds.

Heap Layout
Heap layout will be the cause of about ninety percent of the apparent problems when an application works in debug, but not release. 

When you build your project for debug, you are using the debug memory allocator. This means that all memory allocations have guard bytes placed around them. These guard bytes are placed there to detect a memory overwrite. Because heap layout is different between release and debug versions, a memory overwrite might not create any problems in a debug build, but may have catastrophic effects in a release build.

See Check for Memory Overwrite and Use the Debug Build To Check for Memory Overwrite for more information. 

Compilation
Many of the MFC macros and much of the MFC implementation changes when you build for release. In particular, the ASSERT macro evaluates to nothing in release build, so none of the code found in ASSERTs will be executed. See Examine ASSERT Statements for more information. 

Some functions are inlined for increased speed in the release build. Optimizations are generally turned on in a release build. A different memory allocator is also being used.

Pointer Support
The lack of debugging information removes the padding from your application. In a release build, stray pointers have a greater chance of pointing to uninitialized memory instead of pointing to debug information.

Optimizations
Depending on the nature of certain segments of code, the optimizing compiler might generate unexpected code. This is the least likely cause of release build problems, but it does arise on occasion. See Optimization Problem for a solution. 
****************************************************

Donc apparement il y a quatre sortes de changements :
- Heap Layout
- Compilation
- Pointer Support
- Optimizations 

j'espere qu'il n'y a que ca qui change, je fais encore chercher plus loin ...

3psilon · Answer

Je vais tenter de me renseigner aussi.

Si une personne passant par la connait la réponse ou un site expliquant les grandes differences entre ces deux modes,
merci de laisser un pti message

Bye

3psilon · Answer

Bon, ma fois, j'ai trouvé la mm chose que toi  JCDjcd

msdn

Perso, il va me falloir un dico et un bon café pour décrypter tout ca ;)

Sinon j'ai vu qu'il existait quelques softs :

- BoundsChecker : détecteur automatique d'erreur pour Visual C++. (numega)
- TrueTime : profiler analyse de performance et d'optimisation pour Visual C++.
- True Coverage : couverture de code, détermine le pourcentage des applications et des composants déjà testés.

Je voudrais savoir si qq1 aurait deja eu recours a ce genre de softs ?

3psilon · Answer

Slt,

Concernant debug-release :

1) Le meme lien que dans mon post precedent mais en francais cette fois :)  msdn

2) Présentation du tas :

La présentation du tas est à l'origine de 90 % environ des       problèmes apparents quand une application fonctionne en version debug, mais pas en version release.
Lorsque vous générez votre projet pour la version debug, vousutilisez l'allocateur de mémoire debug. Ceci signifie que toutes les allocations de mémoire sont entourées d'octets de garde. Ces
octets de garde détectent les remplacements de mémoire. Dans lamesure où la présentation du tas diffère entre les versions release et debug, un remplacement de mémoire peut ne pas créer d'incidents dans une version debug, mais avoir des effets  catastrophiques dans une version release.

src : [    http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/vccore/html/_core_Examine_ASSERT_Statements.asp msdn]

Voir aussi : 
[    http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/vsdebug/html/vcoriDebuggingTechniquesForVisualC.asp msdn]
[ http://www.codeguru.com/forum/showthread.php?t=269905  codeguru]

+++

cs_JCDjcd · Answer

oki merci

Tri listview ( debug - release )

14 réponses

Votre réponse

Discussions similaires