Je suis un peu perdu...

bonjour

Absent depuis des lustres, je reviens et lis tous les messages...


Quand je regarde ce que produit Klaus, je reste sans voix.(et ne comprends pas tout.)

Félicitations ! Je me demande quand tu prends le temps de dormir...

Et du coup j'ai une question.

Que doit on posséder aujourd'hui pour rester dans la course.

Quel version de Panoramic, de KGF dll ,bas , IDE, PPE etc.
Je suis allé voir sur vos sites mais n'ai pas su quoi récupérer.
De plus comme une version sort tous les jours (ce qui fait preuve d'une belle vitalité) +
où trouver en une fois tous les téléchargements qui vont bien ?

Le sujet a dû être évoqué, mais quand je fais une recherche via le petit module à gauche, je ne trouve rien...

Donc merci pour vos réponses.

Pour Panoramic:
V0.9.25i9 du 22/12 2013

Pour mes logiciels:
KGF.dll V2.89 du 01/03/2014
KGF.chm (la doc correspondante)
KGF_SUB.bas
KGF_OBJ.bas
On trouve ces modules sur mon site, page Externes
ou sur mon WebDav (lien et identifiants dans la signature de ce post)

KGF_wizard.exe
KGF_wizard.txt
IDE.exe V1.0.27 du 25/02/2014
IDE.chm
Diaporama_inc.bas
test_Disporama.bas
sur mon WebDav

PPE est de Ygeronimi, et c'est disponible sur son WebDav (lien et identifiants dans la signature de chacun de ses posts).

Pour PPE, c' est l' acronyme de "Personnal Panoramic Editor".

Celui ci est l' essai de ma part de faire un éditeur Panoramic en
Panoramic avec l' aide considérable de la dll de klaus et de lui même.

Le dossier en entête de mon webdav est le dernier à jour.
Pas tout n' est parfait mais cela évolue avec le temps... 

Rassure-toi Maelilou, tu n'est pas le seul à être perdu.

Je suis actuellement à l'étranger, loin de mon domicile et à chaque fois que je regarde le forum, il y a des nouveautés que je n'ai pas le temps de décortiquer.
Comme tu as pu le constater, j'ai fait une pose dans le développement de PANORAMIC, mais je vais essayer quand même de sortir une nouvelle version officielle.
Le compilateur a avancé et je vais bientôt le mettre à jour sur le Webdav.
D'autre part, j'essaye de faire avancer PANORAMIC pour ANDROID, mais c'est difficile, ANDROID ne se comportant pas du tout comme WINDOWS.

J'avais le projet d'intégrer les DLL de Klaus dans PANORAMIC pour qu'on puisse utiliser ses fonctions en natif, mais Klaus a une telle production que je remet ce projet à plus tard.

Je suis actuellement sur un gros projet dans le monde fascinant du GPS (cartographie, enregistrement/rejeu de tracé, aides à la navigation, évitement d'obstacles, ...) qui me prend tout mon temps. Mais je vais bientôt refaire surface pour continuer PANORAMIC.

@Jack:
Je peux facilement faire des extraits par thème, présentées sous forme de DLLs indépendantes, chacune avec ses sources et son projet Delphi. En fait, KGF.dll est la fusion de plusieurs petites DLLs, parfaitement indéêndantes les unes des autres. J'avais fusionné le tout simplement pour me faciliter la vie, au niveau de la maintenance de l'ensemble, et au niveau de la documentation (ce qui représente un boulot énorme, tu le sais bien).

C'est clair que les fonctions de la DLL de Klaus peuvent être intégrées par thème / version de Panoramic.
Intégrer l'ensemble d'un coup serait assez costaud à faire, je pense. En tout cas, ça promet plein de bonnes choses encore à venir

Ben çà alors, on a même réussi à perdre Jack...

   

C' est vrai que KGF avance à une vitesse vertigineuse et ce n' est pas pour me déplaire.
Deux outils complémentaires et simples à prendre en main avec, en plus,
l' aide en ligne de Klaus...

...c' est génial...

Je me demande si Klaus, tu ne devrait pas conclure KGF en finalisant les derniers trucs en cours. Cela permettrait à Jack d'intégrer celle-ci dans Panoramic. Il suffirait de la reprendre sous un autre nom pour continuer à s'en servir, et peut-être refaire une version (en réserve) avec un point de départ sur les nouvelles fonctions qui serait une dll comme kgf en complément du nouveau Panoramic qui aurait inclut  les anciennes fonctions de kgf.
(J'spère d'être clair)

Oui, tu es clair, Cosmos70.

Je vais attendre un feed-back de Jack pour choisir une orientation. L'intégration de ces fonctions n'a un sens que si elles sont accessibles sous forme de commandes pour les fonctions qui ne retournent pas explicitement une valeur précise, ou sous forme de fonctions intrinsèques pour celles qui retournent une valeur, qu'elle soit entière ou chaîne de catactères.

J'imagine par exemple que Jack me prescrive une certaine interface à respecter, et que KGF.dll (ou l'éclatement en plusieurs DLLs par groupes de fonctions) sera intégré dans Panoramic sous forme d'un fichier ressource - ce serait peut-être la solution la moins contraignante pour Jack. Mais c'est juste une supposition, car je n'ai aucune idée de la façon dont Panoramic est réalisé en interne.

Les deux gros morceaux que j'aimerais voir en Panoramic en mode natif, c'est la gestion des impressions et la gestion des fichiers binaires avec la gestion des enregistrements de longueur fixe. Cela pourrait donner naissance à des commandes du type:

Code:

dim_record clients$
  code_client%                    : ' un entier sur 4 octets (4 étant par défaut)
  nom_client$[40]                : ' une chaîne de 40 caractères
  type_client%[1]                : ' un entier sur 1 octet
  remise_client                    : ' un flottant
  code_postal%[4]                : ' un entier sur 4 octets
end_record
...
' ouvrir mon fichier client avec code_client% comme clé d'accès
FILERECORD_OPEN_READ 1,client$,code_client%,"Mon_fichier_client" 
' lit enregistrement no 17 di fichier client
FILERECORD_READ 1,client$,17 
' rechercher l'enregistrement client dont le code client contient la valeur de code_client%
FILERECORD_FIND 1,client$       
...

Car tout ça, c'est possible avec les fonctions actuelles !

J'aurai aimé, même si je ne peux faire ce que je veux maintenant, dans le cas où tu bloquerais kgf, c'est d'avoir une fonction on_key_up (ou similaire sur RE, dans le cas où c'est possible. J'aurai préféré utilisé cette instruction à la place de on_change. Maintenant si cela peut se faire, il faut aussi pouvoir désactiver, pour ne pas en étant sur un memo en exemple, écrire sur RE. C'est un problème que j'avais avec AutoIt.
Si c'est pas possible, je regarderai avec l'équivalent de dir_change. Maintenant si tu ne bloques pas kgf, il n'y a pas urgence.

@Cosmos70:
En fait, tu voudrais avoir un évènement ON_KEY_UP, pas une fonction ON_KEY_UP(), n'est-ce pas ?

Je peux y réfléchir - ça ne doit pas être trop compliqué. Sache toutefois que l'évènement ON_CHANGE du EDIT associé à l'objet RichEdit est déclenché par l'évènement ON_KEY_PRESS du RichEdit. C'est un évènement géré par Delphi, mais non accessible directement en Panoramic. Cela correspond à un ON_KEY_DOWN suivi d'un ON_KEY_UP avec le même scancode. Et ce n'est valable que pour les touches ayant un effet sur le contenu du RichEdit, pas pour les flèches, par exemple.

Si vraiment il est important de séparer le ON_KEY_DOWN du ON_KEY_UP, je peux faire quelque chose, néanmoins.

Pour le moment, je ne bloque pas KGF.dll. Elle continue à évoluer. Si Jack me donne des consignes précises pour une interface à respecter, je ferai des extraits de KGF.dll avec ces extraits, en les rendant conformes à ce que Jack souhaite. Mais je laisserai KGF.dll intacte.

Citation :

En fait, tu voudrais avoir un évènement ON_KEY_UP, pas une fonction ON_KEY_UP()

J'arrive pas à comprendre la différence.
J'ai dit on_key_up, car je l'ai choisi à la place de on_key_down, mais pour un caractère ce doit-être du pareil au même. Avec un clic de souris, avec up, on peut décaler le curseur si on clique à côté, mais avec un caractère cela ne me parait pas important.
Donc on_key_press, je trouve cela très bien.

J'ai parlé de cette fonction, pour le cas où tu bloquerai kgf, mais c'est pas pour tout de suite, et moi j'ai pas le temps de rentrer dans RichEdit. Le jour venu je ferais un teste complet pour comprendre, et cela m'ennuie de demander une commande que je ne testerai pas maintenant. A moins qu'il y ait un programme qui soit opérationnel tout de suite. Donc pas de panique! 

Juste pour l'info technique:
Voici la définition de ces 3 évènements:

Code:

 procedure TForm1.FormKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState) ;
 procedure TForm1.FormKeyUp(Sender: TObject; var Key: Word; Shift: TShiftState) ;
 procedure TForm1.FormKeyPress(Sender: TObject; var Key: Char) ;

