Delphi + JavaDoc = DelphiCodeToDoc [Trucs & Astuces]

Mon sujet précédent étant parti en vacances , je me permet de poster à nouveau ce sujet.

Le titre résumé bien l'outil. Vous voulez utilisez JavaDoc avec Delphi ? Bienvenue
Vous ne connaissez pas JavaDoc ? Allez faire un tour sur le site alors ! http://dephicodetodoc.sourceforge.net/

----------------------------------------------------------------------------------
DelphiCodeToDoc v0.8Beta disponible - Outil gratuit de generation de documentation pour Delphi

La dernière version de DelphiCodeToDoc (v0.8Beta) est disponible. Elle peut être téléchargée ici :

http://prdownloads.sourceforge.net/d...b.zip?download

DelphiCodeToDoc est un outils gratuit de génération de documentation pour Delphi, distribué sous la licence GNU - GPL. Il utilise les informations contenu dans le code source, comme les symboles et les commentaires formattés, pour produire une documentation précise de votre code ou de votre composant.

Situation : DelphiCodeToDoc sort donc de la version Alpha, et passe en Beta. Il sortira en Stable (v1.0) dans les deux prochaines versions.

-----------------------------------------------------------------
Quelles sont les nouveautés de cette version ?
Cette version v0.8Beta contient les modifications suivantes :

*Ajout d'une version de DelphiCodeToDoc en ligne de commande (Tracker 997523)
*Correction des TAGs ignorés s'ils sont précédés d'un decorateur '*'(Tracker 997528)
*Correction de m'impossibilité d'analyser une expression "Cast Index" (Tracker 1000672)
*Correction du type Object qui plante l'application (Tracker 991180)
*Correction des fonctions simples qui n'ont pas leur type de retour documentés (Tracker 1010200)
*Correction du "Lien Suivant" lors de l'utilisation du filtre de visibilité sur les membres (Tracker 996611)
*Correction de la largeur des tableaux dans le code HTML (Tracker 989272)
*Correction de la traduction US (Tracker 991592)
*Mise à jour des traductions Françaises


Quels sont les bugs connus du logiciel ?
*Aucun pour le moment

Quelles sont les limitations connues du programme ?
*Les méthodes avec le même nom (surchargées) dans une classe resulterons en une seule fonction dans le rapport de sortie
*Les fonctions avec le même nom (surchargées) resulterons en une seule fonction dans le rapport de sortie
*Aucun "define" du pre-processeur ne peuvent être définis
*Les propriétés n'ont pas de description (mais sont générées)
*Les évenements n'ont pas de description
*Seul le format HTML sera généré pour la documentation
*Seul l'Anglais est disponible pour le document généré
*Le TAG @see n'est pas supporté

Quelles seront les futures évolutions ?
*Ajouter le choix de la langue pour la génération de la documentation
*Ajout d'un nouvel expert "création du projet" complet et plus estétique

Et oui c'est l'époque des vacances.

Merci d'avoir posté de nouveau.

Bonjour,
la distribution de DelphiCodeToDoc ne contient pas d'exemples sur les possibilités de l'outil ?
QQ peut-il m'en communiquer un ?

