Proposition pour Klaus

Bonjour Klaus.

La SUPER HYPER KGF.DLL est devenue si énorme que personnellement (et je pense qu’il y a bien d’autres) je n’arrive plus à suivre son évolution qui est  plus rapide que ce que je peux digérer !

Dès que je me mets à jour, je m’aperçois qu’une nouvelle version (parfois deux) est déjà sortie.

Je te propose de :
• Finaliser et clore cette DLL et que tu ne la modifieras que pour apporter une éventuelle correction ou amélioration.
• Créer une autre DLL dont tu trouveras bien un nom où tu introduiras tes nouvelles créations DLLiènnes.  

Je pense que de cette façon, on pourra mieux te suivre et que tu te faciliteras la tâche pour la maintenance de la documentation etc.
Il va sans dire (mais il va mieux en le disant) que tu restes seul maître de ce que tu fais.


Je me demande ce qu'en pensent les autres?

A +

Hum, je dois avouer que je suis assez d'accord... à la base, je sais que l'idée était de n'avoir qu'une DLL pour simplifier la vie des programmeurs, faciliter la gestion et éviter d'avoir à fermer / ouvrir les DLL à tout bout de champs et pour faciliter les maj pour klaus.
On avait sans doute sous estimer la puissance de travail de Klaus ...
Il faudrait peut être du coup réfléchir à l'organisation. Mais bon, c'est Klaus qui voit, il ne faudrait surtout pas que ça le gène dans ces ajouts de fonctions qui nous permettent de réaliser des choses sur lesquelles nous aurions était bloqué.
D'un autre sens, il faudrait voir ce que fera Jack quand il aura fini le compilateur. Il semblait intéressée pour intégrer une partie de ce qu'avait fait Klaus directement dans Panoramic (si je ne déforme pas ses propos).
En effet, si tel était le cas, la Klaus pourrait désenfler des parties intégrées.
Sinon, il faudrait peut être garder un KGF.DLL pour les fonctions diverses et les fonctions "vitales" et (re)faire des DLL spécialisées dans des domaines précis. A Klaus de voir, en tout cas Klaus continue, tu le sais bien sûr, mais ce que tu fais est vraiment super pour nous tous

Au départ, c'était ma conception: plusieurs petites DLLs, chacune dédiée à un aspect particulier.

Mais il y a un problème/ Panoramic ne sait ouvrir qu'une seule DLL à la fois !

Et dès qu'on veut ouvrir une autre DLL, il faut permer la DLL actuellement ouvertr. Et cela pose 2 problèmes de programmation très concrets:
1. il faut tenir trace le la DLL ouverte pour pouvoir la réouvrir, lorsque subitement on a besoin d'une fonction résidant dans une autre DLL. Pas simple, si ce besoin survient dans une routine évènement, qui lui-même peut être interrompu par un autre évènement voulant ouvrir une 3ème DLL, ou se servir d'une fonction contenue dans la première...
2. certaines fonctions de KGF.dll ne sont pas tout à fait indépendantes et autonomes. Elles mémorisent des informations dans des variables internes à la DLL, pour les réutiliser lors d'un appel ultérieur ou pour les mettre à disposition d'autres fonctions de KGF.dll. L'exemple le plus récent est la Toolbar: la fonction CreateToolbar crée une Toolbar et la place à l'écran, gardant de façon interne toutes les références pour pouvoir la gérer. Ensuite, la fonction AddButtonToToolbar permet d'ajouter des boutons à la barre existante. Et la fonction ModifyToolbar permet de faire varier certains attributs de cette barre. Si l'on ferme KGF.dll entre CreateToolbar et ModifyToolbar, par exemple, la fonction ModifyToolbar ne saura plus qu'une Toolbar a été créée et ne pourra pas faire son travail. Pire, cela provoquera certainement un plantage par violation de mémoire, car les objets Windows injectés dans le programme Panoramic ne peuvent plus être gérés. Le crash aura lieu au plus tard lors de la fermeture du programme Panoramic, mais certainement déjà avant, lors d'un clic sur un des boutons de la Toolbar, car la routine évènement associée est une routine Delphi logée à l'intérieur de KGF.dll, et lors d'un nouveau chargement de cette DLL, les adresses ne correspondent plus.

Des exemples comme ça, il y en a plein, dans KGF.dll. Les fonctions d'impression, d'interception de clics, les objets MaskEdit, ValueListEditor, DateTimePicker etc auront tous ce même problème, et la liste n'est pas exhaustive.

Techniquement, il n'y a que deux solutions:
1. faire une grande DLL unique dans laquelle tout réside - c'est la situation actuelle depui la version
"V1.11 08/08/2012 Début de réintégration des DLLs individuelles"
2. modifier Panoramic pour permettre l'usage de plusieurs DLLs simultanément - je ne pense pas que ce soit dans les cartons de Jack