Tu vois que:

pour ON_KEY_PRESS, ty récupères le caractère frappé. C'est un caractère visible, y compris le retour charriot, ayant une influence sur le contenu de l'objet.

pour les deux autres évènements, tu récupères le scancode et l'état des touches shift, control et alt. Cela concerne toutes les touches, y compris F1, F2, ..., Page suivante, Tab etc.

En fait, tout dépend de ce que tu veux faire. J'ai fait le choix de signaler toute frappe provoquant un changement du contenu de l'objet. Si tu veux réagir à la frappe des autres touches n'ayant pas d'effet visible sur le contenu de l'objet, alors il faut effectivement choisir l'évènement ON_KEY_UP, mais il faut en plus retourner le scancode et l'état des 3 touches shift, control et alt. C'est faisable, par exemple via la création d'une nouvelle fonction:

Code:

res% = dll_call2("RichEditSetOnKeyUpEvent",RE%,adr(EDIT%))

On remplacerait alors l'évènement ON_CHANGE par l'évènement ON_KEY_UP. Et ce sera l'évènement ON_CHANGE de l'objet EDIT% qui sera déclenchée par l'évènement ON_KEY_UP du RichEdit. Cela ne présente pas de problème majeur.

Bon, voila ce que je trouve intéressant, même si je pense que cette instruction, on peut s'en passer.
En prenant en exemple le PPE de Ygeronimi, que je n'ai pas regardé pour la bonne raison que n'arrive déjà pas à regarder pour moi en ce moment, il me parait intéressant de choper les caractères qui peuvent être un séparateur comme pour le masque d'une ligne déjà conçu. Cela me parait plus simple que d'analyser toute la ligne à chaque modification. Seule les caractères qui sont concernés, portent à analyse.
Dur de trouver du temps à répondre en ce moment.

