Discussion :

[Jean-Philippe44]

Bonjour,

je cherche a contrôler un logiciel via vba.

Ca marche bien enfin presque.

Je détermine l'ensemble des handles des controles et envoi soit des postmessage ou des sendkeys.

Je voudrais supprimer les postmessage et les sendkeys puisqu'il y a quelques bugs.

Est ce que connaissant la classe du control et son handle je peux le déclarer en tant que control en vba et donc le manipuler comme s'il était natif

je ne sais pas si c'est possible et je ne trouve pas de fonction en vba qui permet de declarer un objet via son handle

merci

[unparia]

Bonjour

Est ce que connaissant la classe du control et son handle je peux le déclarer en tant que control en vba et donc le manipuler comme s'il était natif

Si telle est ta question, la réponse est non.
Tu peux à la rigueur lui adresser des messages (si fenêtre Windows à part entière), mais non le "manipuler comme s'il était natif" .

[Jean-Philippe44]

Bonjour, je suis Breton !!!

est ce que l' UI Automation ne peut pas etre une solution a mon probleme?

[unparia]

L'automation (et uniquement si l'application "pilotée" la supporte), permet de manipuler les objets de l'application ainsi "pilotée". Cela ne fait pour autant en aucun cas de ces objets des objets de l'application pilotant.

[Jean-Philippe44]

je cherche a contrôler un logiciel via vba.....

je vais voir demain si j'ai les info via Inspect

par contre, je cherche de la doc et si tu as un lien, je suis preneur

merci

ce que je veux c'est simplement faire des click, envoyer du text sur un logiciel..............

j arrive sur des control "classiques" mais j'arrive a rien sur des controles de type class:

XTPReport
xtpBarTop
xtpBarBottom
xtpBarLeft
xtpBarRight

[unparia]

Ta question est donc finalement la même que celle d'une autre discussion que tu as ouverte sans succès : déterminer le handle de certains contrôles présents sur la fenêtre d'une application externe ouverte.
La lecture de ton autre discussion montre que tu sais parcourir les fenêtres enfants de la fenêtre principale, n'as aucune difficulté à déterminer le handle de certains contrôles, mais en rencontres avec d'autres. Il s'agit là d'un scénario assez classique : ===>>
Les fenêtres (contrôles, donc) sont identifiables de plusieurs manières :
- la première (utilisation de la fonction GetFocus de l'Api de Windows) est ici à exclure, puisqu'elle signifierait que tu es déjà sur le contrôle que tu cherches à manipuler :
- parlons alors des deux autres (avec FindWindow) :
1) ----- extraction à l'aide de son titre, lorsqu'elle est doté d'un titre (en espérant toutefois que ce même titre (caption) n'ait pas été également donné à des contrôles autres
2) ----- (pas de caption) extraction à l'aide de sa classe, mais gros problème car il devient alors impossible de distinguer entre eux plusieurs contrôles de la même classe éventuellement présents.
Tu sembles bien être dans le cas 2 et je ne peux personnellement alors rien pour toi.

[Arkham46]

Bonjour,

pour ui automation : http://arkham46.developpez.com/artic...ibility/intro/

On ne peut pas tout faire avec cependant, cela dépend déjà si l'application ciblée a implémenté la fonctionnalité.

[Jean-Philippe44]

Bonjour,

Quand il n'y a pas de nom mais seulement la class des controls, j'arrive a m y retrouver, ils sont dans un ordre logique.

Mon probleme c'est que j'ai le handle d'un control qui ressemble a une ListBox mais qui n'en est pas une
(les messages windows ne passent pas et ce n'est pas déclare comme la class d'une Listbox).

Il y a d'autres vraies ListBox que je gère très bien.

Dans cette pseudo ListBox je dois cliquer sur des cases a cocher.....

J ai vu ca: http://www.codemag.com/article/0810122

et ca https://msdn.microsoft.com/fr-fr/lib...v=vs.110).aspx

et comme on peut integrer en reference: UIAutomationClient + ....

je me suis dit que peut être....

Merci pour le lien je vais regarder .....ca ressemble a des enfants caches....

[unparia]

j'ai le handle d'un control qui ressemble a une ListBox mais qui n'en est pas une

et

Dans cette pseudo ListBox je dois cliquer sur des cases a cocher.....

essaye alors d'énumérer les enfants de ce contrôle (puisque tu en as le handle)
Si cette dernière tentative reste sans succès, il ne te reste qu'à solliciter l'auteur de cette application externe

[Jean-Philippe44]

oui mais ca c'est fait, y pas d'enfants avec les API sous Vba mais ils existent...........

donc je vais me prendre la tête mais je dois trouver un moyen pour envoyer des p.. de click sur cette p... de fausse ListBox

[unparia]