Mon objectif étant de remonter des informations de modifications de code source du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
//@comment <LD> 
//@comment Modif . Pas implémenté.
    Assert(...
//@comment  </LD>

Par avance merci.

Un exemple de code généré sur le site officiel : http://dephicodetodoc.sourceforge.ne...iCodeToDoc.htm
Cet exemple est généré à partir du sous répertoire "Extract" des sources du logiciel.

Sinon, tu as à ta disposition la documentation pdf de l'outils: http://dephicodetodoc.sourceforge.net/Download.htm

Et enfin, une doc et des exemples pour chaque JavaDoc TAG: http://dephicodetodoc.sourceforge.ne...Doc_Syntax.htm

Maintenant, par rapport à ta demande, DCTD supporte les TAG JavaDoc et les extensions Inlines. Donc soit tu utilises ce "standard" pour décrire ton code, soit ... et bien soit tu envois une demande d'amélioration par le site :)

J'espère avoir répondu à tes questions.
TridenT

Envoyé par trident_job

J'espère avoir répondu à tes questions.
TridenT

Parfaitement
Je vais regarder cela dans le détail, merci.

N'oublie pas que le logiciel vient juste de passer du stade Alpha à Beta depuis la v0.8. Il n'est donc pas encore complet.
Le "wizard", par exemple, n'en est pas vraiment un.

Cela dit, si tu as des propositions, idées d'améliorations, remarques, je suis preneur !
Et surtout, s'il ne convient pas à ton souhait, ou que tu ne l'aimes pas du tout, ca m'interresse aussi de savoir pourquoi !

Envoyé par trident_job

N'oublie pas que le logiciel vient juste de passer du stade Alpha à Beta depuis la v0.8. Il n'est donc pas encore complet.

Cela ne me géne pas, tu as au moins l'envie d'en faire quelque chose, ce qui n'est pas donné à tout le monde !

Je vais essayer de t'expliquer mon besoin et l'idée associée.
J'ai des sources de tests unitaires et j'aimerais que ces fichiers 'hébergent' la documentation de ces tests, c'est à dire les spécifications de ces tests ( le pourquoi ), le source portant 'le comment' on le fait.
Et ce afin d'éviter de recopier ces même informations dans un document Word, à destination des membres de l'équipe et surtout des futurs 'repreneurs'.
Ce document étant à mon avis une redondance d'informations et surtout un document mort-né étant donné que dans ce que l'on appel le 'change management' on est certain que ce document va dériver, alors que le fichier source beaucoup moins. Enfin on l'espére !

Mon second besoin est le suivant:
je suis en train d'adapter un composant, un dataset de DOA pour ne pas le citer, et j'aimerais que cette fois le fichier source 'héberge' la liste des modifications et le pourquoi de ces modifications et ce afin de générer une documentation.
Et dans ce cas séparer le 'comment on fait' ( le source ) du 'pourquoi on le fait' ( +- l'objectif ).
Donc ici j'aimerais extraire uniquement les méthodes impactées et le pourquoi elles le sont.

Donc ton logiciel documente le source, les classes, les entêtes de méthode, les propriétés,etc. S'il permettait d'extraire soit la documentation du source soit la documentation imbriquée d'un type particulier j'en serais ravi mais ma demande implique peut être une refonte de ton soft.

D'une certaine maniére l'idée serait d'avoir un EDI qui gére des fichiers composite, évitant ainsi une multitude de document !
N'ayant pas Rationnal Rose sous la main, ou un autre outils du même type, qui permet si on est rigoureux de générer une documentation conséquente, j'essaie donc de trouver une solution simple et ton logiciel semble répondre à mon besoin.
Il me reste à l'étudier plus profondément.

Envoyé par trident_job

Et surtout, s'il ne convient pas à ton souhait, ou que tu ne l'aimes pas du tout, ca m'interresse aussi de savoir pourquoi !

Le sachant, dans tout les cas je te fais un retour sur mes tests. J'en ai essayé d'autre mais ils nécessitent de remanier les informations collectées.
Je l'ai essayé derniérement mais j'ai du louper une marche ;-)

Merci pour ton apport à la communauté Delphi, ton soft il est .

J'ai des sources de tests unitaires et j'aimerais que ces fichiers 'hébergent' la documentation de ces tests, c'est à dire les spécifications de ces tests ( le pourquoi ), le source portant 'le comment' on le fait.

Le problème est peut-être là. Le source, à travers les commentaires, peut faire office de document de conception, mais peut-être pas de spécification.
Pour ma part, je n'ai pas l'habitude de mélanger les deux.

Dans le cas de tes tests unitaires, rien ne t'empêche effectivement de commenter à ta guise tes sources (unités, classes, fonctions) pour les faire ressortir dans une doc.
Ensuite, pour la génération, voici ce que DCTD peut faire :
Générer la doc HTML de tout ce que tu as commenté dans le JavaTAG description. le problème, ce que tout va apparaitre, unités, classe, fonctions, etc ...

Voici ce que DCTD pourra faire dans la prochaine version:
Ignorer dans la documentation les classes, fonctions et membres qui n'ont pas été documentés.
Filtrer les données à générer dans la doc : Unités, Classes, méthodes, propriétés, constantes, etc ...
Cela te permettra d'avoir une doc plus légère.


Voici ce que DCTD pourra faire dans une version future:
Compatibilité avec les fichiers de description XML et DOX (DocOmatic). Celà permet de séparer les commentaires "JavaDoc" et le code source en terme de fichier. Il sera possible de passer d'un format à l'autre, ou d'avoir les deux en parrallèle. je ne sais pas si c'est vraiment interressant pour toi.


Voici comment DCTD pourrait évoluer pour ton besoin:
L'introduction de balises style "JavaDoc" spécifiques pour introduire un commentaire "de spécification". Ces balises pourraient donc être les seules à être extraites. Il faudrait que je regarde si qqch existe déjà dans d'autres softs, et dans le JavaDoc, mais il me semble pas. Est-ce que cela serait suffisant pour toi ?

mais ma demande implique peut être une refonte de ton soft

L'introduction d'une nouvelle balise ou d'un TAG spécifique ne pose pas de problème, heureusement. Le soft est suffisament souple, modulaire avec assez d'abstraction pour permettre ce genre d'évolution en douceur.
Mais je ne voudrais pas faire de modif qui ne soit pas dans le "ton actuel". Etendre les possibilités du logiciel oui, j'en serais ravi, le transformer en couteau suisse, je ne crois pas

Je pense que ton idée mérite d'être creusée, on devrait quand même arriver à trouver une solution

Si tu as déjà un ptit bout d'exemple que tu peut me faire parvenir, comme cela je serais sûr de ce que tu veux. Qcq lignes de codes commentés, et le résultat que tu veux obtenir.

Envoyé par trident_job

J'ai des sources de tests unitaires et j'aimerais que ces fichiers 'hébergent' la documentation de ces tests, c'est à dire les spécifications de ces tests ( le pourquoi ), le source portant 'le comment' on le fait.

Le problème est peut-être là. Le source, à travers les commentaires, peut faire office de document de conception, mais peut-être pas de spécification.
Pour ma part, je n'ai pas l'habitude de mélanger les deux.

Ce n'est pas vraiment des spécifications étant donné qu'elles n'existent pas, le source= les spec ! Donc j'aimerais détailler suffisament ces tests.
Avec les tags existants, c'est suffisant.

Envoyé par trident_job

Voici ce que DCTD pourra faire dans la prochaine version:
Ignorer dans la documentation les classes, fonctions et membres qui n'ont pas été documentés.
Filtrer les données à générer dans la doc : Unités, Classes, méthodes, propriétés, constantes, etc ...

Dans un premier temps cela me permettrait effectivement de remonter que les modifs du sources, quitte à générer 2 documents. Ensuite je verrais.
Et cette prochaine version quand seras-t-elle dispo ?

J'ai fait qq tests souhaites-tu que je passe par ton site pour te remonter les infos ou je les poste ici ?

Avec les tags existants, c'est suffisant.

Cool ! 8)

