Quand tu ouvre le dialogue il a cette taille la par défaut ?
Tu peut quand même le redimensionner par la suite ?
Car chez moi par défaut il est plus petit (même en prenant en compte que mon écran à une définition plus grande) et je peut encore le réduire, il devient alors très petit et doit pouvoir être affichable sur n'importe qu'elle définition d'écran.

Merci nomicons/smile

-Hop les nomenclatures sont terminé.
Vous pouvez torturer le truc dans tous les sens et me remonter les coquilles et petite amélioration si vous en avez.

Petit résumé rapide des fonctionnalités:

Tableau :
-Les tableaux peuvent avoir un nom.
-Peut être ajouté sur n'importe qu'elle folio.
-Police marge et alignement (droite centre gauche) ajustable séparément pour les en têtes et les cellules du tableau.
-Position taille et nombre de lignes ajustable.
-Possibilité de liée plusieurs tableaux entre eux notamment quand l'intégralité de la nomenclature ne peut être contenu dans un folio.
-Ajustement automatique de la taille du tableau par rapport au folio.
-Option pour appliquer la géométrie d'un tableaux à tous les tableau liée à celui-ci, histoire que tout soit homogène.

Contenu du tableau :
-Entièrement personnalisable, vous affiché ce que vous voulez ou vous voulez (info à afficher dans l'ordre voulue, filtre sur type d'élément, filtre sur contenu de l'info "contient, contient pas, non vide etc...").
-Le contenue étant généré depuis une bdd sqlite, il vous est possible d'écrire votre propre requête.

Dialogue de création de nomenclature.
-Sauvegarde/chargement de configuration du tableau et du contenue afin de rendre la création plus rapide.
-Option pour automatiquement ajuster le tableau au folio.
-Option pour ajouter automatiquement de nouveau tableaux dans de nouveau folios si la nomenclature ne peut être contenue dans 1 à N folios/tableaux.

Corrigé merci.

galexis wrote:

Si tu te ressers de ce tableau comme fonction pour lister les folios, les sections de fils ou autre et les câbles,ou un autre cas qui pourrait le nécessiter ...

Oui ce sera le cas, et donc ? Dans ce cas tu serais plutôt pour le 3 ?

Question sur un comportement :
Quand on supprime un tableau qui est liée à d'autre tableau, faut il :
-1 supprimer uniquement le tableau
-2 supprimer tous les tableaux liée à celui-ci
-3 poser la question.

Perso je penche pour le 2eme car je pense que cela évitera des erreurs du style oublier d'en enlever un.
Ça n'a aucun sens de supprimer un tableau et garder les autres qui étais liée car que l'on supprime un tableau du début, de fin, ou au milieu dans tous les cas il manquera des infos étant donné qu'il manquera un tableau ou alors (en fonction de la config) le dernier sera beaucoup plus gros et donc dépassera du folio.
Et pour finir mettre en place des tableaux est maintenant assez simple et rapide c'est pas comme si on perdais 1h de boulot..

357

(32 replies, posted in Code)

16  + 20 + 20 = 56s
Wooo less than 1 min to build for three OS.

Hello, thanks for the patch, but in the Qt documentation I see the follwing note:

Note: Since Qt 5.14, range constructors are available for Qt's generic container classes and should be used in place of this method.

for both QList<T> QSet::toList() const and QList<T> QSet::values() const.
May be it's will be better to use range constructor, because values will probably be deprecated in future.

S.DEFFAUX wrote:

Je viens de tester sur Win10, la création de nouveau folio fonctionne bien, par contre la nomenclature dépasse du folio même en cochant la "casse ajuster au folio".

C'est pas normal ça. Le tableau s'adapte en hauteur et en largeur, normalement il y une marge (d'environ) 20 px gauche/haut/droit et une marge en bas dont la taille varie en fonction de la taille du folio et de la hauteur d'une ligne de la nomenclature, mais en aucun cas le tableau ne doit dépasser du folio. Peut tu envoyer ton projet pour que je regarde ?

scorpio810 wrote:

*Les tables sont statiques en ce qui concernent les traductions, donc si vous changez de langue les entêtes ne seront pas automatiquement traduis, faudra générer de nouvelles tables.

Je l'avais oublié celui-la, je vais corriger ça.

Pour le tableau oui c'est faisable, un peu de programmation, ajouter une nouvelle table a la db etc... rien de bien méchant.
Je ferais ça pour la 0.8 en plus de la refonte du sommaire avec le nouveau tableau.

galexis wrote:

Sera-t'il possible de récupérer ces info par requêtes dans un "super tableau" de Joshua?

Oui y'à pas de raison que ça ne fonctionne pas.
Après il faudra juste me préciser ce que vous voulez exactement, car c'est pas dans les nomenclatures ça (et devrais une autre nomenclature que c'elle des éléments.)

Oui c'est prévu c'est la norme IEC 81346
https://qelectrotech.org/forum/viewtopic.php?id=463
En revanche quand....

OK, je met ça de coté dans la todo list

Oui supprimer le folio, ou alors fermer le projet éditer le xml avec un éditeur de texte et supprimer le morceau de xml qui correspond au tableau. Facile !!

Plus sérieusement, c'est pas encore implémenté, mais les tableaux pourront bien évidemment être supprimé, et géré par la pile d'annulation. nomicons/smile

Work well for every local. Pushed to git master.
Thanks.

After test,
m_rotate_selection->setShortcut(QKeySequence( tr("SPACE")));
work well for nl be local and also for french.
I will try for all local and if it's ok I commit the change.

Thanks for report

Hop réglé.
Non Laurent, rien a voir avec un workaround de ton cru nomicons/smile

Effectivement, je regarde ça.
C'est déjà pas bien normal que le texte qui chez moi est '_' dans l'éditeur d'élément, devient 'texte' une fois posé sur le folio.

Petite question :
Dans le tableau de la nomenclature, j'ai mis en place la possibilité d'éditer les marges gauche/droite/haut/bas, est ce que au final je me fait pas un peu ch**r pour rien et devrais plutôt laisser les marges de la police par défaut ? Vous en pensez quoi ?
Pour testé/voir les marges par défaut de la police, prenez un texte dynamique appliqué lui la même police et taille que les textes du tableau, les marges corresponde au cadre dessiné autour du texte quand il est sélectionné.

S.DEFFAUX wrote:

Je ne voulais jeter un pavée dans la mare

T'inquiète, y'a pas de mal nomicons/wink et je ne remet pas ton travail en question, bien au contraire.

S.DEFFAUX wrote:

pour ma part je me sert beaucoup de la collection article constructeur, cela m'évite tous retaper.

C'est pour ça AMHA qu'avec les éléments standard de la collection officiel il faut juste le minimum sans référence, la véritable évolution sera le jour ou une base de donné sera crée.
Pour les éléments constructeur spécifique, la évidemment il faut les détaillé dans la collection officiel.

Quand je parle de doublons, je pense entre autre à des éléments se trouvant dans les sous dossiers énergie dont certains sont purement et simplement des copier/coller d'éléments d'autre dossier (bobine, voyant, contact etc...)

scorpio810 wrote:

@joshua : tu penses qu'il serait possible de rendre les tables bi-directionnelles? le model/vue le permet.
Il est bien plus rapide et  efficace de renseigner les informations N° interne, Fabricant,  référence constructeur, etc ... depuis les tableaux que depuis le widget information.

Oui c'est possible mais demanderais beaucoup de boulot.
Je verrais plutôt l'édition par le biais d'un widget qui sera plus simple pour moi à coder et plus simple à utiliser, avec sûrement plein d'avantage comme par exemple pouvoir visualiser l'élément que tu est en train d'éditer (si tu as un doute), alors que si tu édite le tableau sur un folio, tu pourra pas visualisé un élément sur un autre folio, mais aussi toutes les possibilité d'un tableur.
De plus on garde bien séparé le fond et la forme.
C'est l'édition tabulaire que Nuri parlais.

galexis wrote:

Personnellement je ne suis pas pour qu'on créé un symbole voyant par référence de chaque constructeurs, ça deviendra vite ingérable et cela chargera énormément la bibliothèque. Il vaudrait mieux avoir un fichier. Il serait plus propre d'avoir une base de donnée pour remplir rapidement les informations des symboles, soit une commune qu'on alimente, soit une personnel qui s'alimente au fil de nos saisies.

100% d'accord avec toi, les informations d'éléments sont la pour ça, sinon rien que pour des voyants (en comptant les couleurs) on pourrais se retrouver avec des centaines d'éléments visuellement identique.
Perso je trouve que la bibliothèque est déjà bien grosse avec beaucoup de doublons inutile (Faire le tri est un énorme travail).
La base de donné fait partie des choses qui sont dans les cartons. Ce serais une bdd fournis avec Qet et qui pourra aussi être remplis par l’utilisateur, et partagé a nouveau avec la version officiel de Qet afin d'en faire profité tout le monde (comme les éléments).

Galexis wrote:

Super !
T'as finit de coder la nomenclature ?

.
Non :
La sauvegarde des requêtes comme tu l'as mentionné.
Lors de l'ajout d'une nomenclature un dialogue afin de choisir immédiatement la requête, ça gagne du temps.
La création automatique des tableaux sur de nouveau folio quand la nomenclature est trop gros pour un folio.
L'application de la géométrie d'un tableau sur tous les autres tableau liée cad : tu créé une nomenclatures avec création automatique des tableaux sur de nouveau folio -> paf 10 tableaux. Tu ajuste la position du premier tableau ainsi que sa taille afin d'être par exemple, centré sur le folio, ensuite tu applique ça sur les 9 autres tableaux automatiquement ainsi les 10 tableaux sont tous identique sans avoir eu à les faire 1 par 1.

Hop corrigé + quand le dialogue est ouvert il formé en fonction de la requête actuelle du tableau.

C'est corrigé de mon coté, mais comme j'ai commencé à coder pour que le dialogue affiche la configuration de la requette existante, je commiterais le tout même temps.

Go to help -> online manual or just press F1.

For cross ref : https://download.qelectrotech.org/qet/m … index.html

Regards.