Editeur avec marquage syntaxique

@Cosmos70 et Jicehel:
J'ai place KGF_32.dll dans le dossier Synedit du WebDav. C'est une version spéciale, juste pour tester si l'aide en ligne est opérationnelle sur un système 32 bits. Vous voulez bien faire l'essai ?

Je ne suis pas en version 32; mais 64. Je crois que Minibug a une version 32.

Si Minibug ne test pas d'ici là, je testerais en rentrant à la maison (et après avoir mangé car tout le monde m'attend pour commencer ) => Donc résultat du test vers 21H ce soir

@Jicehel:
C'est ta remarque

Citation :

A priori, l'aide marche sur les OS en 64 bits mais on a une vilation d'accès pour les OS en 32 bits (je dis bien à priori).

qui m'a fait citer ton nom pour ce test. Désolé.

Et tel que j'ai fait cette version de test, elle devrait marcher de toutes façon sur un système 64 bits (à vérifier donc - chez moi, sous W8.1 64 bits, ça marche), et il y a une chance que ça marche soru un système natif en 32 bits.

Bonjour Klaus.

Je ne pourrais tester que ce soir car le seven 32 est chez moi et là je suis encore au travail !

Je te donne des nouvelles dès que possible...

Il n'y a aucun problème Klaus, vu le temps que tu consacres à ce projet qui devrait tous nous faciliter la vie, on peut bien te consacrer quelques minutes.
Nous ce que l'on a à faire, c'est renommer notre KGF.DLL en KGF.SAV
Télécharger KGF_32.dll et le mettre dans le dosssier sous le nom KGF.DLL
Tester et te faire un rapport
(Après on laisse cette version de la DLL ou on la supprime et on renomme notre KGF.SAV en KGF.DLL ?)

CA MAAAAARCHE !!!!!!

Bravo Klaus, tu as résolu le problème.

La dll KGF_32.dll fonctionne parfaitement. J'ai bien validé le chemin et là ca fonctionne.
J'ai ensuite retenté de mettre le KGF.dll et là bug de nouveau.

Bravo pour ta ténacité !

Je confirme, le problème était bien là. Ca marche bien sur Vista avec KGF_32.DLL renommée en KGF.DLL

@Klaus :
Maintenant que le problème est trouvé, pourrais tu stp nous expliquer d'où ça vient si cela n'est pas trop complexe ?

C'est vrai que c'est surprenant ce problème, alors que jusqu'à présent KGF fonctionne indifféremment sur 32 et 64 bits. Tous systèmes confondus.

PS : pourra t on encore utiliser la même dll KGF ou bien tu vas développer 2 systèmes différents 32 et 64 bits ?

Dans un programme de teste sur une idée, j'ai trouvé un problème.
J'ai appuyé sur nouveau pour commencé un programme

Je me suis aperçu que 2D_CIRCLE n'était pas colorisé. J'ai voulu ouvrir les options de la page (j'ai vu après coup que c'était syntaxe) et j'ai été bloqué:


De plus il n'y a aucune sauvegarde apparemment. Le bouton Arrêter fait son travail, moi je l'avais demandé justement pour pouvoir récupérer un programme lors d'un blocage, et c'est d'ailleurs pour cela que j'avais parlé: à partir d'une dll ou Synedit, car si Panoramic est bloqué, il n'y a plus rien à faire pour récupérer. Dans le cas présent c'était un début de programme avec quelques lignes.

@Minibug:
Je produirai bien sûr une DLL qui marchera indifféremment sur des systèmes 32 ou 64 bits. D'ailleurs, la fameuse KGF_32.dll est déjà dans cette situation... Je vais juste le faire d'une façon un peu plus propre, et tout générer avec un nouveau numéro de version.

Alors, l'explication:

L'accès à l'aide contextuelle est fait par un contrôle ActiveX nommé hhctrl.ocx. Ce contrôle est fourni gratuitement par MicroSoft, et fait partie du toolkit de développement de l'aide HTML de MicroSoft.