Et cette prochaine version quand sera-t-elle dispo ?

Une semaine au plus tard, plus tôt si les traducteurs sont efficaces !
Généralement, je sors une version par mois, en milieu de mois.

J'ai fait qq tests souhaites-tu que je passe par ton site pour te remonter les infos ou je les poste ici ?

Préference pour le site web, par le portail de SourceForge.
SI tu "maitrise" l'anglais, tu peux poster directement des Trackers.
Sinon, poste ici, je les importe ensuite avec traduction !

TridenT

Envoyé par trident_job

Et cette prochaine version quand sera-t-elle dispo ?

Une semaine au plus tard, plus tôt si les traducteurs sont efficaces !
Généralement, je sors une version par mois, en milieu de mois.

Bonne nouvelle !

Pour les remarques, n'etant un champion en anglais je préfére le français.
C'est parti :
Voici qq remarques :

La sauvegarde du fichier de configuration n'est pas proposée en fin de programme ( quit).
La sauvegarde du nom donné dans 'nouveau projet' n'est pas proposée par défaut dans le fenêtre de sélection de nom de fichier.
Si je modifie le même projet et fait save, il me redemande le nom du fichier.

L'ajout d'une barre de progression lors de la phase de parsing, on ne sait pas trop si le soft continue le traitement ou pas (source de 10600 lignes)