oui mais ca c'est fait, y pas d'enfants avec les API sous Vba mais ils existent

VBA n'a rien à voir là-dedans
Si la fonction EnumChildWindows ne recense aucun enfant, ces cases à cocher ne sont peut-être tout simplement pas des vraies fenêtres Windows.
On peut en effet (et entre autres) parfaitement simuler une case à cocher avec un simple label dont la propriété Caption = "", genre

Code :

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

If Label1.Caption = "" Then Label1.Caption = "X" Else Label1.Caption = ""

Or, un label n'est pas une fenêtre Windows et n'est pas doté d'un hwnd. Il est donc impossible de LUI envoyer un message Windows et la seule possibilité est alors d'y mettre le curseur et de simuler un click à cet endroit !
Je ne pense maintenant pas que le concepteur de cette application se soit amusé gratuitement à mettre en place un label (avec tout le code de gestion additionnelle alors nécessaire) au lieu d'une vraie case à cocher. S'il l'a fait (puisque tu dis qu'aucun enfant n'est recensé) je commence à penser qu'il la fait dans le but, précisément, de contrecarrer l'utilisation d'un robot
D'autres stratagèmes, encore plus complexes, peuvent également avoir été mis en place à l'aide de code connexe (scripts)

EDIT : si tu décides (dans l'hypothèse d'un label) de tenter d'envoyer un clic en ses coordonnées à l'écran, méfie-toi, car il y a là peut-être encore une "contre-attaque" que j'ai déjà personnellement utilisée : click sans effet si non fait après un délai minimum de survol du label (quelques centièmes de secondes) suffisent comme délai). De manière à rejeter tout click qui, fait instantanément, révèlerait une robotisation.

[Jean-Philippe44]

Slt,

Inspect c'est de la pure m....

il indique pas les bons parents !!!!!!

Je vais programmer une recherche auto des Handles qui va écrire le code en auto.

[unparia]

Existe également Spy ++, mais si mes hypothèses sont bonnes, il ne t'apportera rien de plus utile !
De toutes manières (je le répète) rien de cela n'a quoi que ce soit à voir avec VBA.
Bon courage.

[clementmarcotte]

Et puis tiens, même si ce n'est pas VBA.

Tu vas sur http://msdn.microsoft.com

Tu trouves le lien de téléchargement vers les outils...

Tu télécharges Visual Studio Community (PAS EXPRESS) gratuit.

Tu te fais soit un contrôle ActiveX, soit une application (complément ou macro complémentaire) Office pour gérer ta fenêtre étrangère au fond de la jungle.

Après cela tu utilises ton composant avec VBA.

Au travers de tout cela, tu vas devoir apprendre à travailler avec l'API Windows et/ou les classes du Framework. Des mois de plaisir...

Mais, une fois que tu as Community, le plus sage c'est de repartir à zéro et de te créer une vraie application autonome plutôt que de vouloir convertir une raffinerie en usine à gaz.

Il n'est jamais trop tard pour apprendre que le mauvais outil fait des employés ina(e)ptes.

[unparia]

Il y a en tout état de cause longtemps que j'aurais mis ce code tout bête dans un Userform, au lieu de traiter "Inspect" (que je n'utilise d'ailleurs jamais) de ..., etc ... :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Private Type POINTAPI
    X As Long
    Y As Long
End Type
Private Declare Function WindowFromPoint Lib "user32" (ByVal xPoint As Long, ByVal yPoint As Long) As Long
Private Declare Function GetCursorPos Lib "user32" (lpPoint As POINTAPI) As Long
 
Private Sub UserForm_MouseUp(ByVal Button As Integer, ByVal Shift As Integer, ByVal X As Single, ByVal Y As Single)
  Dim ici As POINTAPI, ici_hwnd As Long
  GetCursorPos ici
  ici_hwnd = WindowFromPoint(ici.X, ici.Y)
  MsgBox ici_hwnd
End Sub

Pourquoi ce code ? Tout simplement parce-que, en pressant le bouton gauche de la souris, puis, en le gardant pressé, en se positionnant sur une vraie fenêtre Windows, puis, en lâchant alors le bouton de la souris, on a le handle de cette fenêtre.
Si, dans cette manoeuvre le résultat était le même en s'étant positionné sur une de ces "cases à cocher" qu'en se positionnant sur une autre fenêtre de cette fameuse appli, la conclusion serait simple et sans appel : cette "case à cocher" n'est pas une vraie fenêtre Windows et n'a donc aucun handle.
Mais j'arrête ici mes interventions dans cette discussion, car plus on "avance" et moins il s'agit de VBA.


EDIT : le présent message pourra être utile à d'autres. Ce code leur permettra de découvrir que rares sont les contrôles de VBA qui sont de véritables fenêtres Windows. Seuls quelques-uns (dont les listboxes, mais pas les comboboxes) en sont.

