KGF_dll - nouvelles versions

De rien !

De rien !

Pour la doc, il faut dire que c'est un boulot énorme. Heureusement que beaucoup de choses peuvent se faire par copier/coller, en particulier pour ajouter de nouvelles pages. Mais les textes explicatifs, il faut les saisir, il fait établir les liens de navigation sans oublier l'énorme indexe alphabétique, puis regénérer la doc et tout redistrubuer... Tu as vu la taille du fichier CHM, déjà en l'état ? Si j'ajoutais des captures d'écran et autres effets visuels, la taille serait multiplié par 10. Je l'ai fait pour la documentation de Synedit_Editor - aussi bien la doc générale que la doc de la prise en main. C'est vrai - c'est agréable à regarder. Mais à l'échelle de KGF.dll ? Avec près de 700 fonctions ? Je devrais embaucher.

Je sais ce que c'est, je l'ai moi-même testé avec la doc de GPP.
plus de 700 fonctions, houaaaaa !!! C'est un vrai langage que tu nous a développé à toi tout seul !

Quant a embaucher, c'est notre président qui serait content ! Cela ferait du chômage en moins...

Concernant la saisie prédictive, je pense être proche du but...
Je vais faire une détection dans le texte de synedit et lorsqu'elle sera active, cela dégagera une partie de la fenêtre SYNEDIT sur la coté droite où je ferait apparaître une liste avec les mots clés.
Il faut maintenant que je mette cela en pratique...

Moi c' est cette partie qui me rebute.
D' ailleurs, c' est ce qui rend mes programmes impubliables.

@ygeronimi :
Il faut prendre son temps...

@Klaus :
Ça y est presque. Ma saisie prédictive fonctionne !



Le seul petit problème est la détection des caractères qui s’opère par la fonction SCANCODE.
Et comme le tout se trouve dans un sous programme appelé toute les 1/2 seconde, il m'arrive de perdre des caractères dans ma variable. et pourtant tout est bien affiché dans la fenêtre SYNEDIT

Je croit me souvenir que tu avais parlé de pourvoir récupérer les caratères dans les objets cachés mais je ne sais plus (pas) comment faire !!

Comment peut on contourner ce problème ?

On va faire un essai. Va chercher KGF_Synedit.dll dans mon WebDav et utilise-le à la place de KGF.dll.

