Demande fonction KGF pour inclure une série dans une liste.

Citation :

C'est quel programme qui utilise la dll? le programme distant ou celui qui veut lire.

C'est celui qui veut lire le texte du EDIT distant qui daoit faire ça.

Citation :

comment va t'il savoir la longueur du buffer?

De la manière suivante:

Code:

dim longueur%, cmd%,hnd%, buf$
cmd% = 14 : ' valeur décimale du code message WM_GETTEXTLENGTH
hnd% = ... (handle du EDIT dont il faut lire le texte)
longueur% = dll_call4("SendMessage",hnd%,cmd%,0,0)
buf$ = string$(longueur%+1," ")  : ' +1 pour faire de la place pour le séro terminal
...

J'ai également corrigé quelques approximations dans mon code du post précédent. Avec mes excuses...

Bien que mes yeux se ferme, j'ai eu envie de tester, mais je mélange les pinceaux. Je pense que ce serait intéressant de bien mettre le procédé au point. Ca servira un moment ou un autre.

Ca ne marche pas, mais je ne sais pas trop comment reprendre le programme, et dans quel ordre il faut procédé.

Je me sers du premier programme en exemple à lire. Il faut faire un exécutable de celui-ci avec l'éditeur normal, sinon il faut corriger les erreurs.

Voici tel que j'ai repris ton code. J’ai essayé d'inverser les deux routines, c'est le même résultat. Faut pas m'en vouloir mais je ne suis plus frais en fin de journée.

Code:

' teste communication avec edit compilateur
label ecrire , lire , fin , lire_edit
dim dll$ , exe$ , res%,message$ , recu% , handle$
left 0,600
dll$ = "c:\synedit_editor\kgf.dll"                    :' à modifier
exe$ = "c:\pano\divers\testeeditcompile.exe":' mettre le nom du 1er programme compilé

handle$ = "Réception"

execute exe$ : wait 1000

edit 10:width 10,500:font_size 10,10
button 11:top 11,40:caption 11,"écrire":on_click 11,ecrire
button 12:top 12,40:left 12,150:caption 12,"envoi memo":on_click 12,lire
button 13:top 13,40:left 13,300:caption 13,"stop":on_click 13,fin
button 14:top 14,40:left 14,450:caption 14,"Lire autre":on_click 14,lire_edit

memo 15:top 15,80:width 15,800:height 15,300:font_size 15,10:font_bold 15

repeat
  recu%=clipboard_string_paste$
until recu% > 0 or scancode = 27
caption 0, recu%

end
=============
ecrire:
 message$ = text$(10)
 dll_on dll$
 res% = DLL_call3("IPCSendMessage",adr(message$),len(message$),recu%)
 dll_off
return

lire:
  if count(15) > 0
      lire()
      dll_on dll$
      res% = DLL_call3("IPCSendMessage",adr(message$),len(message$),recu%)
      dll_off
  end_if
return

sub lire()
  dim_local a,aa$ , bb$
  for a = 1 to count(15)
      aa$ = item_read$(15,a)
      bb$ = bb$+aa$+chr$(13)+chr$(10)
  next a
  message$ = bb$
end_sub

lire_edit:
  lire_edit()
return

sub lire_edit()
  if recu% = 0 then end_sub :' handle de l'edit
  dim_local longueur%, cmd%,hnd%, buf$ , adr% , adr2% , i% , wparam%
  dll_on "User32.dll"

  cmd% = 13
  wparam% = 255
  buf$ = string$(255," ")
  adr% = adr(buf$)
  adr2% = adr(lparam%)
  for i%=0 to 3
    poke adr2%+i%,peek(adr%+i%)
  next i%
  res% = dll_call4("SendMessage",recu%,cmd%,wparam%,lparam%)
  ' -------------
  cmd% = 14 : ' valeur décimale du code message WM_GETTEXTLENGTH
  ' hnd% = ... (handle du EDIT dont il faut lire le texte)
  longueur% = dll_call4("SendMessage",recu%,cmd%,0,0)
  buf$ = string$(longueur%+1," ")  : ' +1 pour faire de la place pour le séro terminal
  ' -------------------------------------------------------------
  dll_off
end_sub

fin:
  text 10,"HALT_STOP" : gosub ecrire
  terminate
 

Quand ça marchera, je garderai le code sous le coude, car ça permet plein de choses.

