Sommaire (Page 3 of 5)

Super, c'est une grosse évolution par rapport à l'existant ! Oui, tu peux envoyer les modifs. J'en ai pas besoin expressément, mais ca permettra de tester.
Toutefois...
[mode mec chiant = ON]
selon les docs à réaliser, les clients, le type d'industrie, etc... le sommaire sera amené à avoir différentes formes : type, nombre, largeur et ordre des colonnes (même problème avec les nomenclatures, chacun veut son truc à lui).
Le top, ce serait de pouvoir définir soi-même ces paramètres dans les propriétés DU PROJET.
[mode mec chiant = OFF]
mais ca complique sérieusement le truc, je suppose...

J'ai oublié de préciser, qu'on peut remplir ces nouvelles propriétés du ou des cartouches sans avoir besoin d'un cartouche spécifique modifié avec ces nouvelles variables, ce ne sera pas affiché dans le cartouche comme par exemple avec ceux fournis, mais sera enregistré et listé dans les pages sommaire ce qui peut-être très intéressant suivant les besoins.
Exemple : je veux que le folio ID 15 contienne l'indice de révision D, mais que ça n'apparaisse pas sur son cartouche.

Super !

Dans l'éditeur de cartouche, l'explication de la variable %version me parait trompeuse:
elle affiche la version de QET et non pas une version du projet/schéma.

Petite remarque, ces nouvelles propriétés de cartouche ne peuvent pas être appelées comme variables dans l'autonum de Davi pour la numérotation des Eléments, ce qui peux être un plus, ou pas !

Normal, tu as du rajouter loc = Doc dans l'onglet champs personnalisées.
Il est clair que j'aurai du nommer cette nouvelle variable autrement que %loc, ça peux prêter à confusion.

Et comme dit plus haut, ces nouvelles variables ne peuvent être appelées pour nommer des labels éléments (pour l'instant. A voir avec Davi si ça vous intéressent ou pas.).
Comme ces autres variables %author, %filename, etc, ces nouvelles propriétés de cartouche ne fonctionnent pas dans les formules de label éléments.

Merci pour vos remarques, suggestions, il est encore temps de revenir en arrière et faire un revert ...

Revision: 4626
Author:   scorpio810
Date:     2016-08-12 13:32:56 +0200 (Fri, 12 Aug 2016)
Log Message:
-----------
Titleblock properties rename property %loc to %locmach

C'est pour cela que l'aspect personnalisable de l'éditeur serait intéressant...

J'ai quelques idées mais faut pas compter sur moi pour faire du C++ qui fonctionne. Moi je sais faire du C++ "statique", c'est-à-dire non compilable...

Plus sérieusement, pourquoi ne pas utiliser le format .elmt pour définir les tableaux ?
J'explique l'idée :
Pour faire un tableau, l'utilisateur doit définir 2 éléḿents :
1. celui qui servira d'en-tête et qui peut ressembler à quelque chose comme ca :

2. celui qui sera rempli de données, comme ca par exemple (ou QET remplace les variables %truc par leurs valeurs):

Clair, en arrière plan il faut un engine qui génère les nouveaux folios avec ces éléments et qui sache combien de ligne il peut générer par folio. Mais quand c'est sur pied, on peut aussi utiliser le même engine pour faire des nomenclatures, listes de câbles, etc.

Avec ce truc, l'utilisateur a toute la flexibilité pour créer les tableaux dont il a besoin. Il peut définir lui-même la taille des textes, la largeur des colonnes, etc... et donc il est seul responsable si les textes se chevauchent, pas le logiciel !

L'intérêt réside aussi dans le fait que ce "générateur de tableaux" serait tellement flexible que, normalement, une fois développé, on ne devrait plus avoir besoin d'y toucher.

Mouahaha, pas joli de se moquer de Galexis, hein Nuri. 

Nuri: pas la peine de ré inventer la roue. 

Le code de diagramfoliolist fait déjà très bien le travail, il suffit de remplacer les constantes définies dans le code (regarde mes patch ) par des variables appelées depuis la config de QET pour rendre le sommaire entièrement dynamique :

Dans la config de QET l'utilisateur pourrait sélectionner dans une liste les entêtes de chaque de colonne qu'il veut (ID, Folio, titre, installation, location, auteur, date, etc ), leur ordre dans le tableau, et définir la largeur de chacune d'entre elle.