réception clipboard

Invité

J'ai beaucoup de mal de récupérer les infos du presse papier.
Soit avec clipboard_string_paste$ ou clipboard_paste N.
J'ai régulièrement le message suivant: Cannot open clipboard ! Je ne comprends pas très bien pourquoi, je reçois ce message, d'autant le gestionnaire de l'album est ouvert et que l'on voit ce qu'il contient.

Qu'est-ce qui pourrait soit perturber la réception du presse papier, ou bien contrôler pour éviter l'erreur?

Pourtant j'ai déjà utilisé ces commandes, et cela marchait.

Invité

Je m'en suis sorti avec clipboard.
Je ne peux pas dire quels étaient les problèmes, mais comme mon ordi s'est bloqué ce matin, je recommencé le programme de commande.

Apparemment maintenant ça marche, mais je sois encore évoluer et compliquer la tâche. J'espère que ça va marcher, car ce sera une évolution majeur de mon programme.

Invité

Je fais encore ce message, simplement pour qu'il ne soit pas pris ombrage avec le clipboard. Je ne sais pas ce qu'il s'est passé hier soir.

Maintenant cela fonctionne dans les deux sens avec clipboard_string_copy et clipboard_string_paste$ dans les deux programmes, ce qui fait que le programme à cellules, pourra servir de boite de commande multiple, avec des cellules qui pourront être des boutons, des saisies de textes multiple, dont les styles seront prédéfinis, d'éditeur pour afficher un document avec des couleurs. Grace au presse papier, ce programme sera un exécutable en "tâche de fond" pour ainsi dire dont les 900 lignes n'auront pas besoin d'être présentes. Ce sont des commandes simples qui feront la programmation.

Il y aura juste à exécuter le programme avec execute sans le wait. à travers le presse papier, on envoi les ordres pour afficher, cacher, modifier, lire, fermer. Dans ce cas là le programme se ferme.

Invité

Je suis venu régulièrement sur ce programme dans la journée, pour l'amélioré, faire des teste.

Je ne'ai eu aucun problème avec le presse papier, sauf que maintenant ça à tendance à recommencer. Je constate que le processeur tourne, et qu'il y a d'avantage de ressources qui travaille. Donc là il y a problème. Si je suis tributaire des ressources pour faire tourner un programme, il ne peut pas y avoir de stabilité à celui-ci, car à ma connaissance, qu'est-ce que j'ai pour contrôler cela?

Je pensais que ces instructions sur le presse papier, on pouvait s'en servir, mais si il y a blocage à cause du travail qui se fait en tâche de fond (je suppose que c'est l'anti-virus), je ne sais plus ce que je dois faire.

