oui f6 pour générer la solution :p
Pour etre certain vas dans générer>"regénérer la solution".


KEN,

Ok visiblement tes sources ici n'étaient pas du tout à jour, étant abonné à la source j'ai jetté un oeil pensant que tu n'etais pas sous Seven...

Bonne continuation à tous ;)

++

Salut à tous,

Ken:
Je viens de dl la source pour tester sous seven x64

Il semblerait que ton driver "KernelMemory.sys" ne soit pas compatible :s
Il faudrait le debuger/recompiler sous seven en espérant que cette méthode soit encore possible sur cette plateforme :s

Si mes souvenirs sont bon, ce driver avait pour seul but d'éviter les deadlocks sous XP, il serait interessant de voir le comportement sous Seven sans utiliser ces drivers, avec un peu (beaucoup) de chance il se pourrait que ce problème ne se produise pas sur cet OS

AUS3004:
En attendant AUS3004, tu peux d'aller dans le constructeur clsOpenedHandles.vb et commenter la ligne : Class_Initialize_Renamed()

La tu pourra lancer l'appli elle se lancera mais plantera assez vite, car il en resulte des collections vides etc, il te faudra donc désactiver tout ce qui fait appel aux fonctions et objets de cette classe excepté "EnableDebug" et "EnableShutdown".

++

Wai c'est exactement ça, pas facile de trouver la meilleur solution surtout qu'on est souvent tres seul face à nos choix :s
Des fois j'essai de demander a ma copine ce qu'elle en pense mais bon, ca m'aide rarement je dois dire! :)

Wai c'est clair que les listview mangent surement plus que de reinterroger les process...
Je ne sais pas trop ce que tu utilise comme methode pour le refresh, mais si tu stok les infos dans une structure pour comparer et ne modifier la listview que pour les infos differentes de celle affichees ca ne prend presque plus rien.
Mais bon je dis ca juste pour le plaisir d'échanger sur les differentes methodes possible, j'ai fais des tonnes de tools qui listent les process et je remets à chaque fois mes methodes en question afin d'obtenir le meilleur compromis.

Pour mon process mgr il est codé en C.

erf je me disais justement pourvu qu'il ne me sorte pas que c'est pour le GDIObjects :s

C'est en effet une des rares infos dynamique interessante qui necessite le handle
Perso mon choix serait de ne l'afficher qu'a la demande sur une zone de proprite par exemple.

L'avantage est que tu n'interroge plus les process (dans un timer) tu te sers juste des infos recuperees lors du listage, sauf si new process alors tu demandes les infos statiques
Enfin c'est un choix comme un autre, mon explorer n'a pas pour vocation d afficher bcp d infos mais de les afficher le plus legerement possible...

++

Salut,

"pas d'ouverture/fermeture de handles à chaque refresh des process par exemple)"
Tu as besoin des handles pour raffraichir quoi au juste ?
Perso sur mon dernier process explorer je ne reouvre pas les process car pas besoin dans le sens ou les infos dynamique sont renvoyees dans la structure _SYSTEM_PROCESS
celle la meme que tu recupere avec NtQuerySystemInformation

A moins que tu n'utilise pas cette methode de listage ?

Re moi,

Bravo pour toutes ces maj!

Histoire de chipoter encore un peu sur des détails, n'aurais tu pas oublié de mettre ton imagelist sur couleur 32bits ?

++

je suis sous vista mais j'ai pas teste ton tool je me suis basé sur la capture.

En fait oui les columheaders sont bien au style vista, mais pas la selection...
Du moins d'apres ta capture d'ecran...

Pour comprendre ouvre le taskmgr sur l'onglet process et compare la selection a ta listview...

++

re,

SetWindowTheme vas donner le theme de l'explorateur a la listview

tu fais SetWindowTheme(Lv.handle, "explorer")
Ca change le style de la sélection, ca fait comme la lv du taskmgr.

++

Salut a tous,

Ergonomie originale ^^
Ca me donnerait presque envie d'en faire un du genre en C (si quelqu'un connait un Rubban utilisable en C)

Pour la ListView, un petit SetWindowTheme s'impose ;)

Bonne continuation ;)

++