handle(numero_form) pas le bon ?

J'ai trouvé un phénomène bizarre qui me pose problème. En apparence, la fonction handle(0) retourne un handle qui est censé être celui de la form 0. Mais pour Windows, le handle de la fenêtre correspondante est différent ! Je ne peux donc pas retrouver un programme Panoramic à partir d'un autre programme Panoramic avec la fonction FindWindow de Windows; je ne peux même pas passer le handle de ma propre fenêtre form 0 à une API Windows pour faire quelque chose.

Le petit programme suivant met le problème en évidence. En cliquant sur le bouton "Lancer", les deux edit se remplissent. Celui de gauche contient handle(0), celui de droite le handle de la fenêtre de la form 0 vu par Windows.

Une aide serait vraiment la bienvenue :

Code:

' programme test pour handle et FindWindow
label lancer
caption 0,"Test-Handle"
dim i%,h%,i0%,a%,a$
alpha 11 : top 11,10 : caption 11,"Handle(0)"
alpha 12 : top 12,10 : left 12,150 : caption 12,"Handle Windows"
alpha 13 : top 13,10 : left 13,300 : caption 13,"handle_canvas(0)
edit 1 : top 1,30
edit 2 : top 2,30 : left 2,150
edit 3 : top 3,30 : left 3,300
button 4 : top 4,70 : left 4,10 : caption 4,"Lancer" : on_click 4,lancer
a$ = caption$(0)
a% = adr(a$)
i0% = 0
end

lancer:
text 1,""
text 2,""
h% = handle(0)
text 1,str$(h%)
wait 1000
dll_on "user32.dll"
i% = dll_call2("FindWindowA",i0%,a%)
text 2,str$(i%)
text 3,handle_canvas(0)
dll_off
return

Juste une supposition, mais je ne m'avancerai pas trop :
Peut être parce que user32.dll a été écrit en C++ et que le format de retour
n'est pas tout à fait compatible avec ce qu'attend Panoramic ?

Normalement, les fonctions de user32.dll sont appelées avec la convention stdcall - comme toutes les DLL en Panoramic...

oui, normalement...
mais lorsque j'ai voulu faire ma première dll avec Dev-C++ pour Panoramic, cela planté méchamment (pourtant j'avais tout fait pour avoir une dll classique au niveau des appels)... d'où mon passage en Delphi où là je n'ai pas rencontré de pb....

Je ne sais pas, ça m'a l'ai bon pour l'appel de la fonction FindWindowA dans user32.dll. Je peur même utiliser le résultat (le handle vu parf Windows) pour faire autre chose avec, avec d'autres API. Mais pourquoi handle(0) donne-t-il un résultat différent ? Que handle_canvas(0) soit différent, c'est normal. Et handle_canvas(0) change même selon les modifs qu'un apporte à l'affichage, ne serait-ce qu'un redimensionnement de la fenêtre. Mais handle(0) ? J'aimerais bien savoir ce que Jack pense de cela.

bon,jour Klaus

j'ai fait l'essai avec un petit utilitaire qui me renvoie le Handle de la fenêtre pointé par la souris.

A première vue Handle(0) renvoie bien la bonne valeur.
C'est bien le résultat de la dll qui est faussé...

tu trouveras les sources de l'utilitaire ici:
http://www.phidels.com/php/index.php3?page=../php/pagetelechargementzip.php3&id=201&PHPSESSID=d3d1930

Merci pour ton aide. J'ai téléchargé le truc et je vais analyser ce qui ne va pas.

Une petite idée :
Lorsqu'on lance panoramic_editor, celui-ci génère un panoramic.exe (qui je suppose est l'interpreteur) dans le répertoire documents & setting \Tmp
Il est résident en RAM mais je n'arrive pas à l'identifer...

Dans ce cas PRECIS, Plutot que d'utiliser user32.dll Pourquoi tu n'utilises pas par exemple en Delphi (dans ta dll)
FindWindow(nil,'Test-Handle') ?

cela fonctionne très bien...

Eh bien, précisément parce que je ne voulais pas passer par une DLL pour cela, mais le faire directement en Panoramic, avec les possibilités de Panoramic qui doit pouvoir appeler une fonction dans une DLL. C'est fait pour. Je connais bien la fonction Windows FindWindow que j'appelle également dans la dll KGF.dll, mais ici, le problème était différent.

Bon ben du coup il y a plus de problème alors si handle() fonctionne ?...

Oui, j'utilise handle(0) et cela marche (voir ma nouvelle contribution LoadProgram.dll).