Les instructions et la méthode reste la même depuis ce matin. Au contraire, elle me semble plus efficace (je tiens à dire qu'il y a un wait sur chacun des programmes pour justement économiser les ressources).

Est-ce que Jack peut donner une méthode justement pour qu'il n'y ait pas de problème?.

D'avance merci
Je me demandais si je ne pouvais pas me servir de On_error_goto, mais c'est une instruction que j'ai jamais pu faire marcher, je dirais même que c'est le contraire.

Invité

C'est encore moi, et je crois que je n'aurai pas de réponse.
Je réussi tout au travers du presse papier: ouvrir un fichier, sélectionner une cellule, la modifier à distance, recevoir toutes les infos des cellules, la dernière case ou bouton cliqué, ouvrir ou fermé le menu, bloqué ou débloquer la fenêtre pour avoir l'aide qui va avec. Ok mais voila, régulièrement le presse papier se bloque avec cet info : "Cannot open clipboard". çà me fout mon programme en l'air. J'ai essayé cent solutions, avec les commandes Panoramic, en ce moment c'est avec la DLL de Klaus. Normalement ça marche un certain temps, et puis voila, le message réapparait. Le programme n'est pas bloqué, mais les infos d'un programme à l'autre ne passent plus.
Je vais reprendre la phrase de Jean Claude:

Citation :: Quand je vais relire ce que je viens d"écrire dans un an, j"espère que je ne serais pas désavoué. En attendant je continue de supporter PANORAMIC car on en a bessoin.

Admin Nombre de messages : 2386 Date d'inscription : 28/05/2007

Suite à tes observations, je vais faire des tests poussés sur l'utilisation du presse-papier.
A priori, je ne vois pas d'où vient ton problème.
Mais je peux affirmer 2 choses:
- le message d'erreur que tu observes "cannot open clipboard" n'est pas émis par PANORAMIC,
- pour la lecture du presse-papier (CLIPBOARD_STRING_PASTE$ et CLIPBOARD_PASTE), si le presse-papier est vide ou ne contient pas de texte (il contient par exemple une image), le résultat est la chaine vide.

Invité

Je suis très heureux de savoir que tu comprennes mon problème.
Je mettrais bien mon programme en ligne dans un zip, la seul chose est qu'il y a bien eu 100 transformations, avec des essais différents, et que le dernier programme n'est qui épisode.
J'ai procédé ainsi:
j'ouvre le programme distant , celui-ci envoi un nombre aléatoire de reconnaissance.
à chaque commande que j'envoi, je mets d'abord ce nombre qui doit être reconnu par l'autre programme.
J'ai essayé au départ avec ON_TIMER et clipboard_string_copy et paste$, ça marchait , mais avec ce problème par moment
J'ai essayé ensuite selon le principe du programme que j'avais fais sur les fichier à accès direct, ça marchait et idem
J'ai repris on_timer mais cette fois,je me suis dis que je vais me servir de l'heure pour synchroniser, aussi on_timer change l'heure d'un edit, et avec on_change, en tenant compte du timer de l'autre programme, je regarde la réception du presse papier.
J'essaye plein de chose, ça marche et de temps en temps, ça bloque.

Finalement, je viens de faire un zip, avec le programme du moment (le programme sert juste à faire des essais pour le transfert, mais si ça marche, c'est pas programmation, et non avec des boutons et des memo).
attention, si le message apparait, il faut fermer le programme distant, sinon gestionnaire de taches
le programme est ORDRE Cde.bas
Merci bien
Voir le Fichier : Jack.7z

@ Cosmos70: je te suggère d'utliser mes routines de communication contenues dans ma DLL. Elles s'appellent IPCGetHandle et IPCSendMessage
Ces routines sont à utiliser dans le programme EMETTEUR. Dans le programme RECEPTEUR, il faut déclarer un champ EDIT dont top et left sont régatifs et inférieurs à -500 (ex: -1234)

Dans le programme récepteur, on déclare:
edit 23: top 23,-1234: left 23,-1234: on_change 23,message_recu

Dans le programme émetteur, on fait, une fois au début:
id% = -1234: dest$ = "Nom du programme de destination"
hand% = dll_call3("IPCGetHandle",adr(dest$),len(dest$),id%)

Dans programme émetteur, on fait pour chaque message à envoyer:
res% = IPCSendMessage(adr(mess$),len(mess$),hand%)

Ainsi, tu t'affranchis du presse-papier et tu déclenches le traitement dans le programme récepteur par un évènement on_change. Le message lui-meme, une cha^ne de caractères, est envoyé directement par un service API Windows.

Invité

Je te remercie pour ta réponse.
Je viens de modifier le programme en arrière plan pour apporter des améliorations.

Je suis un peu saturé pour l'instant et j'ai a faire ailleurs. J'essayerai de revoir ta question plus tard, à moins que tu modifies à ta guise le programme de commande qui est dans le zip.

merci bien

Invité

Klaus qu'en tu t'affranchis du presse papier, c'est pour de bon, où juste pour le handle?

Pour le presse papier, je pense avoir compris ce qui se passe. Normalement avec une fait une copie, puis ensuite, il y a lecture. Ici on a deux programmes qui ne se connaissent pas, mais qui communique par l'intermédiaire du presse papier. Je travail avec le gestionnaire de l'album ouvert, et je vois le moment où je tape sur une touche, le presse papier, et la réception, et à force de voir, on fini par se faire une représentation de ce qui se passe. Je pense que parfois le presse papier est sollicité des deux côté en même temps, et dans ce cas, c'est "coller" qui l'emporte. Il vide d'abord celui-ci, puis collecte les infos, et dans ce cas, les infos ne sont pas recueillis, d'ou l'erreur rencontrer.

Je vais voir avec ta DLL, mais auparavant, je vais faire la même chose sur l'autre programme avec TIME$, pour que les deux programmes soient synchronisés, avec un décalage de la réception. Je veux savoir si j'ai vu juste. Dans ce cas, il serait peut-être bon d'avoir une instruction supplémentaire avec TIMER pour avoir ce décalage entre deux programmes. Cela demande réflexion. Qu'en pensez-vous?

Dire qu'on peut s'affranchir du presse-papier, c'était juste une façon de parler. Je veux dire par là que le mécanisme que je propose, remplace totalement la communication par le presse-papier et passe par un autre canal, celui des API Windows.

L'idée est la suivante:
Dans le programme récepteur, on déclare un champ de type edit qui servira de "boîte à lettres". Son contenu sera remplacé à chaque "message" envoyé.

Pour pouvoir identifier la boite à lettres, il faut connaître le nom du programme récepteur (on peut utiliser la caption de la form 0, ça marche très bien), et un identifiant spécifique (correspond à un "canal" ou un "numéro de boîte postale"). Afin de pouvoir faire cela facilement en Panoramic, j'ai choisi d'utiliser la position du edit, à savoir top et left. En donnant une valeur négative inférieure à -500, on est sûr que ce champ n'apparaît pas à l'écran et que ses coordonnées n'offrent pas d'ambiguité avec celles des autres objets Panoramic. C'est donc cette valeur "top" qui sera utilisée comme "identifiant" par le programme émetteur.

On peut même imaginer que pour un programme récepteur donné, on a plusieurs champs boîte à lettres, avec ses identifiants différents. Ces champs peuvent alors servir à définir plusieurs voies d'accès au récepteur, une par groupe de fonctions, par exemple, ou une par programme émetteur autorisé.

Dans le programme émetteur, on utilise une faois au début, la fonction IPCGetHandle en spécifiant le nom du programme récepteur et l'identifiant de la boîte à lettres. La fonction retourne un "handle" qui permet ultérieurement à la routine IPCSendMessage d'envoyer une chaîne de caractères directement dans ce champ edit du récepteur.

Si l'on a spécifié une routine on_change dans le programme récepteur pour ce champ boîte à lettres, elle sera appelée immédiatement après réception d'un message, et on peut consulter text$() de ce champ pour avoir le message. Nul besoin d'utiliser un timer: le programme récepteur, après les initialisations, exécute "end" et attend un évènement. La réception d'un message déclenche alors la routine on_change, elle s'exécute pour traiter ce message, puis elle termine par return. C'est aussi simple que cela.

Bien sûr, il y a le problème du télescopage des messages, si rien n'est fait pour synchroniser les traitements, mais cela est également vrai en passant par le presse-papiers. Je suggère la méthode d'un dialogue formel message suivi de quittance.

Pour cela, le programme émetteur doit également définir une boîte à lettres; elle peut avoir le même identifiant créant ainsi un canal unique bidirectionnel. Au début, après avoir fait IPCGetHandle, l'émetteur doit alors envoyer un message spécifique de connexion, du type "CONNECT monprogramme xxx" (monprogramme représente la caption de la form 0 de l'émetteur, et xxx est l'identifiant de la boîte à lettres).

Le récepteur, en recevant ce message, doit faire un IPCGetHandle avec monprogramme et xxx afin de récupérer l'adresse de la boîte à lettre de l'émetteur.

A partir de ce moment, si l'émetteur envoie un message au récepteur, il doit attendre la confirmation. Ceci donne le temps au récepteur de traiter le message, soit directement, soit en le mémorisant dans une file d'attente. Le récepteur envoie alors une quittance à l'émetteur (du type "OK", "Erreur xxx", "Data xxxxxxxx" etc) ce qui débloque la situation pour l'émetteur qui peut continuer en fonction du contenu de la quittance.

Bien sûr, ce procédé est valable pour 1 émetteur communicant avec 1 récepteur. Je peux de communiquer la procédure à suivre dans le cas de plusieurs émetteurs vers un seul récepteur, mais si ce sont les mêmes fonctions du récepteur qui sont demandées, alors il y a un problème lié à Panoramic car les variables sont peut-être déjà utilisées par le traitement d'un premier message d'un premier émetteur, et un deuxième émetteur mélangerait cela à coup sûr. Cette configuration n'est possible que si chaque émetteur utilise des fonctions bien distinctes du récepteur, et dont les variables ne sont pas mélangées, même pas les variables telles que des indices de boucles etc. Il vaut mieux utiliser plusieurs récepteurs dans ce cas. C'est facile à obtenir: chaque émetteur n'a qu'à lancer son propre récepteur, mais avec un nom de programme différent.

Logique générale du dialogue:

démarrage émetteur
lancement récepteur si nécessaire
émetteur: IPCGetHandle "récepteur xxx"
émetteur: IPCSendMessage "CONNECT moi xxx"

récepteur: si CONNECT alors IPCGetHandle "moi xxx"

puis, pour chaque message:
émetteur: IPCSendMessage xxx message

récepteur: traiter le message, puis
récepteur: IPCSendMessage xxx OK

émetteur: continuer...

Nombre de messages : 7095 Localisation : 77 Date d'inscription : 29/11/2007

Si tu es maître des deux programmes, une idée pourrait être qu'ils se synchronisent eux-même, c'est à dire que celui qui lit le presse-papier l'efface après lecture, ou y mette un accusé de réception, de façon que celui qui écrit attende qu'il ait été lu pour continuer son traitement.
Bon, je ne m'exprime pas très clairement, mais c'est simple à faire.

PS mon message est parti en même temps que celui de Klaus...

Invité

à Klaus
quant tu dis:

Citation :: id% = -1234: dest$ = "Nom du programme de destination"

id%=1234, c'est un nombre au hasard, ou c'est précis?

J'essaye d'analyser tout ce que tu dis, maintenant, il faut absolument que je trouve le temps de reprogrammer et je sais que ça va être dur.

Je vais essayé de faire un exemple très simple pour savoir, si c'est de cette façon que cela fonctionne, parce que modifier un programme sans savoir si on a bien compris la méthode, c'est le rendre mauvais. Je n'ai pas tes facultés.

C'est un nombre au hasard, effectivement. Il faut en choisir un entre -500 et -2000 (limite Panoramic). Alors, c'est comme au loto - c'est par attirance pour un numéro. J'avais pris -1234 parce que les numéros se suivent, mais tu peux prendre -517, -1840, etc. En fait, c'est juste une convention à respecter entre émetteur ét récepteur afin que l'on puisse identifier la boîte à lettres. Le récepteur est identifié par son nom (caption de la form 0), et la boîte elle-même par la valeur top et left qui est justement ce que j'appelle son identifiant.

Invité

Je viens de télécharger KGF.dll, je n'avais que l'ancienne version, vu que la fois précédente, j'avais repris l'ancienne.

Pourquoi tu mets avec mes "routines de service". je pensais en voyant cela qu'il y avait les routines en basic pour fonctionner avec. J'ai compris qu'il s'agissait des différents sous programmes de ta routine.

Ce qui serait bien est de mettre un code qui fonctionne pour chaque possibilité de ta Dll.

Je faire un bout de code dans l'instant, mais c'est sur le forum que je le passe. J'espère que ce soir j'aurai une possibilité.
@+
une question:

Code:: IPCSendMessage( )

n'est pas une fonction basic, si c'est un tableau, il faut déclarer quoi?

Invité

Il y a une chose que je ne pige pas.
Chaque est un programme émetteur et un programme récepteur pour faire des échanges.

Or il y a un chemin de destination avec la variable dest$
L'un des deux programmes pour fonctionner doit être un exécutable, mais l'autre j'ai l'impression qu'il doit l'être aussi si je dois mettre une adresse de destination à l'autre programme.

Je vais te mettre le point de départ de ce que j'ai fait. Peux-tu apporter les corrections. Normalement j'ai un programme jumeaux avec celui-ci.

Autre chose, est-ce que edit peur-être un memo, parce que les infos sont multiples.

Autre chose, l' id% est-ce l' Id% de l'autre programme, et inversement?
Merci

Code:: edit 1:left 1,-1222 :top 1,-1222
edit 2:width 2,width(0)-50
on_change 1,message_recu

button 3:top 3,30:caption 3,"envoi":on_click 3,message_envoi
memo 4:top 4,60

id%=-1235
dest$="C:\TESTE\Fichiers_teste\transmission2.exe"

hand%=dll_call3("IPCGetHandle",adr(dest$),len(dest$),id%)

end
message_recu:
text 2,text$(1)
' accusé réception
mess$="reçu, réponse ordi 2"
res% = IPCSendMessage(adr(mess$),len(mess$),hand%)
return

message_envoi:
' Dans programme émetteur, on fait pour chaque message à envoyer:
' res% = IPCSendMessage(adr(mess$),len(mess$),hand%)
rem "message émetteur"
mess$=""
if count(4)>0
for a%=1 to count(4)
mess$=mess$+item_read$(4,a%)
if a%<count(4) then mess$=mess$+saut$
next a%
res% = IPCSendMessage(adr(mess$),len(mess$),hand%)
end_if
return

Voici un fragment de code qui réalise un émetteur et un récepteur en liaison bi-directionnelle, avec confirmation par le récepteur de chaque message reçu par l'émetteur. Ce code contient la structure logique et un exemple de message application. Il est largement documenté et peut être aisément adapté.

Code:: ' ------ RECEPTEUR.bas
'
' Par convention, le récepteur traite des messages du format suivant:
' <commande> paramètre1[,paramètre2,.....,paramètren]
' Les commandes sont repr&sentées par des mots-clé; une seule est suggérée ici:
' CONNECT programme,identifiant
' programme = caption de la form 0 du programme émetteur
' identifiant = identifiant de la boîte à lettres de l'émetteur

label nouveau_message, connect
label mafonction : ' à adapter...

dim mess$, i%,
dim prog$ : ' nom du programme émetteur
dim id% : ' identifiant de la boîte à lettres de l'émetteur
dim handle% : ' adresse de l'émetteur

caption 0,"RECEPTEUR" : ' pour la fonction IPCGetHandle dans l'émetteur !

edit 17 : ' c'est ma boite à lettres (le 17 esr aléatoire)
top 17,-1234 : ' ceci est l'identifiant de la boite à lettres du récepteur
left 17,-1234
on_change 17,nouveau_message : ' on sera averti lors de la réception d'un message

end : ' et on se met en attente d'un message

' ------ on a reçu un message
nouveau message:
mess$ = text$(17) : ' on prend le texte su message
i% = instr(mess$," ")
if left$(mess$,i%-1)="CONNECT" then gosub connect
' ici, identifier les autres fonctions, comme par exemple:
if left$(mess$,i%-1)="MAFONCTION" then gosub mafonction
return

' ------ CONNECT programme,identifiant
connect:
mess$ = right$(mess$,len(mess$)-i%) : ' on isole les partamètres
i% = instr(mess$,",")
prog$ = left$(mess$,i%-1) : ' on mémorise le nom de l'émetteur
mess$ = right$(mess$,len(mess$)-i%) : ' on ne garde que l'identifiant
if numeric%(mess$)=1 : ' test de numéricité de l'dentifiant
id% = val(mess$) : ' ici, on mémorise l'identifiant de l'émetteur
if id%>-500 : ' pas un identifiant valide ?
id% = 0 : ' alors, on ne renvoie jamais de message à l'émetteur !
prog$ = 0
end_if
handle% = IPCGetHandle(adr(prog$,len(prog$),id%) : ' on récupère l'adresse de l'émetteur
' à partir de maintenant, tout le dialogue va se dérouler avec le handle seulement
else
id% = 0 : ' id pas numérique: on ne renvoie jamais de message à l'émetteur
prog$ = ""
end_if : ' pas d'identifiant valide, on oublie l'émetteur
return : ' la connexion est établie !

' ------ MAFONCTION par1,par2,par3
mafonction:
mess$ = right$(mess$,len$(mess$)-i%) : ' on isole les paramètres
' ici, traiter les maramètres, exécuter ce qu'il y a à faire
mess$ = "OK"
res% = IPCSendMessage(adr(mess$),len(mess$),handle%) : ' envoyer la quittance à l'émetteur
return

' ======================================================================================

' EMETTEUR.bas

label connect
label lambda : ' à adapter...

dim id% : ' identifiant de la boîte à lettres du récepteur
dim handle% : ' adresse du récepteur
dim recept$ : ' nom du récepteur
dim send$ : ' message à envoyer
dim res% : ' code erreur de la fonction API Windows
dim quittance_recue% : ' flag "on a reçu une réponse du récepteur"
dim recu$ : ' texte d'un message reçu du récepteur

caption 0,"EMETTEUR"

recept$ = "RECEPTEUR" : ' fixer le nom
id% = -1234 : ' il faut donner l'identifiant du récepteur !

edit 23 : ' boîte à lettres pour les réponses (le 23 est aléatoire)
top 23,-1239 : ' identifiant de la boite à lettres (pourrait aussi être -1224, ...)
left 23,-1239
on_change 23,nouveau_message : ' pour être averti de la réception d'un message

' --- ici, les autres initialisations du programme

end

' --- ici, les routines d'évènement du programme

' ------ routine établissant la connexion avec le récpteur
connect:
handle% = IPCGetHandle(adr(recept$,len(recept$),id%) : ' on récupère l'adresse du récepteur
: ' à partir de maintenant, tout le dialogue va se dérouler avec le handle seulement
send$ = "CONNECT EMETTEUR,-1239" : ' préparer le message de connexion
res% = IPCSendMessage(adr(send$),len(send$),handle%) : ' envoyer ce message, res% = 0 si erreur API
return

' ------ réception d'un message du récepteur
nouveau_message:
recu$ = text$(23) : ' prendre la réponse
quittance_recue% = 1 : ' et signaler son arrivée
return

' ------ routine pour envoyer un message lambda
lambda:
send$ = "MAFONCTION data1,data2,data3" : ' préparer le message
quittance_recue% = 0 : ' on n'a pas encore reçu de réponse !
res% = IPCSendMessage(adr(send$),len(send$),handle%) : ' envoyer le message
repeat : ' attendre la réponse
wait 100
until quittance_recue%=1
' ici, on peut traiter la réponse contenue dans recu$ !
return

Invité

Finalement je pense que maintenant ça marche.
Depuis que j'ai compris, et cela semble me donné raison, c'est l'envoi et la réception en même temps d'un message du presse papier qui pose problème.

J'ai regardé chaque routine d'envoi et de réception, et fait les commandes dans l'ordre, et il semble qu'il n'y ait plus de problème.

Il y avait des erreurs de méthode. J'ai réutilisé les fonctions suivantes:clipboard_string_paste$ clipboard_string_copy et clipboard_paste + la Dll de Klaus (l'ancienne).

Je crois que dans le manuel, il faudrait bien préciser que la fonction de copy et de paste en même temps provoque le message d'erreur.

Une chose lorsque cela se produit, même si les programmes ne sont pas bloqués, les commandes clipboard deviennent inopérantes.

Pour le fonctionnement: j'ai procédé ainsi:
on_timer,label colle dans un memo le presse papier
avec ce memo: on_change memo, traitement
pendant le traitement le timer et change sont à OFF, ensuite je les rétablis.

Quand je serais sure de moi, je mettrais le code, cela pourra servir.

En ce qui concerne ma fonction ClipboardCopy de ma DLL version ACTUELLE, elle marche si l'on suit le mode d'emploi. Voici un petit pout de code qui le démontre:

Code:: ' test de ClipboardCopy avec KGF.dll

' extrait de la documentation de KGF.dll:
' res% = ClipboardCopy(handle(numéro_objet)) copier le contenu d'un mémo ou d'un edit dans le presse-papier

label copier

dim res%, num%

edit 1
top 1,10
width 1,100

button 2
top 2,10
left 2,150
caption 2,"Copier"
on_click 2,copier

end

copier:
dll_on "KGF.dll"
num% = 1
res% = dll_call1("ClipboardCopy",handle(num%))
dll_off
return

Donc, le code que tu m'as envoyé par messagerie ne peut pas marcher: tu ne lui passes pas en paramètre le numéro de l'objet Panoramic à copier. Ceci explique cela...

Invité

Salut Klaus.
Je ne voulais pas t'embéter sur le forum, juste te dire que je plantais avec le code.
Ce que j'ai mis est juste la ligne, pour faire référence, mais le code complet fonctionne très bien avec la Dll précédente, mais à chaque fois que j'ai fais les essais avec la nouvelle, le programme s'efface, et l'éditeur est bloqué. D'ailleurs je vais mettre le code, le seul problème est le chemin de chaque fichier, mais moi je teste avec mes méthode, et pour l'instant ce n'est pas pour faire une démo.

Code:: top 0,20:width 0,540:height 0,900
dim a%,i% , a$ ,b$ ,saut$ ,controle1$ ,t% , n_objet% ,res%

label envoi , teste ,fin , modifier , recoit_de_lotre_prg
dll_on "KGF.dll" :n_objet% = 1

saut$=chr$(10)+chr$(13)

memo 1 :item_add 1,"commande_charger|C:\TESTE\fichiers_teste\grille_teste.fic"+chr$(0)
memo 2 :item_add 2,"commande_charger|C:\TESTE\fichiers_teste\doublon.fic" +chr$(0)
memo 3 :item_add 3,"commande_charger|C:\TESTE\fichiers_teste\teste prg.fic" +chr$(0)
memo 4 :item_add 4,"commande|ferme" +chr$(0)
memo 5 :item_add 5,"commande|imprime" +chr$(0)
memo 6 :item_add 6,"commande|menu_ON" +chr$(0)
memo 7 :item_add 7,"commande|menu_OFF"+chr$(0)
memo 8 :item_add 8,"commande|débloque" +chr$(0)
memo 9 :item_add 9,"commande|bloque" +chr$(0)
memo 10 :item_add 10,"commande|stop" +chr$(0)

button 11 :caption 11,"ouvrir validation":hint 11,"ouvre boite valide 2 boutons"
button 12 :caption 12,"ouvrir doublon" :hint 12,"ouvre boite doublon 2 boutons"
button 13 :caption 13,"ouvrir test prg" :hint 13,"fenetre teste"
button 14 :caption 14,"fermer" :hint 14,"ferme la fenetre ouverte et non le programme"
button 15 :caption 15,"imprime" :hint 15,"laisser pour l'instant, je me sert de justbasic"
button 16 :caption 16,"menu_ON" :hint 16,"ouvrir un menu sur la fenêtre"
button 17 :caption 17,"menu_OFF" :hint 17,"ferme le menu
button 18 :caption 18,"débloque" :hint 18,"met un bouton au coin haut à gauche"
button 19 :caption 19,"bloc" :hint 19,"retire le bouton"
button 20 :caption 20,"stop" :hint 20,"ferme le programme, puis envoie le signal pour tout fermer"

memo 21 :top 21,410:width 21,520:height 21,100:bar_horizontal 21:color 21,255,251,231
edit 22 :top 22,520 :text 22,time$
memo 24 :top 24,530 :height 24,270:width 24,190
item_add 24,"commande|modifier"
item_add 24,"1:1|modification"
item_add 24,"1:2|on modifie?"
item_add 24,"commande_fin"
list 25 :top 25,520:left 25,200:width 25,320:height 25,340:font_size 25,12:hint 25,"réception des données traduite"
button 26 :top 26,810:caption 26,"envoi modif":on_click 26,modifier:hint 26,"envoi des données à modifier"

for a%=1 to 10
top a%,a%*35-35:top a%+10,a%*35-33
width a%+10,95:width a%,410
height a%,35 : left a%,100 :left a%+10,0 : on_click a%+10,envoi
next a%
' démarrage du programme en fond de tâche
' clipboard_string_copy "départ"
execute "C:\TESTE\fichiers_teste\Text_simplifié_clipboard.exe"
wait 500
' on vient d'ouvrir l'autre programme qui envoi ensuite un numéro de reconnaissance

repeat
a$=clipboard_string_paste$
if instr(a$,"Numéro contrôle:")>0
controle1$=right$(a$,len(a$)-instr(a$,":"))
end_if
until controle1$<>""
' on vient de recevoir le numéro, et celui-ci sera envoyé à chaque fois au départ
' de chaque commande, pour qu'il sache que c'est pour lui

' insert dans la commande le n° reçu de l'autre programme pour reconnaissance
for a%=1 to 10:item_insert a%,1,controle1$:next a% :item_insert 24,1,controle1$
'
clipboard_string_copy controle1$+saut$+"en attente":wait 100
clear 21

' -------------------
timer 23 : timer_off 23

rem "*********** B R A N C H E M E N T S *************"

on_timer 23,recoit_de_lotre_prg
on_change 21,teste
' les boutons sont prg sur: envoi
end

'===============================================================================
' visité par le TIMER
recoit_de_lotre_prg:
clipboard_paste 21
return
' ==============================================================================
teste:
' ici si 21 change, on abouti ici
timer_off 23 : off_change 21
a$=clipboard_string_paste$
if a$=controle1$+saut$+"ordre_reçu:QUITTEZ" then goto fin
i%=instr(a$,controle1$)
if i%>0
if instr(a$,"attente")=0
b$="" : clear 25
repeat
i%=instr(a$,saut$)
if i%>0
b$=left$(a$,i%-1)
item_add 25,b$
a$=right$(a$,len(a$)-i%-1)
end_if
until i%=0
end_if
end_if
clear 21
on_change 21,teste : timer_on 23
return
' ==============================================================================
' chaque clic d'un bouton abouti ici
envoi:
for a%=11 to 20:if clicked(a%)=1 then i%=a%-10 :' si 1, on a le bon bouton
next a%

set_focus i%
res% = dll_call0("ClipboardCopy")
timer_on 23
clipboard_paste 21

return
' ==============================================================================
' modifier du texte dans le fichier appelé
modifier:
timer_off 23
set_focus 24
res% = dll_call0("ClipboardCopy")
timer_on 23
return

' ==================
fin:
dll_off:timer_off 23
midi_on:midi_play 67,6:midi_play 65,8:midi_play 64,11:midi_off:' musique pour bien vérifier que l'autre progr est fermé
terminate

Bon Appétit!

Comme je l'ai dit dans mon post précédent (regarde bien le code), tu utilises dll_call0 pour appeler une routine SANS paramètres, alors que ClipboardCopy attend un paramètre et il faut donc utiliser dll_call1, comme dans le petit programme entièrement fonctionnel de mon post précédent.
Cela concerne les lignes 113 et 123 de ton code.

Je n'ai pas gardé l'ancienne version de la DLL, mais avec l'actuelle, cela fonctionne comme ça, et ça marche.

Invité

Ok compris. En fait j'allais partir, et j'ai vu ton post, et je ne me souvenais pas d'avoir mis du code, à part la ligne. Et je t'ai répondu. Je ne rentre dans le détail que maintenant.

Je crois que maintenant les problèmes sont résolus, je n'ai plus le message d'erreur, et j'essaye autant que possible de mettre du code Panoramic. Merci de ton intervention. Que j'ai une dll ou l'autre, à partir du moment que ça marche, quoi que si je publie et si je me sers de ta dll, je crois qu'il me faudra coder selon la nouvelle version.

Jack peut-être tranquille, ses fonctions fonctionnent.

Merci à toi

» Clipboard
» Clipboard
» Domotique avec Panoramic. RS485, la réception de données
» Version instantanée du 17 juillet 2011: PANORAMIC V 0.9.22i1
» Dlls compilees nouvelle version avec gestion clipboard texte