EDIT 2 pour uniquement Jean-Philippe44 :
1) garde par ailleurs présent à l'esprit que c'est le système qui attribue, lors de son activation, un handle à la fenêtre activée. Ce handle ne sera donc pas le même entre deux sessions de l'appli comportant cette fenêtre.
2) Les coordonnées retournées éventuellement en modifiant lmégèrement mon code ci-dessus par :

Code :

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

MsgBox ici_hwnd & " au point de coordonnées " & ici.X & "," & ici.Y

sont des coordonnées en pixels par rapport au point 0,0 de ton écran (pas de la fenêtre de l'appli)
Tu peux toujours les transformer (quelques fonctions de l'API de Windows) en coordonnées relatives (par rapport au point 0,0 de la fenêtre de l'appli), mais ces coordonnées ne seront utilisables (pour y simuler un clic) que si immuables (et donc que la fenêtre de l'appli ne soit jamais redimensionnée).
Tu peux enfin, moins maladroitement transformer ces coordonnées relatives en pourcentages par rapport à la largeur et la hauteur de la fenêtre de l'appli concernée.
Dans tous ces cas de figure : garde à l'esprit ce que j'ai exposé plus haut en ce qui concerne les "contre-attaques" qui auraient pu être installées (le délai minimum de" survol", entre autres).
Tu as maintenant tout en main pour te lancer dans ces acrobaties (si tu y tiens vraiment).

[Jean-Philippe44]

déjà je dois retrouver ce que me donne la réponse du code,
j ai été idiot de penser que des tools avaient la bonne réponse ....
donc mes BM_CLICK perdus dans la nature sont ds la logique d'une personne qui ne sait pas ce qu'elle fait
Apres,
je suis débutant mais un peu con de cette perte de temps a avoir confiance sur des tools qui ne connaissent même pas le chemin d'un handle classique
ce soir c'est viernes, entonces ron, manana pero seguro que sera bien la respuesta.

[Invité]

Bonjour,
D'abord on ne sait rien de l'application en question.

Si elle dispose de librairies ou non! Si oui elle doit avoir de références vba utilisable dans le projet Vb!
Si c'est un contrôle sous forme de librairies elle peut être chargée dns le références options parcourir et ensuite ajouter dans la fenêtre des contrôles.

Mais gérer des fenêtres Windows avec des sendkey c'est glaire!

[Jean-Philippe44]

oui, pour les SendKeys, c'est clair et surtout pas propre et aléatoire, au bon vouloir du focus et donc un travail baclé.......

Le logiciel est CaesarII et pour eux, plus ils vendent de licences et mieux c'est donc post traitement a chier et plus c'est long mieux c'est............pcq les délais imposeront plus de licences

[unparia]

Bonjour rdurupt
Ce qui l'es encore plus ("glaire"), c'est sans aucun doute de s'acharner à vouloir traiter par robotisation ce qui aurait été conçu pour contre-carrer une robotisation.
Quel est l'enjeu de tous ces efforts ?
plusieurs réponses possibles, parmi lesquelles :
- soit l'application concernée accomplit des tâches spécifiques. Et il sera alors moins coûteux de développer soi-même une procédure ou un ensemble de procédures pour atteindre le même résultat (c'est là tout le sens de la réponse de clementmarcotte)
- soit il s'agit de robotiser ce qui ne devrait pas l'être (un jeu, par exemple) et on ne comprendrait alors pas le mérite d'un "joueur" qui se ferait remplacer ainsi par une machine !
- soit enfin de "piloter" chez le "voisin" ce qui n'est et ne doit être que la propriété du "voisin"
- soit "inonder" ... (comprendre ce que c'est)
- soit "violer" (je pense à des applications bancaires et/ou autres)
- soit ... à l'infini, mais jamais très "clair" ...
Mais (une fois de plus) : rien de tout cela n'est et ne sera jamais du ... VBA (la présente section).

[Invité]

Bonjour unparia
Je suis d'accord, soit l'application est prévu pour être piloté soit non.

Si elle est pilotable je dois pouvoir trouver sur le site du fournisseur des exemple de code!
Si elle dispose de librairies elle sont disponibles dans Vba!
De toute les façon les évènements ne seront pas gérable sans affecter le contrôle à un objet susceptible de gère les évènements.
Si c'est un contrôle il est pourvu de ces événements et un double click dessus nous envoi au moins sur la méthode Click.

Code :

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

1
2
3
4
5
 
Private WithEvents MyControle as Control
Set MyControle= le_controle
Private sub MyControle_Click()
End sub()

si j'envoie mon objet dans la fenêtre espion je devais trouver quelques indications!

si je fais un click droit sur l'objet->définition J'arrive sur l’explorateur d'objet et je voies les méthode associées!