LIBRAIRIE DE NOMBREUSES FONCTIONS POUR AGIR SUR LES FENETRES, PROCESSUS ET THREA
MadM@tt
Messages postés
2167
Date d'inscription
mardi 11 novembre 2003
Statut
Membre
Dernière intervention
16 juillet 2009
-
28 juil. 2006 à 23:59
insosama Messages postés 5 Date d'inscription mardi 7 août 2007 Statut Membre Dernière intervention 8 mai 2008 - 16 avril 2008 à 23:49
insosama Messages postés 5 Date d'inscription mardi 7 août 2007 Statut Membre Dernière intervention 8 mai 2008 - 16 avril 2008 à 23:49
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/38829-librairie-de-nombreuses-fonctions-pour-agir-sur-les-fenetres-processus-et-threads
https://codes-sources.commentcamarche.net/source/38829-librairie-de-nombreuses-fonctions-pour-agir-sur-les-fenetres-processus-et-threads
16 avril 2008 à 23:49
je crain cependant de pas avoir le niveau pour encore bien l'assimiler et l'utiliser. enfin, comme cela a déja été dit, c'est en s'arrachant les cheveux sur des codes obscure que la lumiere finit par eclairer le tout (je sais, a ce niveau, c'est quasi-mystique).
bon, blague mise a part :
vous croyez que ca serait possible d'utiliser ces fonctions pour ellaborer un logiciel de deploiement de setup ?
en fait, j'aimerais partir de cette idée (!!! auto-it !!!) : http://www.supinfo-projects.com/fr/2006/autoit_2006/3/ qui consiste, globalement, a "scripter" une installation de logiciel.
a partir de cette idée, du constat que auto-it et les aides en fr complete et interressante ne sont pas légion, et que pour l'installation, certaines fonctions plus poussé peuvent etre interressante : fonction logique, base de registre, etc, etc, etc, j'en suis venu a la conclusion que le mieu serait de faire la meme chose, mais sous VB (logique, quoi).
il y aurait : un "installeur" capable de lire des "script" (en fait de simple texte dans lequel figure les opération a faire sur les fenetre et les fichiers), un logiciel qui serait capable de sequenser l'utilisation de plusieurs script et de definir d'eventuel variable d'exploitation (adresse d'installation, options, etc ...) et enfin, IDEALEMENT une derniere capable de "snifer" une installation en court et d'enregistrer le script correspondant.
dans ce sens, est ce que ce code correspond a mon "cahier des charges" ?
est ce que la suggestion de eldim est bonne (sur les send message) pour l'utilisation que je veu en faire, et est il possible dans ce cas d'integrer ces fonctions a peu pret facilement ? (ou alors devrais je coder ca directement dans le corps du programme, et non l'integrer dans les modules)
enfin, voila. a priori, je vous rassure de suite, je suis pas cinglé, je me rend compte que OUI cette source correspond, au moins en partie, et pour d'autre trop pour moi ^^, mais si vous avez des precision a apporter sur l'utilisation de ce code dans mon optique ... je vais pas "cracher" sur de bons conseils avisé, non ?
petite idée a la noix d'ajout : gestion des "popup" ? en tenant compte de l'anulation de ces dernieres par un "clic" a l'exterieur (source : http://www.vbfrance.com/codes/POPUPMENU-PERTE-FOCUS_26106.aspx).
ca fait partie de la gestion des fenetres, ca serait peut etre "de circonstance"... comme ca peu etre jugé completement "hors sujet" ^^
encore bravo (je m'acharne a comprendre, mais au moins on peu pas dire que ca soit pas commenté) et un chiti 10.
ps : ton code et vista ?
7 avril 2008 à 11:03
Private Sub Form_Load()
Dim tabProcessID() As Long
Dim tabHWnd() As Long
Dim T As Long
' Liste les processus
mpListProcess tabProcessID()
lstProcess.Clear
For T = LBound(tabProcessID) To UBound(tabProcessID)
lstProcess.AddItem mpGetProcessName(tabProcessID(T))
Next T
' Liste les fenetres
mwListWindows tabHWnd()
lstWindows.Clear
For T = LBound(tabHWnd) To UBound(tabHWnd)
If mwIsWindowVisible(tabHWnd(T)) Then
lstWindows.AddItem mwGetWindowCaption(tabHWnd(T))
End If
Next T
' Liste les fenetres
mwListTasks tabHWnd()
lstTasks.Clear
For T = LBound(tabHWnd) To UBound(tabHWnd)
lstTasks.AddItem mwGetWindowCaption(tabHWnd(T))
Next T
End Sub
7 avril 2008 à 10:46
Moi je comprend rien à ce que vous dites, cela dit si quelqu'un pouvait me dire comment ça marche, je lui serais plus que reconnaissant...
Merci
20 déc. 2007 à 11:27
Elles me sont très utiles.
26 juin 2007 à 07:46
25 juin 2007 à 22:33
http://vbsystemlibrary.free.fr/
Il s'agit d'un projet bien plus élaborée que celui-la, et possédant en plus une architecture objet un peu semblable au framework .net. C'est un projet open source ouvert à tous, et notre objectif est de créer une librairie très facile d'utilisation et puissante pour pouvoir programmer sous windows. Cela pourra donc peut etre t'aider.
Merci pour ton commentaire
25 juin 2007 à 20:25
21 oct. 2006 à 17:27
Enfin bon le VB n'est pas négligeable quoi ^^
Sinon en ce qui concerne cette librairie, il y aura bientot (très bientot) un projet de lancé avec 2 autres vbfranciens : Draluorg et Violent_Ken, qui consistera en la réalisation d'une "vraie" librarie pour VB (open source bien sur ^^).
Je vous tiendrai au courant, ça devrait pas tarder.
21 oct. 2006 à 16:02
merci pour ce code c'est ce que je cherche :)
11 sept. 2006 à 15:15
Je suis d'accord, mais meme s'il existe des tonnes de truc en C, le VB est meme plus utilisé que le C ou C++ je crois, et pourtant en Vb il y a plein de bouts de code difficile à trouver (je m'en souvien que j'avait galéré pour la conso cpu de chaque process, pour le nom d'utilisateur d'un process etc..)
11 sept. 2006 à 14:58
Moi pareil, j'ai fait un peu de C, mais je suis encore sur VB6.
On n'inventera pas grand chose d'entièrement nouveau en VB, c'est certain. Il existe des librairies en C déjà complètes qui permettent de faire des tonnes de trucs, mais c'est toujours mieux (quand c'est possible) de coder par soi même.
Idem pour moi, je peux faire tout ce que je veux faire en VB pour l'instant. Quand commencera le multi-threading prévu, çà risque de se compliquer.... mais c'est encore possible en VB !
@+
11 sept. 2006 à 14:52
11 sept. 2006 à 14:50
11 sept. 2006 à 14:47
11 sept. 2006 à 14:47
Je suis un irréductible VBiste
Et j'aime pas les noms des objets du framework .net, je trouve que c'est pas super bien organisé.
Et puis imagine j'arrive à faire qqch de potable, après ça pourrait s'adapter en C++, ce qui pourrait etre pas mal non ?
11 sept. 2006 à 14:43
11 sept. 2006 à 14:32
@+ et bonne prog.
11 sept. 2006 à 14:26
Pour ta suggestion, c'est exactement sur quoi je bosse.
Sauf que ce que je fais en fait, c'est une classe, pas un type perso.
Comme ça je fais des classes pour les fichiers, pour les fenetres, process, thread etc... Et comme ça un processus a une propriétés composées d'une liste de classes de thread ou de fenetres etc...
Une sorte de framework pour vb6 un peu (mais juste la partie système).
Il faudrait que je la mettre sur vbfrance un de ces jours (si j'arrive à la rendre un peu plus rapide)
11 sept. 2006 à 14:13
Très intéressantes, les fonctions pour récupérer l'utilisateur d'un processus, vraiment !
Une suggestion : il serait envisageable de créer une nouvelle fonction permettant d'obtenir un maximum d'informations sur un processus (et sur le fichier correspondant) à partir des fonctions déjà présentes dans le module (et avec quelques autres)
Exemple :
'type perso contenant des infos détaillés sur les processus
Public Type PROCESS_INFO
ProcessName As String
ProcessID As Long
ParentProcessName As String
ParentProcessId As Long
ProcessUserName As String
ProcessPriority As Long
ProcessPriorityName As String
NumberOfHandles As Long
NumberOfThreads As Long
NumberOfModules As Long
NumberOfHeaps As Long
'NumberOfDifferentProcesses As Long
FileLen As Long
FileDateCreation As FILETIME
FileDateLastAccess As FILETIME
FileDateLastModification As FILETIME
FileAttribute As Long
IsAttributeSystem As Boolean
IsAttributeReadOnly As Boolean
IsAttributeNormal As Boolean
IsAttributeHidden As Boolean
FilePath As String
ExecutableVersion As String
ExecutableDescription As String
ExecutableCopyright As String
PerfMemoryUsage As Long
PerfPeakMemoryUsage As Long
PerfPageFileUsage As Long
PerfPeakPageFileUsage As Long
PerfQuotaPagedPoolUsage As Long
PerfQuotaPeakPagedPoolUsage As Long
PerfQuotaNonPagedPoolUsage As Long
PerfQuotaPeakNonPagedPoolUsage As Long
PerfPageFaultCount As Long
PerfCpuUsage As Long
timeUserTime As Double
timeKernelTime As Double
timeProcessorTime As Double
tCreationTime As String
tExitTime As String
End Type
Pratique d'avoir un max. d'infos.
Quoi qu'il en soit, très bonne source bien commentée !
@+
1 août 2006 à 16:48
31 juil. 2006 à 16:20
31 juil. 2006 à 16:14
Sinon, très utile comme source merci
31 juil. 2006 à 15:58
31 juil. 2006 à 15:15
Asimengo > merci, sinon il est vrai que renfield a pas tort, enfin je vais réfléchir sur les sendmessage paske ça m'interesse pas mal (merci pour la suggestion), et je suis sur que y'a moyen de s'en sortir ^^
(avec 1 fonction et des constantes ???, ou essayer avec une classe, des objets... je sais pas à voir)
31 juil. 2006 à 11:59
31 juil. 2006 à 11:34
@Renfield: Des commentaires comme le tien là, si on en avait tout le temps comme ça on n'irait plus à l'école. Vivement que tu continue dans ce sens et que la tendance générale des commentaires sur VBFRANCE soit orientée dans le sens de la construction avec autant de délicatesse.
31 juil. 2006 à 10:30
31 juil. 2006 à 09:53
31 juil. 2006 à 08:13
31 juil. 2006 à 07:56
Très bonne idée. Manque juste les sendmessage sur les fenêtres à mon gout... mais super idée
29 juil. 2006 à 13:20
29 juil. 2006 à 13:13
J'ai effectué à peu près tous les changements que tu proposait, sauf mpNbProcess qui pourrait appeler mpListProcess, car je pense que ça serait de la perte de mémoire. En effet dans mpListProcess on fait la liste des process dans un tableau, alors que dans mpNBProcess on a pas besoin de ce tableau, on ne le fait pas et donc c'est déjà ça d'économisé.
Sinon j'ai également modifié dans le module pour fenetres les fonctions ListWindows et ListTasks pour qu'elle ne renvoient pas le nombre de fenetres (on utilise ubound)
Merci et on voit sur msn ce dont tu voulais me parler, ça m'interesse pas mal ^^
29 juil. 2006 à 05:40
concernant le code, j'avoue que c'est assez bien ficellé...
attention néanmoins, à quelques points :
dans mpListProcess, par exemple.
inutile de renvoyer Compteur (la fonction Ubound est la pour ca. au pire, fais en une fonction, qui renverra ce Compteur.)
encore que ce point soit discutable, ton tableau possède une 'case' de trop. Pour corriger cela, fais par exemple :
Do While T
If Compteur > 0 Then
ReDim Preserve tabID(Compteur) As Long
End If
' Enregistre le process
tabID(Compteur) = uProcess.th32ProcessID
Compteur = Compteur + 1
' Prend le suivant
T = ProcessNext(hSnapshot, uProcess)
Loop
question lisibilité, il vaux mieux, si possible éviter les Exit Sub, qui exploitent un code retour d'API :
If CreateToolhelpSnapshot(TH32CS_SNAPPROCESS, 0&) = 0 Then Exit Function
uProcess.dwSize = Len(uProcess)
...
deviendrait :
If CreateToolhelpSnapshot(TH32CS_SNAPPROCESS, 0&) <> 0 Then
uProcess.dwSize = Len(uProcess)
...
End If
dans mpIsProcess et quelques autres, attention, il manque l'appel à CloseHandle.
dans mpFindProcess aussi. De plus, tu utilise Ucase, pour la recherche Instr que tu fais... utilise plutot vbTextCompare comme paramètre de ta fonction :
If InStr(1, uProcess.szexeFile, sProcessNameExe, vbTextCompare) <> 0 Then
remplace les "" par vbNullString :
mpGetProcessPriority = ""
Ca n'est pas de la coqueterie
"" est un pointeur vers une chaine de caractère vide (4 octets, plus les 4 octets nécessaires a stocker la taille de la chaine, vu que VB6 utilise des BSTR)
vbNullString est un pointeur nul)
4 octets, ca n'est rien, c'est sur, mais ca fais toujours un 'voyage' de moins, pour le systeme, pour savoir si la chaine est vide
mpKillProcess devrait renvoyer un code retour indiquant si le process a pu etre killé
tes fonctions devraient s'appeler les unes les autres.
mpNbProcess, par exemple, pourrait appeler mpListProcess
mpGetUserNameFromProcess pourrait être renommée en mpGetProcessOwner
29 juil. 2006 à 01:34
Donc si tu veux les utiliser, pas besoin de les redéclarer, contrairement à si tu passe par une dll, car dans ce cas ton api elle sera déclarée dans la dll et dans ton prog (donc mange + de mémoire)... Enfin je suis pas sur du tout.
Sinon j'ai choisi de bien séparer les modules au niveau des catégories (process, fenetres etc..) et au niveau des déclarations/fonctions pour mieux s'y retrouver derrière, on mélange pas tout
Sinon je pensais rajouter un module pour les "modules" justement, histoire de pouvoir lister tous les modules (dll et autres) auquel accède un processus. Comme je ne m'y suis jamais mouillé je vais regarder un peu, mais si quelqu'un veut proposer quelque chose je suis preneur.
29 juil. 2006 à 01:23
Et bien je trouve que c'est une excellente initiative.
De plus tes codes sont propres et bien commentés.
Je ne manquerai pas à t'informer de fonctions à rajouter.
Juste en passant, bon j'y connais rien donc si je dis une grosse co**erie laisse tombé, mais n'y a t'il pas moyen de placer toutes ces fonctions dans une seules DLL ?
++ & bon courage à toi
28 juil. 2006 à 23:59
- Cette librairie est le rassemblement et l'optimisation de ce que j'ai pu programmer ou trouver sur vbfrance ou ailleurs, je n'ai pas recopié texto des fonctions juste pour dire d'en avoir, j'ai essayé de commenter chaque ligne de code, non seulement pour tout assimiler moi meme, mais surtout pour que les débutant le puissent aussi. Donc pas la peine de dire que j'ai pompé à droite à gauche ;)
- Je ne suis pas un pro de l'optimisation, c'est pour cela que je vous propose qu'on y mette tous notre petite graine, histoire d'améliorer ça au maximum et que tout le monde puisse l'utiliser.
Donc si vous avez des suggestions pour améliorer le code, ajouter/modifier des commentaires, ou des fonctions à ajouter, je vous invite à proposer !
Bonne prog ;)