Ajouter un menu Check+Build, utile après avoir modifier le source.

Suite à un 'check', lorsque j'exécute un 'build' le curseur de souris n'est pas modifiée en sablier.

Pas de possibilité de rappeler, via l'interface, la page HTML après l'avoir fermée. Je dois passer par l'explorateur de fichier.

Les menus restent sélectionnable pendant le traitement 'Check projet', je peux donc l'appeler + fois et une AV peut survenir.

Permettre la purge du dossier de sortie ( Out )

La langue sélectionnée n'est pas sauvegardée.

Dans le champ 'résumé du projet' des propriétés du projet, on ne peux pas une fois un caractére saisie sélectionner la ligne entiére afin de la supprimer.

Ces propriétés ne sont pas présente dans les page HTML :
{$IFDEF CompilerVersion4}
FMasterSource: TDataSource;
FMasterLink: TMasterDataLink;
{$ENDIF}
Est-ce le comportement normal ?


Gestion des tag :
Je n'ai pas la possibilité de ne pas afficher "#No TAG found in source code#" pour les classe,méthodes et propriétés non détaillées.
J'ai utilisé les 2 options concernant les tag sans succés.

Une gestion de la génération en ligne de commande est-elle prévue ? Dans le cas où je ne souhaite pas sauvegarder la version HTML.
Je génére la doc a chaque fois que je veux la lire mais sans passer par l'interface.

Le format du fichier de configuration restera-t-il 'propriétaire' ?
Un fichier INI offirais plus de possibilité dans le cadre d'une gestion en ligne de commande.

J'ai un décalage d'un contenu de tag dans la déclaration d'une classe, j'essaie d'isoler le pb.

Pour l'ajout de tag pour le code ( mon second pb ) :
si on pouvait récupérer des informations placées dans le corps de la méthode, entre le begin et le end, cela serai super.
soit un tag, soit permettre des blocs {*.... }

Voilà, il s'agit de qq point de détails mais je préfére te les signaler.

Les classses dans la partie implémentation ne sont pas prisent en compte dans la doc générée, est-ce 'normal' ?
Le tag version et author ne semble pas fonctionner dans le commentaire des méthodes dans la partie implémentation.

Pour l'ajout de tag, voici un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
procedure TDM.UpdateCLob;
var T1,T2:string;
begin
   T1:='Premier Test';
   T2:='Second Test';
 
   // Rafraîchi les datasets, on part sur le même contenu.
  OracleDataSet.Refresh;
  OracleDataSet2.Refresh;
   // 'Session1' : Se positionne sur le premier enregistrement puis l'édite
  OracleDataSet.Locate('CODE',1,[]);
  OracleDataSet.Edit;
 
  T1:=DateTimeToStr(Now);
  Sleep(1000);
    // 'Session1' : on modifie un champs CLob
  OracleDataSetCOMMENTAIRE.Value:=T1;
 
   // 'Session2' : Se positionne sur le premier enregistrement
  OracleDataSet2.Locate('CODE',1,[]);
   // 'Session1' : On met à jour la première ligne
  OracleDataSet.Post;
   // 'Session2' :  on édite la ligne
  OracleDataSet2.Edit;
 
  T2:=DateTimeToStr(Now);
   // 'Session2' : on modifie un champs CLob
  OracleDataSet2COMMENTAIRE.Value:=T2;
   // 'Session2' : On met à jour la première ligne
  OracleDataSet2.Post;
 
  OracleDataSet2.RefreshRecord;
  OracleDataSet.Refresh;
 
  OracleDataSet.Locate('CODE',1,[]);
  // Check du résultat
  Check(OracleDataSetCOMMENTAIRE.Value=T2,'Problème pour le type Clob !');
end;