Tout est identique, sauf un point précis:
Lors de la frappe de touches dans Synedit, un certain nombre sont traitées de façon interne. Si une touche est non traitée, elle est utilisée dans le Synedit de façon habituelle (insertion de caractères, suppression, ...). Cette version, en plus du traitement habituel par défaut, va envoyer un message dans le EDIT destiné à recevoir les évènements, avec le format:
cNNNxxx
c est l'identifiant du message - tu l'utiliseras pour détecter qu'il faut traiter une touche
NNN est le numéro du Synedit générant le message
xxx est le code di caractère (065 pour '"A").
Essaie de voir si c'est utilisable. Si oui, je vais "habiller" cette fonctionnalité un peu plus, en particulier donner la possibilité d'activer et désactiver cela.

Ok Klaus je te remercie.

Je vais devoir partir d'ici quelques minutes mais je regarde en revenant vers 16h30.
Et dès que j'ai testé je pose le résultat.

A tout à l'heure et encore merci.

Bon, je suis de retour...

je viens de mettre en place la DLL et j'ai modifié mon code pour récupérer l'info indiquée.
Par contre j'ai juste cNNN mais xxx n'est pas visible ?!

De plus le NNN censé m'afficher le numéro de ma fenêtre SYNEDIT n'indique à priori pas la bonne fenêtre !?
NNN indique 003 alors que pour moi c'est la numéro 1...

Oups... j'avais oublié une ligne. Maintenant, me NNN devrait être correct.

Par contre, tu ne vous pas le xxx ? Je transmets bien 7 caractères... L'objet dont le handle est précisé dans le second paramètre de SyneditCreate doit bien être un EDIT, et il est en principe capable de recevoir 7 caractères.

je vérifie de suite tout ça...

J'ai vérifié avec Synedit_Editor:

Code:

 SE%(nsyn%) = dll_call2("SyneditCreate",handle(nf%),handle(95))   : ' créer l'objet Synedit
  ' 95 étant un EDIT caché avec évènement ON_CHANGE

puis, le début de la routine ON_CHANGE:

Code:

syneditalert:                                        : ' ON_CHANGE sur EDIT no 95
  salert$ = text$(95)                                : ' EDIT 95 contient l'identifiant de l'évènement
  nalert% = instr("CHNSDOAMKEmeakdc",left$(salert$,1))   : ' déterminer le code envoyé par la DLL
  select nalert%

puis la fin du bloc SELECT avec le traitement du "c":

Code:

   case 16: ' un caractère a été frappé
      message text$(95)
  end_select
  return

Le message vien bien, puis le caractère est pris en compte dès qu'on valide le message. Donc, pour moi, tout va bien.

EDIT

Il va de soi que le "traitement" de "case 16" montré ici sert juste de preuve de l'arrivée du message. Ce n'est en rien un traitement que je laisserai dans Synedit_Editor...

désolé de te faire attendre Klaus...

j'ai eu un problème sur mon portable Suite à une mauvaise manipulation, ma cession s'est fermé et du coup je n'ai pas pu reprendre mon fichier là ou il en était juste avant.

je dois donc tout recalibrer alors que c'était pratiquement au point.
A priori j'ai bien le messages complet avec les valeurs, mais pour un test plus complet il va me falloir plus de temps.
Désolé...

Je compatis - c'est pénible de perdre des données comme ça. Ne t'inquiète pas - je ne peine pas, ici !

Ça y est c'est bon ! J'ai remis de l'ordre dans le code...

Effectivement grâce à ton intervention et la ' DLL amélioré' j'ai un meilleur résultat.

En fait maintenant, lors d'un changement sur l'EDIT (ON_CHANGE), j'oriente le travail vers une SUB qui traite la saisie et travaille sur l'affichage du LIST (mots clé) sur la partie de droite.

Je gère aussi le retour arrière (code 08) et l'underscore (code 56) utilisé dans le nom des mots clé.
Tous les autres caractères réinitialise la recherche et du coup efface le LIST.

L'ensemble fonctionne plutôt bien. Il me reste maintenant à trouver une gestion 'plus pointu' de la saisie dans la fenêtre, comme par exemple un clic au milieu d'un mot. Mais ça je vais y réfléchir...

Encore un grand merci Klaus.

Super !

Alors, maintenant, je vais "habiller" cette fonctionnalité, car elle n'ailme pas se trouver toute nue...

Nouvelle version:
KGF.dll V7.12 du 10/12/2016

Nouveautés:
- SyneditFunction: nouveau code fonction 38

Modules modifiés:
KGF.dll
KGF.chm

La doc et les sources sont à jour.

Ce nouveau code permet de gérer la création d'un évènement eNNNxxx si l'utilisateur a frappé un caractère qui n'a pas été traite par Synedit en interne. Par défaut, cette possibilité est désactivée.

Nouvelle version:
KGF.dll V7.13 du 11/12/2016

Nouveautés:
- Nouvelle fonction: ReplaceStringBetweenDelimiters

Modules modifiés:
KGF.dll
KGF.chm

La doc et les sources sont à jour.

Cette fonction fait exactement ce que fait RemoveStringBetweenDelimiters, mais en plus, ajoute une chaine de caractères à la place du texte supprimé.

Bonjour Klaus !

J'ai l'impression que la mise en place de la nouvelle fonction SYNEDIT ne marche pas correctement.

J'ai bien ajouté la ligne res% = dll_call3("SyneditFunction",SE%,38,1) à la suite de mes lignes d'initialisation de mes fenêtres SYNEDIT.

Lors du déclenchement du ON_CHANGE en tapant des caractères, je récupère seulement la chaîne Cnnn et aucun code de caractères...

Désolé - c'est corrigé. J'ai "habillé" cette option, mais j'en ai voilé la face... Chez moi, avec le banc de test, je regarde derrière le voile, et c'est pourquoi je ne m'en suis pas rendu compte. Mais c'est corrigé - j'ai relevé ce qui cachait les yeux...

Ok Klaus merci !

Je vient de faire quelques tests et tout semble fonctionner correctement.  

Je ne voudrai pas abuser mais je me posais la question concernant le déplacement des touches haut-bas-gauche-droite dans les fenêtres synedit...

Je teste mes touches par le même principe du SCANCODE dans un sous-programme par timer toutes les 1/2 seconde. Et c'est vrai que le résultat ne me convient pas totalement car j'ai des saccades et l'ensemble est mal calibré (trop lent ou trop rapide).

Crois tu qu'il serait possible d'envoyer les codes des touches de direction de la même manière que pour les caractères en mettant juste une lettre différente comme dNNNxxx (d pour déplacement). Ce qui me permettrai un traitement a part et 'immédiat' ?

Merci pour ta réponse.  

Aucun problème ! Je vais faire ça.

En fait, je n'ai rien à faire ! Tu reçois déjà ces évènements, avec le code "c" bien sûr. Mais la partie xxx représente le VK_code de la touche frappée, et c'est

Code:

 VK_LEFT  = 37;
  VK_UP    = 38;
  VK_RIGHT = 39;
  VK_DOWN  = 40;

Essaie - tu verras. Ceci concerne toutes les touches non traitées en interne(ctrl/C, crtl/W, crtl/P, ...).

J'avais pensé le faire avant même de t'en parler mais justement les touches directionnelles ne sont pas détectées

j'utilise bien ces codes : 37 , 38 , 39 et 40.
J'ai mis un affichage sur le CAPTION de SYNEDIT qui me renvoi le code complet cNNNxxx
A première vue les codes ne sont pas retournés par la nouvelle fonction.

Dans Synedit_Editor, une flèche en haut:

Pas de problème, les flèches, la gomme, tout est bien reconnu.

Voici la fain du SELECT...END_SELECT ldans le ON_CHANGE du EDIT associé au Synedit:

Code:

    case 16: ' un caractère a été frappé
      ' on a reçu un message "cNNNxxx", mais on ne le traite pas dans Synedit_Editor !
      if option_affichage_touches_recues%=1 then message "Caractère frappé: "+text$(95)
  end_select