Il y a un cas particulier: c'est BDR.dll. C'est une DLL indépendante, et elle le restera. On pourra l'utiliser sans KGF.dll, au choix directement ou via l'interface BDR_SUB.bas. Mais j'ai fait l'effort de rendre BDR.dll accessible à travers KGF.dll. Ceci se fait par des procédures dans KGF_SUB.bas qui ont le même nom et la même syntaxe que les procédures de BDR_SUB.bas, mais qui utilisent de façon interne le mécanisme de chargement dynamique de DLLs qui est implémenté par les 4 fonctions suivantes de KGF.dll:
LoadDLL = charger une DLL en mémoire
UnLoadDLL = décharger une DLL de la mémoire
TargetDLL = cibler une fonction d'une des DLLs chargées en memoire
CallDLLx = exécuter la fonction ciblée avec x paramètres
C'est effectivement possible, mais la mise en oeuvre est complexe. C'est pourquoi je l'ai intégré dans KGF_SUB.bas, mais je ne conseille pas d'utiliser cette technique directement dans un programme Panoramic - trop complexe.

Et puis, un autre aspect: la documentation. Je fais un effort vraiment énorme pour produire une documentation complète et à jour de l'ensemble des fonctions de la DLL, y compris le travail de finalisation de la traduction en anglais qui est actuellement en cours. Si je dois rediviser tout cela en deux ou plusieurs sous-ensembles, ce travail augemntera considérablement. Personnellement, je préfère consacrer mon temps à améliorer des fonctions existantes ou en ajouter d'autres plutôt que de faire de l'intendance.

Vous voyez, la structure actuelle est basée sur de vraies raisonnements techniques. Ne vous laissez pas rebuter par "l'avanche" des versions qui se succèdent. Chaque fois, la documentation est actualisée, et elle est bien structurée. Je la fournis en version CHM que je conseille à tout le monde: petite, rapide, facile à utiliser pour qui connait le mécanisme d'ai de de Windows. Il y a aussi une version DOC (format Word 2003) et une verion PDF. Ces deux versions sont essentiellement fournies pour ceux qui ne sont ni francophones ni anglophones, afin qu'ils puissent utiliser un traduceur automatique (pas Goofle, par pitié, mais plutôt Reverso ou similaire) afin d'avoir une première ébauche dans leur langue.

Bonjour,
Avant de répondre j'ai voulu me remettre dans le bain, car moi aussi j'avais envi de parler du problème de kgf, et je m'en suis gardé pour ne pas froissé Klaus, avec tout le travail qu'il fait, et bien souvent à notre demande.

Ce qui me gène le plus, c'est kgf_sub. J'apprécie pas cette sub, qui est énorme à mon goût pour l'utilisation généralement d'une fonction. Je préfère carrément utiliser les fonctions directes de kgf.

Je m'étais posé la question ces derniers jours, si qu lieu de kgf_sub, ce ne serait pas plus simple d'avoir un petit programme qui, en retour d'une liste, prépare directement le code à intégrer, avec peut-être des lignes d'aide.

J'ai ouvert kgf.chm, chose que je n'avais ps fait depuis un moment, et finalement, cela fait un peu ce que je propose: on clique sur un choix, et on copie le code qui va avec. Je l'ai fait sur une fonction que je n'ai jamais utilisé, et ça a marché.

Je pense que c'est nous qui devront évolué, et faire un effort pour nous adapter à une chose qui ne peut pas être simple vu le peu de possibilité qui s'offre à nous.

Il y a une chose que je regrette, c'est une commande qui nous dit si une dll est ouverte ou non. Car comment faire pour un #include qui est diffusé? Est qu'une dll est ouverte ou non? Si on veut développer un #include devant utiliser une dll, utilise t-on les mêmes variables, entre l'#include et le programme qui l'appelle? Est-ce res%, resultat%,hdn%,handle%...

Il y a une approche commune a avoir Mais devant l’immense tâche de Klaus je me vois mal lui demander de faire un effort.

Une chose maintenant, à moins d'en avoir été le demandeur, je ne me préoccupe pas du travail en cours, jusqu'à ce les derniers ajouts soient au point. Je ne peux pas continuellement aller faire du téléchargement, et de l'installation, alors que je ne trouve pas déja de temps pour moi. Il faut être disponible pour cela. Je dis seulement ce que j'aurai aimé, c'est d'avoir sur un clic dans une liste clairement expliquée de la fonction a utilisé, le recopie du code dans le presse-papier pour le recopier, ou un programme avec en face de chaque fonction, un bouton:check pour insérer les codes à utiliser. Mais c'est surement un gadget.