Un tag @Comment permettrais de commenter la méthode UpdateCLob :

Commentaire :
Rafraîchi les datasets, on part sur le même contenu.
'Session1' : Se positionne sur le premier enregistrement puis l'édite
'Session1' : On modifie un champs CLob
'Session2' : Se positionne sur le premier enregistrement
'Session1' : On met à jour la première ligne
'Session2' : On édite la ligne
'Session2' : On modifie un champs CLob
'Session2' : On met à jour la première ligne
Check du résultat

Salut !
Excuse pour le temps de répons,e mais j'ai cru que j'avais déjà posté ...
Tout d'abord, merci pour tes remarques, elles me permettront d'améliorer grandement l'interface, qui n'est pas mon point fort du tout !!!

ensuite, à propos de tes remarques:

La sauvegarde du fichier de configuration n'est pas proposée en fin de programme ( quit).
La sauvegarde du nom donné dans 'nouveau projet' n'est pas proposée par défaut dans le fenêtre de sélection de nom de fichier.
Si je modifie le même projet et fait save, il me redemande le nom du fichier.
L'ajout d'une barre de progression lors de la phase de parsing, on ne sait pas trop si le soft continue le traitement ou pas (source de 10600 lignes)
Ajouter un menu Check+Build, utile après avoir modifier le source.
Suite à un 'check', lorsque j'exécute un 'build' le curseur de souris n'est pas modifiée en sablier.
Pas de possibilité de rappeler, via l'interface, la page HTML après l'avoir fermée. Je dois passer par l'explorateur de fichier.
Les menus restent sélectionnable pendant le traitement 'Check projet', je peux donc l'appeler + fois et une AV peut survenir.
Permettre la purge du dossier de sortie ( Out )
La langue sélectionnée n'est pas sauvegardée.
Dans le champ 'résumé du projet' des propriétés du projet, on ne peux pas une fois un caractére saisie sélectionner la ligne entiére afin de la supprimer.

OK, je renterais un Tracker pour tous ces points, et ils seront corrigés pour la sortie de la v1.0.

Ces propriétés ne sont pas présente dans les page HTML :
{$IFDEF CompilerVersion4}
FMasterSource: TDataSource;
FMasterLink: TMasterDataLink;
{$ENDIF}
Est-ce le comportement normal ?

Non, c'est pas normal ! Je jette un coups d'oeil !

Gestion des tag :
Je n'ai pas la possibilité de ne pas afficher "#No TAG found in source code#" pour les classe,méthodes et propriétés non détaillées.
J'ai utilisé les 2 options concernant les tag sans succés.

Corrigé dans la v0.9beta

Une gestion de la génération en ligne de commande est-elle prévue ? Dans le cas où je ne souhaite pas sauvegarder la version HTML.
Je génére la doc a chaque fois que je veux la lire mais sans passer par l'interface.

La version v0.8b te fournie la possibilité de générer en ligne de commande ta doc. Il s'agit du fichier DCTD_cmd.exe

Le format du fichier de configuration restera-t-il 'propriétaire' ?
Un fichier INI offirais plus de possibilité dans le cadre d'une gestion en ligne de commande.

Non, à terme, je passerais sur un fichier plus facilement éditable, XML ou INI, je ne sais aps encore. Pour l'instant, le but était d'aller au plus vite.

J'ai un décalage d'un contenu de tag dans la déclaration d'une classe, j'essaie d'isoler le pb.

Oui, tiens moi au courant !


Voila le genre de remarques constructives que j'aime !
Merci encore !

Un tag @Comment permettrais de commenter la méthode UpdateCLob :

Je comprends ce que tu veux dire.
Tu veux que la description de la méthode soit enrichie par des commentaires dans le corps de celle-ci ?

Techniquement, cela ne poserait pas de problème.
Il faut voir si du coté JavaDoc il existe déjà qqch de similaire. A ma connaissance, non.

Eventuellement, on peut faire une extension au TAG et avoir un @Comment ou @Description comme tu disais. Je vais regarder tout cela, et je te tiens au courant !

Ca m'interresse aussi du coups !

Salut,