Mais je n'arrive toujours pas à comprendre pourquoi mon appel à FindWindowA dans USer32.dll ne marche pas. Il devrait retourner le même résultat que handle(0) ! Or, il est différent. Pourquoi ? J'ai choisi cette fontion comme exemple car il est facile de comparer son résultat avec handle(0), mais en réalité, le problème est plus vaste: j'ai une différence sur d'autres fonctions de cette dll quand je les appelle par Panoramic par rapport à l'appel par Delphi. Cela ne devrait pas être. Si le problème est résolu pour le cas présenté ici (FindWindowA <-> handle(0)), je pense alors avoir la solution globale...

Oui, je comprend le pb :

Code:

function FindHandle(Titre:integer): Integer;stdcall;
var
    fen:pchar;
begin
 fen := pchar(Titre);
{
 result := FindWindow(nil, fen);
}
result := 1234;
end;

Au final j'ai même mis en dur 1234 car j'avais des gros doutes sur ce que je récupérai sous panoramic...
Encore un pb sur la façon dont sont stockées les chaines sous delphi ?

Ma fonction IPCGetHandle prend en entrée le nom d'un programme (caption(0)). Puis, elle utilise FindWindow pour trouver le handle Windows de la fenêtre. Voici le code réduit au problème de trouver le handle de la fenêtre, et tu verras le traitement du passage d'une chaîne. Ce n'est peut-être pas élégant, mais ça marche avec les strings Panoramic:

Code:

function IPCGetHandle(const nam: pchar; const lon: integer; const id: integer): integer; stdcall; export;
var
        wnd: hWnd;
        pstr: PString;
        str1: pchar;
begin
        pstr := PString(nam);
        str1 := pchar(pstr^);
        wnd := FindWindow(nil,str1);
        if wnd<>0 then begin
...
end;

Cette fonction est appelée par Panoramic de la manière suivante:

Code:

dim s$,i%,id%
s$ = "xxxx" : ' la caption(0) exacte
id% = -1200  : ' identifiant d'une boite à lettre (voir KGF.dll)
i% = dll_call3("IPCGetHandle",adr(s$),len(s$),id%)

Merci Klaus !

Donc si je comprend bien :
le fait de recaster le pchar en Pstring dans un autre pointeur permet de tenir compte du format Delphi, puis il suffit de repointer a nouveau sur le véritable début de la chaine avec str1...
c'est ça ?

Je ne suis pas sûr du tout en ce qui concerne l'explication du phénomène. Je suis novice en Delphi (je l'utilise depuis Novembre 2009 pour faire une DLL pour Panoramic), et j'ai appris sur le tas, à l'aide de moulte consultation de l'aide et de Mr. Google... J'ai essayé de multiples combinaisons qui n'ont pas marché. En analysant mes essais, j'ai eu l'impression que adr(s$) livre l'adresse d'un descripteur contenant l'adresse vers le début de la chaîne, mais Jack m'a dit que je me trompe... En tout cas, en regardant ce qu'il y a à l'adresse fournie par adr(s$) je ne trouve pas le premier caractère de ma chaîne, et j'ai eu de la chance de trouver cette construction. Je l'utilise depuis, et c'est sans problème.

J'ai oublié de préciser que PSTRING est un type que j'ai déclaré comme suit:

Code:

type
    PString = ^String;

J'avais deviné pour PString,
le nom de déclaration est assez parlant...

Je vais essayer de me pencher un peu plus sur ce truc... (pas avant lundi, week-end oblige)

je suis sûr que cela doit être tout bête.
Tellement gros que l'on passe à côté d'une chose évidente...

type
PString = ^String; définit le type PString comme "pointeur sur un string"

si ensuite dans un var, on utilise ce type par pStr : PString; alors pStr sera un pointeur sur un string:

Code:

type
PString = ^String;

var
pStr : PString;

les DLL sont développés en C?

Une DLL peut être réalisée par beaucoup de langages de programmation, C bien sûr, mais aussi Delphi, Visual Basic, diverses versions de Fortran, Pascal, etc.

Les DLL que je réalise sont écrites en Delphi 6.

Bonjour Klaus,

Un truc pour simplifier l'écriture...

Code:

type
  PAnsiString = ^AnsiString;


function IPCGetHandle(const nam: PAnsiString; const lon: integer; const id: integer): integer; stdcall; export;
var
        wnd: hWnd;
begin
        wnd := FindWindow(nil,pchar(nam^));
        if wnd<>0 then begin
...

Bonne soirée !

Merci ! Je garderai l'astuce.