@Cosmos70:
J'ai lu attentivement ta contribution, et je comprends bien tes hisitations par rapport à KGF_SUB.bas.

Ce module, comme tu l'as bien dit, nest absolument pas nécessaire pour utiliser KGF.dll. C'est juste une option différente, et ce n'est ni mieux ni moins bien que d'utiliser directement la DLL. C'est simplement une question de préférence personnelle.

Personnellement, je préfère une syntaxe comme celle des procédures contenus dans KGF_SUB.bas. Cela ressemble fortement aux commandes de Panoramic, si l'on fait abstraction des parenthèses qu'il faut mettre autour des commandes. Mais c'est ce que j'ai trouvé de mieux pour m'approcher de ce qu'on pourrait appeler une extension des mots-clé Panoramic.

Il y a cependant quelques (rares) points où KGF_SUB.bas est indispensable.

Le premier est, comme je l'ai mentionné dans mon post précédent, l'utilisation de BDR.dll conjointement avec KGF.dll. Certes, on peut faire manuellement ce qui est fait dans ces procédures. Mais ce n'est pas intuitif, et une erreur de programmation est vite arrivée. Avec les procédures de KGF_SUB.bas, c'est différent: après ouverture de KGF.dll, on peut librement accéder aux deux DLLs, en suivant la doc et les recommendations pour BDR.dll bien sûr.

Le second est la gestion des fichiers binaires et des enregistrements à longueur fixe. C'est un outil très puissant, mais cela nécessite une définition des enregsitrements avec une certaine rigueur ce qui serait vite décourageant sans ces procédures très simples et intuitives qui font tout le travail à notre place.

Et une dernière raison, pour laquelle j'ai créé KGF_SUB.bas: c'est la lisibilité du programme. Je ne peux pas m'empêcher de trouver

Code:

hint$ = "afficher la photo"
 icon$ = "KGF_1"
 res% = dll_call4("AddButtonToToolbar",1,0,adr(hint$),adr(icon$))

beaucoup moins lisible que

Code:

AddButtonToToolbar(1,0,"afficher la photo","KGF_1")

Mais là encore, il s'agit d'une affaire de préférence personnelle. Et les goûts et couleurs...

Et pour finir, quelques mots sur la taille de KGF_SUB.bas. Certes, cela fait quelques 3000 lignes. Mais dans l'exécutable généré, cela représente bien peu de choses par rapport au reste, surtout Panoramic qui est inclus dans l'EXE. Et puis, il me semble avoir vu sur le forum un outil qui prend un fichier Panoramic en entrée, identifie les SUB, les présente dans une combo ou une list, et permet d'en récupérer le source lors d'un clic sur le nom. Un outil parfait pour ce que tu suggères.

Je peux même aller plus loin: je pourrais facileent concevoir un bouton injecté dans l'éditeur de Panoramic qui fait exactement ça et qui insère le texte de la procédure à l'endroit où est le curseur...

Citation :

Je peux même aller plus loin: je pourrais facileent concevoir un bouton injecté dans l'éditeur de Panoramic qui fait exactement ça et qui insère le texte de la procédure à l'endroit où est le curseur...

J'y ai déjà pensé à cela. Mais je ne suis pas là dessus.

Cela est à tester. Mais je suis vraiment sur autre chose. Mais j'aime pas demander des trucs comme cela pour le fun. Je ne suis pas sur KGF, mais si cela intéresse les autres et que ça ne prend pas trop de temps. Là c'est toi qui voit.

Dans mes loader, j'ai des principes d'injecter du code et c'est bien pratique.

Comme je l'ai déjà dit, il faudrait avoir une commande pour savoir si une dll est ouverte ou non, pour le cas qu'on récupère des includes, et on ne sait pas si c'est déjà dans la structure d'un code.

 

Actuellement, Panoramic ne donne aucun moyen de savoir si une DLL est ouvertr ou non, et éventuellement quelle DLL, le cas échéant. Seule solution: définir une variable globale dans le programme genre DLL_actuelle$ dans laquelle on mémorise le nom utilisé pour DLL_ON, et effacer le contenu de cette variable au moment où l'on fait DLL_OFF.

Tiens, volilà un petit code fait ce soir, juste pour voir ce que ça donne. Ce programme affiche une combo contenant à ce jour lea noms des 3 fichiers bibliothèques de macros de mon cru:
KGF_SUB.bas = interface pour KGF.dll
BDR_SUB.bas = interface pour BDR.dll
KGF_OBJ.bas = création automatisée d'objets Panoramic

La liste est configurée dans le code du programme, et les chemins d'accès sont à adapter, comme d'habitude. Cela se passe dans la procédure "constantes()".