Envoyé par trident_job

Tu veux que la description de la méthode soit enrichie par des commentaires dans le corps de celle-ci ?

Oui.

Envoyé par trident_job

Je vais regarder tout cela, et je te tiens au courant !

Avec plaisir !

Peux-tu me donner qq infos sur ces 2 questions :

Les classses dans la partie implémentation ne sont pas prisent en compte dans la doc générée, est-ce 'normal' ?

Le tag version et author ne semble pas fonctionner dans le commentaire des méthodes dans la partie implémentation. Dans le cas ou je souhaite indiquer qui à fait quoi.

C'est pour quand la mise en ligne de la v0.9beta ?

Merci

Envoyé par trident_job

J'ai un décalage d'un contenu de tag dans la déclaration d'une classe, j'essaie d'isoler le pb.

Oui, tiens moi au courant !

Bon aprés qq recherche voici le code qui semble poser probléme.
(J'ai tronqué le code au maximum)

Je ne sais pas si c'est ma démarche qui est bugée ou le soft
A confirmer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
 
{* -----------------------------------------------------------------------------
  UNIT NAME : CUOracleDataView
  DATE      : 04/02/2003
 
 Les modifications sont balisées ainsi :
// <Auteur>
   ...
// </Auteur>
 
 Modifications :
  ...
  @Version 04/02/2003 Origine
    - uses OracleData.TByteArray instead of TByteArray
 
  @Author Laurent Dardenne <LD>
  @Version 14/09/2004 DOA 4.0.4
 
      Classe TOracleDataView
      ----------------------
       - Method FetchRecord :
 
 -----------------------------------------------------------------------------}
 
unit CUView;
 
interface
 
 
type
 
//<LD>  
{*
rcAll      : on compare tout les champs de type Lob
rcCLobOnly : on compare uniquement les champs de type CLob
rcNone     : on ne compare aucun champ de type Lob (ni LOB, ni CLOB)
Dans le cas où on ne compare pas les champs LOB ou CLOB, on les considérent comme égaux.
La méthode de comparaison renvoie VRAI.
 @Author ..
 @Version 04/02/2004 DOA 4.0.4
}
//</LD>
  TRecordChangeBlob = (rcAll, rcCLobOnly, rcNone);
// </LD>
 
type
 
   // TOracleDataView
   /// Gére les vues 
  TOracleDataView = class(TDataSet)
  private
    FReadOnly: Boolean;
    FSequenceField: Boolean; ///<LD> cf. remarques de TSequenceFieldView </LD>
    Activating: Boolean;
    FLockTable: string;			  /// Nom de la table à locker
    FRecordChangeBlob: TRecordChangeBlob; /// Type de gestion des blobs
    F_RowidColumn: string;		  /// Nom de la colonne Rowid 
    FOnDecompressBLOB: boolean;
    procedure SetLockTable(const Value: string);	/// Accéde au nom de table à vérouiller
    procedure SetTable(const Value: string);		/// commentaire procedure 
 
  end;
 
implementation
 
procedure TOracleDataView.SetLockTable(const Value: string);
begin
end;
end.

Le commentaire de la procédure SetLockTable se retrouve dans le commentaire de la propriété FOnDecompressBLOB.

La présence de la propriété FOnDecompressBLOB semble influencer le comportement dans mon cas.

Pour le type TRecordChangeBlob j'aimerais récupérer dans sa description le tag auteur et version.

Les classes dans la partie implémentation ne sont pas prisent en compte dans la doc générée, est-ce 'normal' ?

C'est corrigé dans la v0.9b.

Le tag version et author ne semble pas fonctionner dans le commentaire des méthodes dans la partie implémentation. Dans le cas ou je souhaite indiquer qui à fait quoi.

C'est aussi corrigé dans la v0.9b.

C'est pour quand la mise en ligne de la v0.9beta ?

C'est une question d'heure maintenant que j'ai reçu les traductions. Ce soir ou demain, la version sera officielle. AU pire des cas, si j'ai un problème de temps (j'ai une vie en dehors de DCTD!), je t'enverrai une pré-version.

Envoyé par trident_job

C'est une question d'heure maintenant que j'ai reçu les traductions. Ce soir ou demain, la version sera officielle.

Merci

ANN: DelphiCodeToDoc v0.9Beta disponible - Outil gratuit de generation de documentation pour Delphi

La dernière version de DelphiCodeToDoc (v0.9Beta) est disponible. Elle peut être téléchargée ici :

http://prdownloads.sourceforge.net/d...b.zip?download

DelphiCodeToDoc est un outils gratuit de génération de documentation pour
Delphi, distribuer sous la licence GNU - GPL. Il utilise les informations
contenu dans le code source, comme les symboles et les commentaires
formattés, pour produire une documentation précise de votre code ou de votre
composant.

Situation : DelphiCodeToDoc continue en version en Beta. Il sortira en Stable (v1.0) dans la prochaine version.

-----------------------------------------------------------------
Quelles sont les nouveautés de cette version ?
Cette version v0.9Beta contient les modifications suivantes :

Correction des commentaires de méthodes dans la partie Implementation non documentés (Tracker 997985)
Ajout du TAG "Throws" pour les méthodes et les fonctions.
Correction des options non traduites à l'initialisation du projet (Tracker 1025884)
Correction de la procedure "Register" non documentée (Tracker 1012908)
Correction de la fonction "Cacher section TAG vide" (Tracker 1012885)
Ajout d'une options "Cacher block vide du rapport" (Tracker 1012886)
Ajout d'une fonction de création de répertoire lors de la sélection du répertoire de sortie (Tracker 892440)
Correction du problème de création de projet à partir d'un lecteur réseau mappé (Tracker 1016893)
Correction des déclarations de types de fonctions (Tracker 1016879)
Correction du filtre des fichier *.pas (Tracker 1016887)


Quels sont les bugs connus du logiciel ?
*Aucuns pour le moment

Quelles sont les limitations connues du programme ?
*Les méthodes avec le même nom (surchargées) dans une classe resulterons en une seule fonction dans le rapport de sortie
*Les fonctions avec le même nom (surchargées) resulterons en une seule fonction dans le rapport de sortie
*Aucun "define" du pre-processeur ne peuvent être définis
*Les propriétés n'ont pas de description (mais sont générées)
*Les évenements n'ont pas de description
*Seul le format HTML sera généré pour la documentation
*Seul l'Anglais est disponible pour le document généré
*Le TAG @see n'est pas supporté

Quelles seront les futures évolutions ?
*Ajouter le choix de la langue pour la génération de la documentation
*Ajout d'un nouvel expert "création du projet" complet et plus estétique

Salut,
j'ai un pb de redondance de description dans les fichiers HTML et ce dans un cas bien précis :

Prendre un fichier .pas contenant des déclarations de classes.
Le copier dans c:\temp\test\Unite.pas
Le recopier avec le même nom dans c:\temp\test\repertoire1\Unite.pas
créer un projet avec l'option "répertoires récursifs" à ON
Exécuter Check/Build.
Le contenu des tags Description '{*' est dupliqué dans les pages HTML.

Renommer le fichier c:\temp\test\repertoire1\Unite.pas en c:\temp\test\repertoire1\Unite2.pas
sans renommer dans la clause Unit le nom d'unité
Exécuter Check/Build.
Le contenu des tags Description '{*' est dupliqué dans les pages HTML.

Renommer c:\temp\test\repertoire1\Unite2.pas dans la clause Unit le nom d'unité.
Exécuter Check/Build.
Le contenu des tags Description '{*' n'est plus dupliqué dans les pages HTML.

Si je recopie le fichier d'origine dans c:\temp\test\repertoire2\Unite.pas
Dans ce cas le contenu des tags Description '{*' est triplé dans les pages HTML.
...

Donc dans le cas où je souhaite avoir, dans une arborescence, 2 fois ou plus le même fichier unité cela n'est pas possible. Je reconnais que ce n'est pas d'un usage courant
Je suppose que dans ta structure de données, la construction de l'unicité de chaque classe ne prend pas en compte le nom de fichier et/ou le nom de répertoire.