Version imprimable
Bonjour à tous,
Devant m'atteler à la conception d'un soft sur demande spécifique, j'ai pour contrainte de définir le "Window Name" et la "Class Name" d'une form.
En effet, cette form doit recevoir des messages d'une autre application qui utilise la méthode FindWindow.
Après diverses recherches sur le net, je ne trouve rien qui puisse m'aiguiller.
Quelqu'un a t'il une solution ou des pistes concernant ce problème?
Merci d'avance
PS : Je précise qu'il me faut une solution en C# ou VB
pour définir le class name et le windows name il faut le faire avant meme que la form ne soit créée...
en effet cela se fait au moment des appels à l'api windows qui va créer effectivement le controle... ce que dotnet fait pour toi puisqu'il fourni la classe (bridge natif/managé) et la fenêtre à créer...
RegisterClass
CreateWindow
sont les 2 méthodes natives concernées.
Problème, même si tu peux éventuellement changer le windowname, la classe cela risque d'être difficile, en effet, les appels API sont effectués au moment où tu instancie la form.
on ne peut donc à priori pas changer la classe registered...
il va peut etre falloir que tu oublie les winforms et te fasse tes propres wrappers...
ou alors tu va devoir envisager une solution hybride en C++/CLI.
Ne serait-il pas plus simple d'employer un mode de communication interprocessus plus "conventionnel" comme les NamedPipe ou les Sockets?
Merci pour ta réponse.
Si ça n'avait tenu qu'à moi, j'aurai effectivement pensé à des moyens de communication beaucoup plus simples.
Malheureusement, je me trouve face à la "solution" d'un éditeur tiers, et je ne peux donc pas faire autrement que d'utiliser leur protocole. A moins que je ne réussisse à les faire changer d'avis (et ça, c'est pas gagné).
Sinon, en effet, il me reste la solution de créer une appli en C++ qui recevrait les messages, et serait chargée de les retransmettre via un protocole définit.
Mais vu que je ne connais strictement rien au C++, ça me paraît compromis.
Peut-être (à essayer quand même) :Citation:
j'ai pour contrainte de définir le "Window Name" et la "Class Name" d'une form.
- "Window name" pourrait être redéfini via la propriété Text de la forme,
- "Class Name" serait défini par la propriété Name de la forme.
Parfois, les choses sont aussi simples qu'elles le semblent, enfin, en partie ;)
Donc, pour le window name, il suffit en effet de définir la propriété Text de la form. Merci Graffito.
Concernant le class name, le fournisseur de mon appli tierce m'a fourni du code, qui a le mérite de fonctionner, qui me paraît relativement obscur (car peu commenté il faut avouer), mais que j'ai pu adapter pour faire fonctionner mon appli, sans pour autant comprendre son fonctionnement dans le détail, ce qui m'ennuie fortement, mais peut être pourrez vous m'aider.
En gros, il permet d'obtenir les messages remontés par une appli nommée Main.exe dans mon appli courante nommée App.exe . Main.exe monitore les états (état batterie, branchement de l'usb, etc..) d'un matériel executant WinCE 6.0 , et notifie l'appli App.exe de ces changements d'état. On peut aussi, depuis App.exe, envoyer des commandes à Main.exe pour définir certaines valeurs (dans l'exemple, le niveau de luminosité de l'écran).Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
De ce que j'en ai compris :
- Lors du chargement de la form, on exécute un Findwindow pour obtenir le handle de la fenêtre de mon appli courante (App.exe) et de l'appli Main.exe . Seul celui du main nous sera utile ensuite, celui de l'app courante n'est utilisé qu'à titre d'information.
- Ensuite, vient une ligne de code (commentée "Subclassing" ???) dont je ne comprends pas le fonctionnement :Mis à part le fait qu'on lui passe un pointeur vers une fonction qui s'occupe de traiter la réception de message.Code:
2
Enfin, dans la fonction qui s'occupe de la réception du message (fonction WinProc), on traite le message reçu, jusqu'ici je comprends, mais vient une dernière ligne :
que je ne comprends absolument pas. Je n'ai pas la moindre idée de ce qu'elle peut faire.Code:WinProc = CallWindowProc(PrevProc, hwnd, msg, wParam, lParam)
En gros, si quelqu'un comprend quelque chose à cet imbroglio, (et qu'il a le courage de m'expliquer), je lui en serait reconnaissant.
Le "subclassing" permet d'intercepter les messages Windows : http://megaten.alterlinks.fr/vbtools...ubClassing.php
l'instruction "PrevProc = SetWindowLong(hWnd, GWL_WNDPROC, AddressOf WinProc) " récupère la procedure traitant les messages avant le subclassing.
La procedure "Public Function WinProc(... ' Message receive sample" intercepte tous les messages Windows après le SubClassing , en affiche certains dans la TextBox, puis appelle simplement le traitement standard d'avant le SubClassing.
Ahhh, d'accord! Merci beaucoup Graffito, c'est très instructif.
Sujet résolu ;)