Or, MicroSoft donne, dans sa documentation, des codes en langage C pour gérer ce contrôle. Et je ne suis pas très fort pour convertir du C en Pascal/Delphi. J'ai donc fait appel à des modules en Delphi, provenant de SourceForge.

Mais là, il y a un problème. En fonction de la version du système et de la version de Delphi, le programme génère un code différent, et qui pose problème dans nos configurations variées. En effet, pour certaines versions, le programme (fourni par SourceForge) va chercher une clé dans le registre Windows pour en extraire le chemin vers le fameux fichier OCX. Et cette clé registre dépend de la façon dont le fameux toolkit de MicroSoft a été installé. Et dans certains cas, la valeur trouvée soit n'existe pas, soit est aberrante pour notre cas de figure.

Alors, j'ai introduit quelques lignes, juste devant le traitement en question.
Je vérifie d'abord si "C:\Windows\SysWOW64\hhctrl.ocx" existe. Si oui, on est dans un système 64 bits, et je prends ce fichier-là qui est la version 32 bits sous un système 64 bits.
Si ce fichier n'existe pas, je vérifie si "C:\Windows\System32\hhctrl.ocx" existe. Si oui, on est dans un système 32 bits et ce fichier-là est donc forcément la version 32 bits.
Et si ce fichier n'existe pas, je laisse le traitement se dérouler, tel qu'il a été imaginé par SourceForge.

Cela donne le code suivant:

Code:

const hhPathRegKey = 'CLSID\{adb880a6-d8ff-11cf-9377-00aa003b7a11}\InprocServer32';
 
{ Returns full path to hhctrl.ocx.
  Returns empty string if file or registry entry not found.
  Note: hhctrl.ocx may not be in the path. Consider the case where
        the ocx has been downloaded to the windows ocx cache via the net.
        So.. best to get the path from the registry.
  Note: Delphi 2 and 3 do not support reg.OpenKeyReadOnly()
        and to access the registry as RW mode under NT (as non admin user) will cause
        an access violation. Best to simply return the ocx path to system folder.
        In 99.9% of cases this will be correct.
}
function GetPathToHHCtrlOCX: string;
{$IFDEF D4PLUS} // -- Delphi >=4 ------------
var Reg: TRegistry;
{$ENDIF}
begin
{$IFDEF D4PLUS} // -- Delphi >=4 ------------
  result := 'C:\Windows\SysWOW64\hhctrl.ocx';       // KGF1 patch to force 32 bit version under 64 bit systems
  if FileExists(result) then exit;                  // KGF1 if file exists, we are happy...
  result := 'C:\Windows\System32\hhctrl.ocx';       // KGF1 patch to force 32 bit version under 32 bit systems
  if FileExists(result) then exit;                  // KGF1 if file exists, we are happy...

  result := '';  //default return
  Reg := TRegistry.Create;
  Reg.RootKey := HKEY_CLASSES_ROOT;
  if Reg.OpenKeyReadOnly(hhPathRegKey) then  //safer call under NT
  begin
    result := Reg.ReadString('');  //default value
    Reg.CloseKey;
    if (result < '') and (not FileExists(result)) then  //final check - file must exist
      result := '';
  end;
  Reg.Free;
{$ELSE}         // -- Delphi <4 ------------
  Result := GetWinSysDir + '\hhctrl.ocx';
{$ENDIF}
end;

@Cosmos70:
Je vais regarder cela en détail.

@Cosmos70:
En effet, dans la définition de la syntaxe, la commande 2D_CIRCLE manquait. J'ai modifié le fichier Synedit_Editor_Syntax_Panoramic.txt dans le dossier Synedit du WebDav. Reprends-le, car le programme d'installation ne le remplacera pas. Et on pourrait aouter ce mot-clé dans la fenêtre de la syntaxe, mais j'ai constaté avec effroi que le texte se met en minuscules. Ce sera corrigé dans la prochaine version. Je prépare un gros morceau supplémentaire, mais.. chut !

Bonjour a tous !

@Klaus : Merci pour ces explications.
Effectivement, il ne faut pas se perdre entre les différentes versions et les différents systèmes.
Encore bravo Klaus.

Citation :

Je prépare un gros morceau supplémentaire, mais.. chut !

