Pour ton problème de requête qui n'est pas enregistrer, je n'arrive pas à reproduire le défaut.

Galexis wrote:

Cela me parait beaucoup plus cohérent de procéder comme cela, sinon quel est l'utilité du champs quantité ???

Car ça a été mis en place conjointement avec les unité par ex 'câble de 3m'.
Mais tu as raison, c'est un oublis de ma part.
Je vais voir pour utiliser ta requête directement dans le code.
Pour le problème de sauvegarde de ta requête il faut que je me penche dessus (pas trop eu le temps cette semaine).

Tu peut préciser quand tu dit "comme vide".
Autrement non lors d'une mise à jours les requêtes que tu as enregistré sont conservé.

Oui il faut bien rajouter "quantité (numéro d'article)", car c'est une colonne comme une autre dans le fichier csv.
Alors il est vrai que dans 99% des cas, la quantité d'article sera la dernière colonne MAIS je préfère prendre les devants et laisser à l'utilisateur le choix de la position.

Le morceau de requête sql suivant définie l'export en tant que bon de commande.

GROUP BY designation

signifie que toutes les sélections portant la même désignation seront groupés en une seul sélection.
Ensuite

COUNT(*) AS designation_qty

Retourne dans la sélection courante, le nombre de sélection qui on été regroupé.

Nuri wrote:

D'où l'intérêt de séparer le traitement nomenclature du traitement bon de commande

Comme je disais j'en voit pas l’intérêt, mais si la majorité décide que si, je m'y colle.

Car j'ai crée le dialogue ainsi sans trop y réfléchir :p
Mais pourquoi pas.
Par contre pour les listes déroulante, les laisser en bas proche du bouton OK n'est il pas mieux, d'un point vue mouvement de souris ?

Pour l'histoire de liste de matériel vs bon de commande, je vais peut être dire une bêtise mais pour moi il est bien question d'une liste de matériel.
Un bon de commande s'adresse à un fournisseur (Il y a de forte chance qu'avec la liste/bon crée depuis QET tout ne soit pas commandé au même endroit ) de plus sur un bon de commande il n'y a pas qu'une liste, il y a le nom de ton entreprise avec des info comme adresse, fax, tel..... un numéro de commande et sûrement beaucoup d'autres choses.

Nuri wrote:

Non, non... Je ne voulais pas remettre les choses en question à ce point là.
Comme je disais, le dialogue est bien construit et très pratique, car on peut configurer à peu près ce que l'on veut.
Donc... Super ! Pas la peine de jeter le bébé avec l'eau du bain !

Ok je n'avais pas bien compris, donc tu verrais deux entrées "nomenclature" et "bon de commande" qui ouvre le dialogue, mais le dialogue ne proposera que les informations utile (nomenclature ou bon de commande).
A voir ce qu'en pense les autres (à coder c'est vraiment rien) personnellement je vote pour un seul dialogue, il suffit juste de créer ta requete la sauvegarder puis rappeler en fonction de ce que tu veut faire ensuite.
Par contre comme disais galexis, on peut renommer l'ensemble en "export csv" ce qui effectivement correspond plus à ce que fait le dialogue.

Nuri wrote:

1.
Un bouton d'aide pour faire apparaître une fenêtre qui explique la différence entre une nomenclature et un bon de commande, et comment le traitement des données diffère.

Il suffit de laisser la souris sur les lignes "Formater en..." pour faire apparaitre le tooltip. Bon j'avoue que ce n'est pas génial.

Nuri wrote:

2.
Un bouton d'aide dans la ligne de la requête SQL pour expliquer rapidement comment créer ses propres requêtes. Par exemple si je veux faire un bon de commande ne contenant que les composants de l'armoire 1 (alors que mon projet contient 3 armoires électriques, par exemple).

Expliquer comment est composé la bdd oui, après expliqué comment composer une requête c'est plus difficile, SQL est un langage. Après on peut mettre 4/5 exemples qui peuvent être utile dans notre cas.

galexis wrote:

e nom des champs "numéro d'article" et "numéro de commande" n'ont jamais été clairs pour moi, et cela était confirmé par le fait qu'à l'export "numéro d'article" apparaissait comme "désignation" ....