Lorsqu'on sélectionne une des 3 bibliothèques, la liste des procédures de cette bibliothèque s'affiche dans une combo en-dessous, ainsi que le nombre de procédures de cette bibliothèque.

Losqu'on sélectionne une des procédures de cette deuxième combo, son source s'affiche dans un mémo en-dessous. Là, il est modifiable si besoin est.

Enfin, un clic sur le bouton "Insérer" en bas place ce code dans le presse-papier, d'où il peut être inséré n'importe où, dans un source dans l'éditeur de Panoramic, par exemple. Ceci peut être un moyen simple d'extraire n'importe quelle procédure.

En entrée, cela peut être n'importe quel fichier source Panoramic, à condition de répondre à deux critères simples:
1. la commande SUB doit commencer en colonne 1 d'une ligne
2. la commande end_sub doit commencer en colle 1 d'une ligne
Aucune autre restriction

Voici le code:

Code:

' insertion_procedure.bas

labels()
constantes()
variables()
form0()

KGF_initialize(dll$)

end

sub labels()
  label choix_bibliotheque, choix_macro, inserer
end_sub

sub constantes()
  dim KGF$ : KGF$ = "KGF_SUB.bas"
  dim BDR$ : BDR$ = "BDR_SUB.bas"
  dim OBJ$ : OBJ$ = "KGF_OBJ.bas"
  dim dll$ : dll$ = "KGF.dll"
end_sub

sub variables()
  dim no%, no_liste_biblioth_ques%, no_bibliotheque%, no_macros%
  dim no_nombre_macros%, no_code%
  dim f$, s$, m$, i%
end_sub

sub form0()
  width 0,700 : height 0,600
  xDlist()
    no_liste_biblioth_ques% = no%
    item_add no%,KGF$
    item_add no%,BDR$
    item_add no%,OBJ$
  xAlpha(20,20,0,10,"Bibliothèques:")   : ' (t%,l%,p%,s%,s$) :
  xCombo(20,120,0)                      : ' (t%,l%,p%)
    no_bibliotheque% = no%
    on_click no%,choix_bibliotheque
    item_add no%,file_extract_name$(KGF$)
    item_add no%,file_extract_name$(BDR$)
    item_add no%,file_extract_name$(OBJ$)
  xAlpha(20,290,0,10,str$(count(no_bibliotheque%))+" bibliothèques")   : ' (t%,l%,p%,s%,s$) :

  xAlpha(50,20,0,10,"Macros:")          : ' (t%,l%,p%,s%,s$) :
  xCombo(50,120,0)                      : ' (t%,l%,p%)
    no_macros% = no%
    on_click no%,choix_macro
  xAlpha(50,290,0,10,str$(count(no_macros%))+" macros")   : ' (t%,l%,p%,s%,s$) :
    no_nombre_macros% = no%
    
  xMemo(80,20,600,400,0,1,1)  : ' (t%,l%,w%,h%,p%,bh%,bv%)
    no_code% = no%
    
  xButton(510,20,120,0,"Insérer")        : ' (t%,l%,w%,p%,c$)
    on_click no%,inserer
end_sub

choix_bibliotheque:
  cursor_hourglass 0
  cursor_hourglass no_bibliotheque%
  f$ = text$(no_bibliotheque%)
  clear no_macros%
  clear no_code%
  file_open_read 1,f$
    while file_eof(1)=0
      file_readln 1,s$
      if lower$(left$(s$,4))="sub "
        s$ = trim$(mid$(s$,4,len(s$)))
        s$ = left$(s$,instr(s$,"(")-1)
        item_add no_macros%,s$
      end_if
    end_while
  file_close 1
  caption no_nombre_macros%, str$(count(no_macros%))+" macros"
  cursor_default 0
  cursor_default no_bibliotheque%
  return

choix_macro:
  m$ = text$(no_macros%)
  file_open_read 1,item_read$(no_liste_biblioth_ques%,item_index(no_bibliotheque%))
  while file_eof(1)=0
    file_readln 1,s$
    if lower$(left$(s$,4))="sub "
      if instr(s$,m$)>0
        clear no_code%
        for i%=1 to 99999
          item_add no_code%,s$
          file_readln 1,s$
          if lower$(left$(s$,7))="end_sub"
            item_add no_code%,s$
            file_close 1
            return
          end_if
        next i%
      end_if
    end_if
  end_while
  file_close 1
  return
  
inserer:
  ClipboardCopy(handle(no_code%))
  message "Le code est placé dans le presse-papier !"
  return


#INCLUDE "KGF_SUB.bas"
#INCLUDE "KGF_OBJ.bas"

P.S. KGF_SUB.bas et KGF_OBJ.bas sont sur mon WebDav, dossier DLLs\KGF_SUB