Tu devrais relire le texte de la section "Communication entre programmes". Il y a un texte d'explidation génrale qui décrit la définition d'une "boite à lettres" en utilisant un EDIT avec TOP=LEFT=identifiant. Cet identifiant doit être une valeur négative. Ceci est à faire dans le programme contenant l'EDIT à lire ainsi que dans le programme qui lit. Ces deux EDIT doivent évidemment avoir un identifiant différent.

Cet identifiant doit être passé en paramètre à la fonction IPCGetHandle par le programme qui lit. Celle-ci retourne alors le handle de l'EDIT de la boite à lettre du programme distant. Et le programme distant fait de même pour récupérer le handle de la boite à lettre du progframme "lecteur".

A partir de là, on donne un évènement ON_CHANGE a cet EDIT "boite à lettres", dans chacun des deux programmes. On peut alors envoyer un message à l'autre programme, et cet autre programme sera averti via l'évènement ON_CHANGE de sa boite à lettres (le facteur a sonné...). Ceci est vrai dans les deux sens.

Alors, tu procèdes comme suit:
1. définir les boites à lettres avec leur évènement ON_CHANGE dans les deux programmes. Par exemple, avec les ID -2345 et -2346.
2. le programme "lecteur" envoie un message au programme distant, avec un texte "SendHandle".
3. le programme distant analyse le message reçu dans son évènement ON_CHANGE. S'il découvre "SendHandle", alors il envoie à son tour un message au programme "lecteur", avec le texte "Handle="+str$(handle(17)), si 17 est le handle du EDIT à lire.
4. le programme "récepteur", dans son évènement ON_CHANGE, analyse le message. S'il découvre le texte "Handle=", il convertit le reste en entier et le mémorise comme handle.
5. A partir de ce moment, tu peux fermer KGF.dll et utiliser User32.dll comme je l'ai indiqué ci-dessus.

Ou alors, tu restes avec KGF.dll:
1. définir les boites à lettres avec leur évènement ON_CHANGE dans les deux programmes. Par exemple, avec les ID -2345 et -2346.
2. le programme "lecteur" envoie un message au programme distant, avec un texte "SendData".
3. le programme distant analyse le message reçu dans son évènement ON_CHANGE. S'il découvre "SendData", alors il envoie à son tour un message au programme "lecteur", avec le texte Data="+text$(17), si 17 est le handle du EDIT à lire.
4. le programme "récepteur", dans son évènement ON_CHANGE, analyse le message. S'il découvre le texte "Date=", utilise le reste comme étant le contenu du EDIT.

Bien entendu, on peut passer toute donnée en forme de chaîne de caractères, pas seulement le contenu d'un EDIT.

 Je me suis endormi sur mon ordi. Désolé.

Pourquoi tu changes de sujet? Il ne s'agit pas de KGF, mais de user32.dll. As-tu fait l'essai du programme?
Si c'est le cas, tu as vu que le handel de l'Edit d'en face est dans le caption de la fenêtre. Je pars du principe que le programme distant ne peux utiliser la dll, et apparemment c'est le cas du compilateur. C'est pas grave, on va en rester là. Si j'ai le temps un jour où je ne serais pas pertubé, je regarderai de nouveau. Il n'y a pas urgence, c'était pour suivre une idée, par curiosité.

Bonne nuit.

Citation :

Il ne s'agit pas de KGF, mais de user32.dll.

Bizarre. Pourtant, tu appelles bien les fonctions IPCxxx, et ce sont des fonctions de KGF.dll, pas de User32.dll.

Effectivement il utilise IPC, et ça fonctionne bien. Je n'ai pas ici utilisé IPCGetHandle, mais le presse papier pour récupéré le handle de l'edit, vu que je pars du principe que pour l'instant qu'une dll ne marche pas avec le compilateur (voir message de Papydall à ce sujet).

En lançant le programme, je lance en même temps l'autre programme qui est exe$, c'est-à-dire le premier programme du haut qui doit-être un exécutable! Bon, ensuite dans le programme de droite en écrivant dans l'edit du haut, puis en cliquant sur: 'écrire' , celui-ci est recopié dans celui du programme distant qui est celui de gauche. Là pas de problème.

Maintenant en écrivant dans le memo de droite, puis en cliquant sur 'envoi memo', le memo est recopié dans l'edit du programme de droite, qui le décompose et le réécrit dans le list du même programme. Pas de problème ça fonctionne encore.