Ça a été un gros fouilli ce truc quand ça a été mis en place, et ça se ressent dans la code : numéro d'article -> désignation.
Quand j'ai codé la bdd pour l'export, j'ai cru à un bug au début car je ne me rappelais plus de tout ça.
Après numéro d'article et numéro de commande il y festo qui fonctionne comme ça, exemple avec un vérin depuis leur site web :
vérin compact
ADN-12-10-A-P-A                ->doit être la designation
N° de pièce: 536205           ->doit être le numéro de commande (ou l'inverse nomicons/tongue)

@Nuri,
je trouve ça un peu contre productif de créer des entrées 'nomenclature' et 'liste de matériel', si par la suite on affiche un dialogue avec uniquement les information utile qu'il faudra choisir, ou rappeler une configuration, à ce compte la autant rester comme c'est actuellement car on perd la rapidité visé initialement.
En revanche si on fait les entrées 'nomenclature' et 'liste de matériel', qui exporte directement en csv les informations concerné (mais non configurable par l'utilisateur) alors la oui, ça à du sens et c'est rapide.
On peut garder une troisième entrée "export csv personnalisé" où la on utilisera le dialogue.

Je me rend compte que les radio buttons, tous | borne | bouton/commutateur est trop restrictif.
Toi et Laurent avez raison il vaut mieux avoir des check box pour chaque type | sous type afin d'avoir un choix inclusif et non pas exclusif.

Après réflexion c'est vrai qu'une grande partie du temps, l'utilisation de l'export sera pour la nomenclature (quoique minime une fois integré dans le projet), liste de matériel, impression (label de bornier, label d'élément simple + maître 'tous type', commentaire de bouton), donc un sous menu export dans le menu projet serait légitime.

galexis wrote:

ce qui me dérange plus c'est les labels basés sur formule manquant dans l'export qui me gène ...  ;-)

T'inquiète pas, ce sera fait nomicons/wink

galexis wrote:

J'ai une question: A priori c'est une base SQLITE. Où est-elle stockée ? Dans le projet ou dans QET ? Momentanée ou permanente ?
Je me disais qu'on pourrait peut-être cs servir de cette base de donnée pour faciliter le remplissage des références/constructeurs/description textuelle ? Lors de la saisie dans un de ces 3 champs, on va taper dans la base de donnée et on propose des saisie précédentes ....

Elle est momentanée dans le code, en revanche il est possible de la sauvegarder.
Oui et non, la bdd est crée à la volé lors de l'export donc pas utilisable en l'état pour saisir les informations d'élément.
La vraie solution (et j'ai déjà cogiter sur le truc par le passé) c'est une bdd article constructeur avec les 3 infos que tu cite (avec description textuelle traduis) et un dialogue permettant d'ajouter, modifier cette bdd, puis lors de la saisi des infos d'élément puiser dans cette bdd.
Et le must si tu connais la ref, tu rentre uniquement la ref et tout le reste se remplira tout seul.
Mais bon la on s'écarte du sujet....

scorpio810 wrote:

C'est plus facile à lire pour un humain que le XML..

Et aussi à coder, moins verbeux que le xml, et c'est très adapté pour ce genre de choses à stocker.

Double clic -> OK nomicons/wink

Galexis wrote:

- la sauvegarde de configuration est un peu déroutante mais très pratique. Quand on choisit une configuration enregistrée, c'est la requête SQL qui s'affiche et non l'affichage graphique qui indique le contenu de la configuration. Du coup la modification d'un configuration ou même juste la lecture de celle-ci n'est pas évidente au commun des mortel.

Oui j'y avais pensé mais avais laisser tel qu'elle car demandais plus de boulot, et je me suis dit que si le besoins s'en faisais ressentir on ne manquerais pas de me le dire nomicons/wink
Je vais donc corriger ça pour les requêtes crée depuis le dialogue, pour les requêtes perso le comportement sera le même.

Pour les autres demande, c'est du détails ce sera corrigé.

galexis wrote:

La question que personne n'a encore posée : est-ce que la création d'un élément nomenclature va en découler ? Je suis en ce moment sur un projet où j'ai beaucoup de plans à créer et cela m'éviterait de les générer à la maison avec mon script bash....

Non !!
Plus sérieusement, la nomenclature ne sera pas crée depuis ce dialogue car dédié à l'export.
En revanche du code sera probablement partagé (la bdd), et j'ai des nouvelles idées sur les fonctionnalitées à ajouter. D'ailleurs il faudrait que je mette à jours mes idée ici https://qelectrotech.org/forum/viewtopic.php?id=1489

Merci Nuri nomicons/smile

Il y a des choses sur lesquelle je suis d'accord, et d'autre moins.
Sur le fait de mieux séparer le menu "projet" par la suite, c'est sur que ce serais mieux surtout par rapport à ce qui AJOUTE DANS LE PROJET et ce qui EXPORTE DEPUIS LE PROJET, en revanche créer une entrée "nomenclature" et une "seconde bon de commande" je suis pas vraiment pour.

Dans le principe je comprend, mais en pratique on passera par le même dialogue avec 2 configurations différente, donc pourquoi faire deux entrées dans le menu, d'ailleurs c'est dans ce but que j'ai crée la sauvegarde/rapelle de configuration, afin que chacun puisse créer l'export qu'il souhaite.

Toujours dans l'idée d'être souple et paramétrable, j'ai mis une option pour filtrer les éléments par bornier afin d'exporter un csv des labels de bornier pour impression, et par bouton/commutateur pour exporter en csv les commentaires pour impression des portes étiquettes.
Si on suit ton idée, il faudrait créer 4 entrées juste pour ce qui est faisable par défaut dans qet.
Peut être faut-il nommer le menu différemment ?

Pour finir je dirais :
Bon, j'arrête là pour pas encore faire un pavé indigeste et attends vos commentaires pour de plus amples développements...

Ba pour le coup, on peut oublier tout ça, car obsolète depuis mon dernier commit.
En revanche si il existe toujours des incohérences avec le nouveau générateur, il faudra remonté ça dans le topic https://qelectrotech.org/forum/viewtopic.php?id=1521 (galexis à déjà commencé).

Bonjour Eric,
merci pour les compliments.

À l'heure actuel il n'est pas possible d'inclure directement une nomenclature dans QET.
Pour cela il faut passé par l'export en csv.
En revanche la création de nomenclature directement dans QET est prévue pour la future version :  https://qelectrotech.org/forum/viewtopic.php?id=1484

La version 0.61 est une vieille version, utilise la 0.7 qui est la dernière version.

L'export de la nomenclature à été totalement réécrit.

-Il est maintenant possible de choisir quelle informations exporté ainsi que l'ordre dans lequelle celles ci doivent être affiché.
-Une option permet de filtrer par type d'élément : tous, bornier, bouton/commutateur.
-Une autre option permet d'afficher ou non les en-têtes de colonne dans le fichier csv.
Avec ces option, il est possible de crée une nomenclature, une liste de commande, mais aussi pour l'impression des labels : liste des borniers et liste des boutons  / commutateurs.
-Il est possible d'enregistrer/charger une configuration facilement.
Enfin le travail étant effectué par une base de donné SQLite, un champ de texte permet à l'utilisateur de crée sa propre requête SQL.

Ho le boulet nomicons/angel, la mémoire me reviens après avoir relu le code.
Lorsque j'ai refais le panel d'élément avec le multi-threading, le cache sqlite était un goulot d'étranglement lorsque l'on cherchais les noms (plusieurs thread accèdent à la même bdd) du coup j'avais viré ça.
En revanche les pixmaps sont toujours mis en caches, mais ils ne sont pas créent lors de la créations de la bdd, mais la première fois que l'on en a besoins (c'est à dire qu'un dossier d'élément que vous n'avez jamais ouvert n'existe pas dans la bdd), ce qui explique que lorsqu'on efface la bdd puis relance qet, celle ci pèse très peu.

Il serais peut être bien de mettre une option pour utiliser ou nom la bdd pour les noms d'éléments, car sur un pc mono-coeur avec un vieux hdd, la bdd est très utile, en revanche un pc avec 8 coeurs et un sdd c'est autre chose.

Il serais aussi intéressant que je me documente sur les accès parallèle sqlite.

Effectivement même chose sur un pc Windows, je sais ce qu'il me reste à faire nomicons/wink

J'ai crée une fonction pour exporter en csv les numéros de fils dans le dernier commit. C'est très minimaliste, vous choisissez uniquement où sauvegarder le csv. J'ai pris en compte tes remarque Christophe.
À tester.

Hum j'ai vraiment du mal avec ce bug nomicons/sad 
Par contre le truc qui est vraiment étrange c'est que ton fichier soit vide, mais aussi le fichier de backup qui lui aussi fait 0 Ko car dans le code ceux sont deux fonctions différente (la sauvegarde et le backup) mais qui visiblement donne le même résultat.
Ça pourrais donc laisser croire que le problème vient d'avant l'écriture dans le fichier, mais d'un autre coté ça semble toucher que windows et qui du coup la seul différence avec les autres OS c'est l'écriture dans le fichier (dont je n'ai pas la main dessus).
Je pensais avoir réglé le problème en utilisant QSaveFile mais non.....
Bref tant de mots pour dire qu'au final je n'ai pas de solution mais je planche dessus.

Idem aux deux autres topic, nous parlerons ici de la fonctionnalité de liste de fileries.

-Pouvoir exporter au format csv, pour par exemple pouvoir imprimer les numéros de fil. D'ailleurs si des personnes ont des informations à ceux sujet, ils sont les bienvenues.
-Si il existe d'autre format de fichier pouvant être utilisé avec les imprimantes de numéro de filerie, nous pouvons essayer de créer ces fichiers en question.
-Pouvoir générer un/des tableaux sur les folios avec :
*numéro de fil
*Dans le cas d'un potentiel comportant qu'un seul fil, afficher dans le tableau les deux élément auquel ce fil est raccordé (idéalement le nom de la borne de l'élément, mais cela n’existe pas encore dans qet)
*Pour les autres cas, le nombre de fils du potentiel + le nom des éléments raccordé.
*Affiché les infos du conducteur.

Fixed in the last commit.
Thanks for report.

Dans ce post seront établie toutes les fonctionnalités de la nomenclature intégré, bien entendue celui-ci n'est pas figé et sera mis à jour au fur et à mesure des discussions.

Tout d’abord je pense continuer à garder (et faire évoluer en parallèle de la nouvelle nomenclature) l'export car peut toujours servir pour par exemple une commande de matériel.

-Choisir de qu'elle colonne affiché ainsi que leurs position.
-Choix de la police (pour les entêtes et le tableau)
-Ajustement auto (taille de la police, position) sur le folio ou manuel
-Afficher la quantité quand une même référence est utilisé plusieurs fois.

pour en revenir à ce sujet : https://qelectrotech.org/forum/viewtopi … 584#p10584
Je pensais faire quelque chose dans le genre (je penche pour le cas N°2), en revanche ce qu'il me pose plus de problème, c'est comment on définie cela sur le schéma ??
Car au final ce sera (pour le cas d'un 3 étages) trois bornes différente sur le schéma mais qui représente un seul élément physiquement.

scorpio810 wrote:

+ champs informations sur la borne, infos qu'il est difficile de mettre en place sur le schéma mais qui doit être présent dans le dessin du bornier à moins que t'ais prévu qu'on puisse y ajouter des textes dynamiques comme avec les anciens borniers?

Non je n'ai pas prévue de mettre en place des textes dynamique (après on peut toujours étudier la question), en revanche c'est tout à fait possible d'écrire l'information comme sur ton folio.

galexis wrote:

Il serait peut-être bien que lors de la définition  du bornier, qu'on renseigne à ce niveau là, la référence et le fabricant des bornes utilisées pour avoir une fois généré la quantité totale de la référence de borne à commander (nomenclature).

Bonne idée.

galexis wrote:

Un truc que ne fait pas le générateur de bornier aujourd'hui, générer les bornier en fonction de l'installation et de la localisation. Si on a -Xc dans +BJ1 et -XC dans +BJ2, le générateur ne fait pas le distingo.

C'est noté.

448

(29 replies, posted in Code)

Because the Xref is update When you move the master.
What you need to do is when you change the alignment properties, you need to force the update of the displayed Xref

Lien de la discussion autour du générateur de borniers.
https://qelectrotech.org/forum/viewtopic.php?id=1486

J'ai relu à plusieurs reprise, mais je t'avoue que je n'ai pas compris nomicons/angel .
Peut-tu ré-expliquer, peut être avec un bout de dessin?