Search options (Page 17 of 33)

Thanks a lot for this good work.

Désolé, mais j'ai plusieurs questions afin de bien comprendre l'ensemble avant de coder quoi que ce soit.

Je ne comprend pas quand tu dit multi-marque ? C'est à dire que l'imprimante accepte n'importe quel type de support pour imprimer ?

Quand tu parle des codes sw, visiblement les imprimantes brady n'en on pas besoin (probablement car on ne peut imprimer qu'un seul type d'étiquette à la fois) et pour wago et phoenix contact, je ne sais pas mais nous n'avons jamais eu de retour dans ce sens.
D’où ma questions quand tu dit

Tu parle de marque d'imprimante ou du logiciel de dessin ? Je pensais que les codes servais à l'imprimante de savoir sur quel support imprimer (un repère de fil n'ayant pas le même support qu'un bornier).

Au vue des deux fichiers que tu nous as envoyé, je comprend les 1h45 passé dessus.
En tous cas, pour l'export au format tableur (donc avec les codes) de mon coté je peut te sortir directement un fichier exploitable par ton logiciel d'imprimante (ton fichier retravailler donc), il me faudra juste les codes les plus utilisé (attention rien n'existe actuellement pour définir la section de fil dans qet).

Au sujet du fichier fnr, j'ai trouvé ça : https://docplayer.fr/10627620-Manuel-ut … lmark.html visiblement c'est un format de fichier crée par IGE/XAO, si quelqu’un pouvais me trouver les spécifications de ce format cela m'aiderais grandement à implémenter ça correctement.
Autrement quelque explication seront necessaire.

Fin des questions il y en aura probablement d'autres par la suite, mais c'est pour bien préparer le travail.

Bonjours robertpire,
merci pour ces précieuses informations

Quand vous parlez d'un fichier excel, qu'elle est l'extension de ce fichier ? csv ? le mieux serais même de me fournir un de ces fichier. (excel étant un logiciel et non pas un type de fichier).
Pouvez vous me fournir l'ensemble des codes ou encore mieux, un lien à ce sujet.

Pour le fichier fnr, vous avez de la chance il s'agit d'un simple fichier texte (je craignais que ce soit du binaire) et de plus très facile à lire.
J'aurais quelques questions à sont sujet mais j’attends d’abord votre réponse au sujet du fichier "excel".

Dans tous les cas je pense pouvoirs créer ces fichiers avec Qet.
A+

Quelque nouvelles,
-Le chargements des collections d'éléments s’effectue dorénavant grâce au parseur pugixml (le parseur Qt à été définitivement enlever de cette partie du code), le gain de temps lors du chargement est considérable, en revanche je ne peut pas donner de benchmark car cela dépend beaucoup de votre configuration matériel (nombre de cœurs, disque dur vs ssd ....) et de votre OS (Linux en tête), cela dit vous pouvez comptez un minima de 30% plus rapide.
Le revers de la médaille (pour des raisons technique)  qet consomme plus de RAM, ~100Mo supplémentaire sous Windows (probablement macOS aussi), puis un peu plus lors de l'utilisation (tout OS confondue) +100Mo sur un projet de 70 pages.
Ce "mauvais coté" pourrais faire l'objet d'un travail afin de diminuer la conso, mais on verra ça plus tard , après tout 200Mo sur nos config actuel....

-En parallèle, le chargement des collections a été retravaillé afin que celui-ci ne freeze plus QElectrotech lors du chargement. Ça ne change rien à la vitesse de chargement, mais c'est plus sympa d'avoir un logiciel qui ne freeze pas.

Great, thanks a lot Unalcade.

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).

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é.

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

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.

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.

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.

@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.

T'inquiète pas, ce sera fait

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....

Double clic -> OK

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
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é.

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

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é).

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.