Ensuite à la fin du programme appelant, celui qui génère le programme de droite, il y a une autre procédure que j'ai nommé: sub lire_edit(). Cette procédure est en teste, et utilise user32.dll, et c'est de celle-ci qui est question. Elle est d'ailleurs pas fini vu que je ne visualise pas le contenu de ce que j'attends. C'est de ceci que je parle. Elle est censée fonctionner en mettant un texte dans l'edit du programme de droite, puis en cliquant sur le bouton: 'lire autre'. Et là il y a message d'erreur.

Pour moi, normalement la programmation est fini jusqu'à ce soir (comme les autres jours d'ailleurs). Et rien ne t'oblige d'y répondre, vu que je suis pas sûre de m'en servir maintenant.

Je pense que la sub lire_edit() serait mieux ainsi:

Code:

sub lire_edit()
  if recu% = 0 then end_sub :' handle de l'edit
  dim_local longueur%, cmd%,hnd%, buf$ , adr% , adr2% , i% , wparam%
  dll_on "User32.dll"

  ' -------------
  cmd% = 14 : ' valeur décimale du code message WM_GETTEXTLENGTH
  ' hnd% = ... (handle du EDIT dont il faut lire le texte)
  longueur% = dll_call4("SendMessage",recu%,cmd%,0,0)
  buf$ = string$(longueur%+1," ")  : ' +1 pour faire de la place pour le séro terminal
  ' -------------------------------------------------------------
  cmd% = 13
  wparam% = longueur%
  adr% = adr(buf$)
  adr2% = adr(lparam%)
  for i%=0 to 3
    poke adr2%+i%,peek(adr%+i%)
  next i%
  res% = dll_call4("SendMessage",recu%,cmd%,wparam%,lparam%)
  dll_off
end_sub

On demande d'abord la longueur du contenu du EDIT, on prépare ensuite la variable buf$, puis on lit le contenu du EDIT dans la variable buf$.

Merci Klaus d'avoir regardé.

Je viens de reporter la sub, mais en ligne 65:   longueur% = dll_call4("SendMessage",recu%,cmd%,0,0) , j'ai le message: (29) Not correct arithmetic expression : Error in function. Line: 65

@+

Alors, essaie avec SendMessageA au lieu de SendMessage. Cela prendra la version ANSI de l'API.

Oui Klaus, ça fonctionne bien ainsi.

Je publierai le code après l'avoir remanié, pour que celui qui est intéressé puisse utiliser le principe. On pourrait ainsi avoir un programme normal avec l'éditeur, et échangé avec le compilateur des données, pour un affichage rapide. Il faudra attendre un peu, j'ai des choses urgentes à faire.

Ouf ! C'est bien - tu y es arrivé ! Je vais y réfléchir, mais je pense que je vais intégrer dans la doc de KGF.dll, ton système de transmission du handle, comme alternative à la fonction IPCGetHandle.

Je remets le code de la sub en question, car il y a une modification.

J'ai eu des problèmes de pointeur, mais ainsi ça semble résolu.

Code:

sub lire_edit()
  if recu% = 0 then exit_sub :' handle de l'edit
  dim_local longueur%, cmd%, buf$ , adr% , adr2% , i% , wparam%
  dim_local v , aa$
  dll_on "User32.dll"

  ' -------------
  cmd% = 14 : ' valeur décimale du code message WM_GETTEXTLENGTH
  longueur% = dll_call4("SendMessageA",recu%,cmd%,0,0)
  buf$ = string$(longueur%+1," ")  : ' +1 pour faire de la place pour le zéro terminal
  ' -------------------------------------------------------------
  cmd% = 13
  adr% = adr(buf$)
  adr2% = adr(lparam%)
  wparam% = longueur%  :' indispensable d'avoir une variable qui reprenne longueur%, sinon problème de pointeur
  for i%=0 to 3
    poke adr2%+i%,peek(adr%+i%)
  next i%
  res% = dll_call4("SendMessageA",recu%,cmd%,wparam%+1,lparam%)
  '                                                 +1  car il manque un caractère
  message buf$
  dll_off
return

Mais pour le compilateur, il y a un réel problème avec les label, surtout avec gosub.
Le mélange de sous-programme et de sub posent problème, sans compter des différences en un programme normal et compilé concernant des retours chariots sur un edit.

Oui, je sais, Cosmos70. Pour le moment, je suis le compilateur de loin - il y a trop de contraintes et restrictions par rapport à la version interprétée. Plusieurs commandes et fonctions ne sont et ne seront pas implémentées, ce qui fait que les codes existants ne seront pas forcément portables vers le compilateur. Il faudra écrire spécifiquement pour le compilateur.