Klaus, stp dis le moi, j'te promet j'le répéterai pas...

Bonjour tout le monde.
Bonjour Minibug

Minibug a écrit:

Klaus, stp dis le moi, j'te promet j'le répéterai pas...

Eh bien,moi, je vais te le dire et satisfaire ta curiosité ;  mais comme promis ne le répète à personne !
Klaus prépare un gros morceau supplémentaire, mais.. chut !  

Merci Papydall ! Tu peux compter sur moi.

+1

Une piste: la proposition d'un mot-clé dès le début de la frappe ????

Mais bon ! c'est secret....

La proposition de mot clé ou de variables en tenant compte du mot clé en cours de saisie... Hum, ce serait en effet un gros boulot.

Et pourquoi pas la possibilité dans les options de mettre en majuscule ou minuscule les mots clé, les chaines ou les commentaires...

Et au lieu des couleurs, on pourrait choisir dans une palette comme celle que l'on a vu sur le forum il y a quelques mois (je ne me souviens plus qui !)...

bon j'arrete là !

Tu as raison Minibug, mitraillons Klaus de suggestions comme nous le faisions pour Jack.
Après, il fera c'est courses dans ce qu'il retient, ce qu'il jette, ce qu'il voudrait prendre mais ne peut pas pour des problèmes techniques et ce qui ne va pas dans le sens vers lequel il souhaite faire évoluer cet éditeur.

Question à Jack - Jack, demain, quand l'éditeur aura était encore plus testé, sera-t-il le nouvel éditeur de Panoramic et quels sont les fichiers que tu fourniras lors d'une montée de version ?

Ce n'est que mon opinion évidemment, et je ne voudrais pas jouer les trouble-fête, mais moi perso j'aimerais bien pouvoir rester sous panoramic_editor, pour sa simplicité, un seul fichier.

C'est juste une question pour savoir comment les choses vont évoluer potentiellement par rapport à la lourdeur dont parlé Jack quand il fait une MAJ de Panoramic. Il a très certainement déjà réfléchi sur ce sujet ou attend peut être de voir le comportement de cet éditeur. On verra bien sa réponse, mais tu as bien fait de mettre ton sentiment JL35.
Personnellement, je ne suis pas attaché à l'éditeur intégré, l'outil de Klaus offrant autant de possibilités. Il pourra sans doute encore être simplifié et complété, mais maintenant il est déjà opérationnel.
Il y a encore du travail à faire pour qu'il soit plus convivial mais je pense que Klaus s'y attaquera quand il aura fini de travailler sur le fond, mais je m'avance.

ATTENTION: version corrigée! On peut télécharger et tester !
Le 17/09/2014 à 15h04.

Voilà une nouvelle version:


Cette version (majeure !) apporte deux éléments importants:
1. la correction du problème d'accès à l'aide contextuelle, indépendamment de la versino 32 ou 64 bits du système
2. la gestion cohérente des identifiants spéciaux.
3. une nouvelle macro DossiersSpeciaux

La nouvelle macro s'installe automatiquement, par le programme d'installation.

Les identifiants spéciaux sont des chaînes de caractères dont chaque occurrence est remplacée par une autre chaîne de caractères, lors de l'exportation du projet en *.BAS, ou lors de l'envoi du contenu d'une page vers un outil quelconque.

A ce jour, les identifiants spéciaux suivants sont définis:
#KGF = chemin vers KGF.dll
#APP = dossier application

Le chemin vers KGF.dll est pris dans les paramètres généraux, où l'on indique à Synedit_Editor où il va trouver sa copie de KGF.dll. Et c'est cette valeur qui sera utilisée pour remplacer #KGF dans le source.

Le dossier d'application est défini dans les options de la page actuelle, et il est mémorisé avec le projet, dans le fichier *.SEproj. Ainsi, on peut configurer un dossier application différent pour chaque projet. Chaque occurrence de #APP est remplacée par cette chaîne de caractères.

Par défaut, le dossier application est "C:\SyneditApplication\".

Et voici un fichier "projet" pour montrer l'utilisation de ces identifiants spéciaux:

Code:

 DossiersSpeciaux()
 message KGFdll$+chr$(13)+chr$(10)+DossierApplication$
 terminate
 end





sub DossiersSpeciaux()
  if variable("KGFdll$")=0 then dim KGFdll$
  if variable("DossierApplication$")=0 then dim DossierApplication$
  ' charger les variables des chemins spéciaux
  KGFdll$ = "#KGF"               
  DossierApplication$ = "#APP"
 
  ' traiter le cas de KGF.dll
  if file_exists(KGFdll$)=0
    message "Fichier non trouvé: "+KGFdll$
    terminate
  end_if
 
  ' traiter le cas du dossier d'application
  if dir_exists(DossierApplication$)=0     
    label DossierSpeciauxErreur : on_error_goto DossierSpeciauxErreur
    dir_make DossierApplication$  : ' si le dossier n'existe pas, on tente de le créer
    off_error_goto
    exit_sub
DossierSpeciauxErreur:
    off_error_goto                : ' échec: on signale
    message "Impossible de créer le dossier "+DossierApplication$
    terminate
  end_if
end_sub
#$APPLICATIONPATH
C:\Users\klausgunther\Documents\Mes projets\Mes projets Delphi\KGF\Application\

Bien j'ai fait l'installation dans un autre dosier en attendant de voir si c'est ok.

Après avoir mis les paramètres, j'ai ouvert un projet déjà créé. La syntaxe de la page n'étant pas définie, j'ai voulu le faire.



Ce qui me gène, il est difficile de prendre pour l'instant l'éditeur par défaut, vu que lorsque qu'il y a un blocage, il n'y a pas de sauvegarde automatique. On ne peut juste faire que des essais. Maintenant c'est pas une vrai critique, le programme étant en fabrication, il est normal que certaines choses soient en attente. Mais justement je pense qu'il faudrait commencer par cela: une sauvegarde, ce qui sécurise le codage d'un programme, même si ce n'est que pour le premier onglet. On ne va pas au départ s'attaquer un tas de programmes à la fois tant que le programme ne sera pas fini. Ainsi on prend moins de risque pour faire des testes.

3 remarques, Cosmos70:

1. Lance Synedit_Editor, va directement dans les options générales, choisis la syntaxe par défaut, sors du programme. Lorsque tu le redémarrera, il y aura la syntaxe choisie (Panoramic ?) et ça marchera. Je vais analyser ce qui se passe si l'on change de syntaxe en cours de route. C'est un bug, c'est sûr, et je le corrigerai. En attendant, tu as le moyen de le contourner.

2. Actuellement, Synedit_Editor est en version ALpha. C'est une suite de versions de test, d'évaluation. Ce n'est pas encore conseillé en "production", comme tout logiciel en version Alpha. Pour le moment, ça sert à valider le concept, définir en collaboration avec toutes les bonnes volontés les fonctions obligatoires, souhaitées, possibles,... Le programme est cependant de pluq en plus stable. J'élimine régulièrement des problèmes conduisant à des crashs. Mais certes, il en reste encore. Le processus est long, mais avec la mise au point participative à l'aide des Panoramiciens les problèmes sont identifiés plus vite, et par conséquent éliminés plus vite que si je faisais tout ça seul dans mon coin.

3. Dans le menu Fichiers, il y a une option "Sauver" qu'on peut utiliser à tout moment. Fais-le après avoir effectué des modifs que tu veux sécuriser. C'est facile et rapide. Bientôt, il y aura des raccourcis pour ça:
ctrl/S = sauver
ctrl/O = ouvrir
ctrl/N = nouveau
ctrl/alt/S = sauver dans
etc.
Il n'y a pas de sauvegarde automatique, et je ne pense pas faire ça tant que le périmètre des fonctionnalités ne soit pas suffisamment figé.

Nouvelle version:


Nouveauté:
On peut maintenant changer la syntaxe de la page actuelle dans les options de la page, puis revenir de la même manière à la syntaxe Panoramic. Le bug est corrigé.

Et comme la capture le montre, c'est Synedit_Editor qui a changé, et non KGF.dll qui reste inchangée.