@ Cosmos70,

Je vais t' expliquer ce que fait ma coloration syntaxique en quelques mots.

A chaque fois qu' il y a un changement sur le RichEdit actif :

-1) Récupération de l' emplacement du curseur
-2) Repositionnement à positionnement un caractère en arrière
-3) Récupération du caractère tapé qui est à cette position
-4) Envoi à la fonction de sélection selon le caractère
-5) Repositionnement du curseur après ce caractère, donc en position initiale

La fonction de sélection fonctionne selon le code chr$(x%) du caractère avec un Select...Case...End_Select 
pour les codes comme Chr$(13) à la ligne,  Chr$(34) ", Chr$(32) espace, etc...(les opérateurs,les parenthèses....).
Selon le code récupéré, on effectue la ou les procédures associée. 
- Si le caractère n' est pas un séparateur, on ajoute le caractère dans une variable $ qui recompose le mots en cours de frappe.
- Si c' est un caractère séparateur on envoie la variable $ vers la fonction de colorisation, on stock le mot dans une autre variable $ pour le cas d'un retour en arrière ( fonction à perfectionner ). On initialise la variable $ du mot en cours

La colorisation se fait sur des mots-clef placés dans des listes
si le mot est dans une des listes, il prend la couleur réservé à celle ci.

Tout ceci se fait via les fonctions de KGF.dll et c' est assez rapide pour ne pas "bugguer"

J' espère que ma littérature est assez clair pour être comprise...  ,
si ce n' est pas le cas n' hésites pas à me rappeler.

En lisant les différents postes que tu as mis, c'est ce que j'avais compris.
Pour ma part, je pense qu'i n'est pas nécessaire de faire tout cela. C'est mon point de vue et cela ne me donne pas forcément raison. J'estime qu'il n'y a à ce préoccupé de la colorisation qu'en vue de l'appui sur certains caractères qui disent que maintenant, il faut contrôler, comme un deux-points, un espace, une parenthèse, etc...
C'est d'ailleurs ce que j'ai testé avec RE d' AutoIt pour faire un essais d'éditeur. Mais AutoIt est encore moins rapide que Panoramic, et je pouvais pas continuer sur la colorisation directe.

Mais n'ayant testé ton programme, je ne peux entrer dans une critique. Je prend juste le temps de lire le forum en ce moment, sans plus.

Le "Select" ne porte pas sur tous les caractères.
Il porte sur :

chr$(32) - espace
chr$( 8 )   - retour arrière

et les caractères suivant :

' ( ) + - * / = " 

et j' ai des listes de mots :

variables
label
mots clef Panoramic
Procédures

Si tu prends ne serait ce que les parenthèses, tu entres dans un casse tête sans nom   .
Tu as plusieurs cas :

- opérateur ( lors d' une équation )
- ou sur un mot clef ( ex: text$(N) )
- ou procedure (ma_sub())

Puis tu as les cas :

dans une chaine de caractères
dans un commentaire

et, après, tu as la fermeture de parenthèses qui doit être de la couleur de l' ouverture...

et à la fin tu deviens                        

Pour ce qui est des parenthèses, je n'ai pas l'intention de coloriser ceux-ci. Je préfère faire un outils comme j'ai déjà montré une fois, avec une numérotation de ceux-ci. Les couleurs différentes ne sont pas toujours évident. On peut-être daltonien (je sais que Klaus n'a pas besoin de mes programmes, il est top fort pour moi), mais personnellement pour les détails, ma vue n'est plus au top, et je dois regarder un peu plus gros, et en gras.
Je ne sais pas si cela va marché avec le lien suivant:
teste coloration
C'est un lien provisoire car celui-ci est dans un dossier qui sera effacé, et repris.
Cela marche chez moi, mais je suis branché. C'est une colorisation html, mais pour cela je ne m'occupe pas des variables et autres, mais je pars sur ce principe.

Dans PPE2 

les parenthèses ont chacune leur couleur.

mots clef
Opérateur
Procédure
chaine de caractères
commentaires

ces couleurs sont modifiables dans les paramètres utilisateur.
Si le texte n' est pas assez gros, tu peux régler la taille aussi.