Synedit Parameters

Une chose est sure, cette fois-ci je n'ai pas créé d'exécutable, j'ai seulement utiliser celui du dossier.

Par contre, je me demande si le filtre Smart screen de Windows ne met pas la pagaille, car à chaque fois que j'appelle un programme en Plug-in, Windows fait son filtrage (en clair: il faut donner l'autorisation).

Je dois quitter, demain je vais tenter de tout recharger et de commencer par lancer tous les Plug-in pour passer le filtrage Windows SmartScreen et ensuite de démarrer BasicEditor.exe et faire les test.

à demain.

Chez moi c' est avast qui inspecte tout à chaque fois.
Mais je n' y crois pas.

le programme appelant avant de lancer l' outils, crée un fichier dans C:\Temp du nom de l' outils avec *.tmp en extension.
Ce fichier contient

Handle du form (de l' appelant )
Langue
Chemin du fichier des paramètres

l' outils lancé, récupère les infos et détruit ce fichier.
il fait ce qu' on lui demande ( quand il est bien luné )
et lorsque l' on valide, renvoi Lparam et Wparam à l' appelant.
Dans Lparam, il y a le numéro de l' outils
1 couleur RGB
2 couleur HTML
3 couleur KGF
4 Paramètres
5 Langue
6 String (code asc() )
7 String ( code chr$())
Dans Wparam, il y a une valeur
Pour Lparam = 1,2 et 3 la valeur KGF de la couleur sélectionné ( L' appelant fait la convertion selon Lparam)
Pour Lparam = 4,5 Wparam =0 Indique seulement qu' il a été fermé
Pour Lparam = 6  Wparam = valeur asc()
Pour Lparam = 7 Wparam = valeur(ch$() l' appelant fait le boulot pour inserer dans le synedit le caractere.

Je crois que je vais arrêter de programmer des trucs complexes.
Cela me prend le chou. On a un comportement et 5 minutes après un autre.
Et ceux sans changer une ligne de code.

Dans 'SyneditParameters.bas', met en rem les lignes de 93 à 99(chargement de KGF pour shortname) et reteste pour voir. J'avais des violation d'accès, et depuis c'est mieux, plus de pb.

Merci Silverman, je vais jeter un oeil  .

Avec la version dispo sur mon webdev je n' ai aucun souci avec le module des paramètres.
Du moins avec une violation d' accès.
Et si je retire cette partie, Jean Claude ne peut plus lancer le sélecteur de couleur...

La version qui me pose des soucis est encore sur mon ordi, enfin sur une clé usb.
J' en ai eu ras la casquette.

Un code à adapter pour lancer un fichier avec n'importe quel chemin de repertoire comportant des espaces, du moment que tes outils n'en comportent pas dans leur nom (100% panoramic):

Code:

start("C:\Program Files\Panoramic Editor V 0.9.25\test0.bas")
end
sub start(file$)
 dim_local current$,pat$,fil$,ext$
   '
   current$=dir_current$
   pat$=file_extract_path$(file$)
   fil$=file_extract_name$(file$)
   ext$=file_extract_extension$(file$)
   '
   if ext$<>""
      if dir_exists(pat$)=1
         dir_change pat$
         if file_exists(fil$)=1
            '
            execute_wait fil$
            '
            dir_change current$
         else
            dir_change current$
            '
            ' erreur : le fichier n'existe pas
            print "no file"
         end_if
      else
         ' erreur : le repertoire n'existe pas
         print "no dir"
      end_if
   else
      ' erreur dans le nom du fichier
      print "error file name"
   end_if  
end_sub

C'est juste une idée à laquelle j'avais déjà pensé, mais je ne l'ai jamais mise en application.

Je vais regarder çà de très près.
L' idée va peut être nous sauver de Windows.
Merci Silverman.


De ce que je vois l' idée est de se placer dans le dossier de l' executable
pour le lancer qu' avec son nom de fichier sans tout le chemin.
L' idée semble bonne.

  Cela fonctionne au poil !

Bravo et merci Silverman.
C' est simple mais encore fallait il y penser.

De rien
J'ai trouvé qq chose qui est peut être à l'origine des pb que tu rencontres:
Place un 'show 0' avant 'dll_off' (KGF), la ça marche sans soucis. Ensuite, déplace le juste après le 'dll_off', et bien la ça plante!
J'ai fais d'autres tests de ce genre, comme mettre en remark tout ce qu'il y a entre 'dll_on' et 'dll_off'. Ca plante aussi!
Je pense qu'il y a une petite incompatibilité panoramic+KGF qui traine qq part; Dès que le 'dll_off' est atteind, c'est la que les ennuis commencent. Reste à voir sur ta machine ce que ça donne.

Bonjour tout le monde !

Je ne sais pas si cela à a voir avec vos problèmes, mais j'ai souvenir d'avoir posté un message qui est passé inaperçu au yeux de tous et qui concernant justement un problème avec DLL_OFF.

J'avais voulu utilisé plusieurs DLLs dans un programme et lorsque je souhaitais changer de DLL j'avais aussi des plantages. Comme personne n'avait fait suite à mon message je pensé que cela venait de moi...

Mais à priori il y a bien un problème !

Bon, hé bien ça avance cette affaire

Merci Silverman.

A+

Là, je crois que tu as mis le doigt sur quelque chose.
DLL_OFF serait bien le coupable.

J' ai mis un DLL_OFF car l' utilisation de la dll était limité à cette procédure.
Et vous remarquerez que sans DLL_OFF que l' on ferme par la croix ou avec un terminate,
il n' y a pas d' erreur.

Citation :

DLL_OFF serait bien le coupable.

Je ne crois pas. DLL_OFF marche parfaitement. Ce qui est en cause, c'est l'arrêt de KGF.dll alors qu'il y a encore des données critiques mémorisées dans la DLL (des chaînes de caractères, en particulier, mais aussi des objets comme des Synedit, l'image interne des fonctions de traitement d'images, etc.

D'ailleurs, est-ce que le DLL_OFF est vraiment nécessaire ? Essaie de le mettre en commentaire...

Je peux mettre à disposition une fonction qui "purge" le contenu encore actif de KGF.dll. On pourrait l'appeler juste avant de faire DLL_OFF. Encore faut-il identifier les ressources concernées dans la DLL. Pour cela, il faut que tu postes la liste de TOUTES, je dis bien TOUTES ! fonctions de KGF.dll que tu utilises dans le programme qui pose problème.

Autre solution, si c'est juste pour fermer ton programme: utilise

Code:

res% = dll_call1("KillProcessByHandle",handle(0))

Ca marche dans tous les cas. C'est ce que je fais dans Synedit_Editor.

@ Klaus,

Dans le cas présent, j' utilise juste "GetShortName".

De toutes les dernières utilisations où j' utilisais Kgf un peu de partout dans le programme
Je me passais du DLL_OFF et je n' avais pas de soucis que ce soit par la croix ou terminate
les deux fermait Kgf comme "KillProcessByHandle".

Là, je crois que j' ai voulu trop bien faire en fermant par DLL_OFF et je l' ai repris dans la poire.
Cà m' apprendra, à vouloir faire les choses proprement.

Ok. Je vais vérifier la fonction GetShortName. Elle semble anodine, mais on ne sait jamais. En attendant, essaie de simplement omettre de DLL_CLOSE pour voir.

C' est fait et cela fonctionne correctement chez moi.

Bien. Je pense qu'il est toujours bon de laisser Windows faire son ménage tout seul, pour la fermeture d'un process. Ce n'est que dans des cas exceptionnels qu'il faut intervenir en amont.

Très bien Klaus mais si l'on souhaite utiliser une autre DLL en même temps que KGF (enfin de veux dire de manière alternative soit l'une soit l'autre) comment doit on procéder ? Y a t'il une manière de faire particulière ?

Demander un cours sur LIBRARY à Silverman.


Il a l' air de maîtriser le dossier.

Deux cas sont possibles dans l'utilisation de plusieurs DLLs:

1. alternativement.
On peut continuer à utiliser DLL_ON et DLL_OFF. Si DLL_OFF pose problème avec KGF.dll, me signaler TOUTES les fonctions appelées dans KGF.dll, et je compléterai une fonction de nettoyage que je suis en train de réaliser de toutes façons.

2. simultanément.
On ne peut plus utiliser DLL_ON, DLL_OFF ni la série des DLL_CALLx. Par contre, il faut passer par le mécanisme implémenté par la commande LIBRARY. Il faut alors déclarer chaque DLL à l'aide de cette commande, puis chaque fonction à utiliser à l'aide des commandes COMMAND ou FUNCTION.

Contrainte spécifique à certaines DLLs (dont KGF.dll): dans certains cas, après l'exécution d'une fonction DLL, des informations significatives restent mémorisées dans la DLL. Si l'on déchange la DLL via DLL_OFF par exemple, ces informations sont perdues, et même une réouverture ultérieure de la DLL ne permettra pas de les récupérer. Le cas flagrant pour KGF.dll est l'image iinterne des fonctions de gestion des images. Mais il y en a d'autres.

Il faut donc bien réfléchir à ce que l'on veut faire avec les DLLs et choisir le système adéquat correspondant.

Merci pour ta réponse Klaus.

Sinon j'ai une autre solution... il s'agit de te demander d'implanter les fonctions de l'autre DLL dans KGF !!
C'est encore plus simple comme çà non (humour...)

Laurent a écrit:

Très bien Klaus mais si l'on souhaite utiliser une autre DLL en même temps que KGF (enfin de veux dire de manière alternative soit l'une soit l'autre) comment doit on procéder ? Y a t'il une manière de faire particulière ?

Peut-être aussi d'utiliser DLL_OFF juste avant le nouveau DLL_ON...

A+

Citation :

Peut-être aussi d'utiliser DLL_OFF juste avant le nouveau DLL_ON...

Certes - oui ! Mais sache que les informations mémorisées dans KGF.dll sont alors perdues. Si tu n'en as plus besoin - pas de problème. Sinon, tu es coincé. Cela concerne l'image interne des fonctions de gestion d'image, les objets tels que MaskEdit, DateTimePicker, Synedit, RichEdit, TabOject, Grid etc, ainsi que les divers systèmes de gestion de fichiers (ISAM, Cheetah, fichiers binaires, BDR) et certaines autres fonctions. Donc, il faut bien savoir ce que l'on veut, avant de quitter KGF.dll !

EDIT

Ce problème est comparable à l'exécution d'un autre source Panoramic par CHAIN, qui de son côté, reviendrait sur le code initial par CHAIN également. On ne peut pas préserver les fichiers ouverts à travers un CHAIN, ni les variables ou les objets Panoramic avec leur contenu. Il s'agit du même genre de contrainte technique.

Oui, c'est très clair.

A+