Search options (Page 26 of 33)

Je pensais bien faire ainsi

Je m'avance un peu, mais crée un petit dialogue pour configurer l'export ne me demandera pas trop de temps. De plus je pense qu'un export peut toujours être intéressant pour sortir une liste de matériels en dehors de QET.
Après je suis 100% d'accord avec toi que QET sache faire ça nativement.

C'est déjà le cas. Tu veut dire dans le widget des propriétés?

Tu dit au minimum : Fabricant, référence, numéro de commande et petite description.
Ensuite tu dit "le client se débrouille avec sont fournisseur".
Mais le numéro de commande, c'est bien un numéro propre au fournisseur. Du coup tu devrais juste avoir à renseigner Fabricant, référence, et petite description.
Je me trompe ?
J'avoue n'avoir pas trop réfléchie au truc, je suis comme Laurent, quand je refais un schéma éléc, je renseigne uniquement le nom du fabricant, la référence "fabricant" du produit et un petit texte d’explication.

C'est le comble, je suis le développeur, mais j'utilise pas souvent QET dans mon boulot, et encore moins de manière aussi poussé que vous

Ok donc ce serais mieux si le combo box proposais toute les variables, même si elles ne sont pas renseignées.

Autrement dernier commit : il est possible d'ajouter un cadre autour des nouveaux textes.

Heu si, toutes les variables sont dispo, le combo box ne te propose que les variables des champ déjà renseigné.

Hop petite amélioration de la GUI,
les listes déroulante sont plus naturel.
Le dialogue pour éditer les champs composé a le focus lors de sa création = plus besoins de cliqué dessus, vous pouvez directement écrire.

Arrête, je vais prendre la grosse tête, de plus Qt facilite bien les choses.

Oui c'est bien ça.
Par défaut (Qt) le point d'origine est le coin supérieur gauche, avec les textes de QET, celui-ci a été déplacé au milieu du coté gauche.
Du coup il est a réévalué quand on change de taille de police, saut à la ligne etc....
J'ai préféré laisser comme c'est par défaut, car implique moins de code, et ne change rien à l'utilisation.

Pour le problème des textes, je n'ai pas réussi à le reproduire.
Vous avez une petite procédure.

Pour les divers comportement des widgets dans l'arbre des textes d'élément, faut que je peaufine tout ça, mais c'est pas toujours simple.

Tu est sure qu'elle apparaît quand elle veut ?
En fait le truc est un peu vicieux, quand le dialogue s'ouvre il faut cliquer dans le champ prévu pour écrire, si tu clic ailleurs le dialogue perd le focus, ce qui est interprété comme la fin de l’édition du dialogue, du coup celui-ci se ferme.
J'ai même déjà vue d'autre truc chiant, que je n'ai pas résolut pour l'instant.

Cher utilisateur de QET, je viens à toi, afin de demander ta précieuse aide. Mais en prérequis, il faut que tu ais déjà fais mumuse avec les "nouveaux textes dynamiques"
Comme je l'avais déjà mentionné dans les précedents posts, les "anciens" textes avec tagg, ne sont (pour l'instant) pas convertis en texte dynamique, et voila pourquoi :
Actuellement, avec les anciens "textes" dans l'éditeur de schéma, dès lors que le commentaire de l'élément est renseigné et que celui-ci est coché, le commentaire apparait dans un encadré sous le label ou Xref de l'élément en question.
Je trouve que ce comportement fait doublon avec les nouvelles possibiltés offertes par les "nouveaus textes dynamiques", car il est possible de créer un texte avec comme source de texte "commentaire".
Je me pose donc la question suivante, faut-il garder ou non, les commentaires "automatiques" dans un encadré ?
Dans le cas ou la réponse serait non, la nouvelle façon de faire serait d'ajouter un "nouveau texte dynamique" avec comme source de texte "commentaire".

Je vous laisse débattre

Une autre chose, trouvez-vous utile d'ajouter la fonctionnalité suivante :
Grouper ensemble les (nouveaux) champs textes d'un même élément.
Par exemple, vous avez 3 textes => grouper = agit comme un seul et même texte.
L'avantage par la suite, serait d'ajouter les fonctionnalités suivantes : Alignement gauche/centré/droite des textes d'un groupe.
Attention, je n'ai encore rien codé sur ce sujet et je ne sais pas encore la difficulté du truc. Donc je ne vous fais aucune promesse.

Non,
texte = c'est un champ texte avec aucune interaction dans l'éditeur de schéma, c'est une partie de dessin de l'élément. Donc n'est pas converti, et ne le sera jamais.

Champ texte = oui ils sont convertis, à l'exception de ceux qui on un tagg pour l'instant.
Une fois qu'ils seront tous convertis, le bouton  "ajouter un champ texte" disparaîtra pour ne laisser que le bouton "ajouter un champ texte dynamique".

Champ dynamique = ba pas de conversion

Pouvez vous me citer les cas ou vous avez besoins de rechercher du texte ?

Oui, j'ai repéré le problème (sans même ouvrir le code ), quand les taggs de textes sont arrivés dans QET, tous les éléments de la collection officielle n'ont pas été taggé (vous imaginez le nombre d'éléments à se tapper à la main...) du coup pour palier à ça, quand on dépose un élément qui n'a pas de texte avec le tagg "label", on prend le premier texte de l'élément et on lui assigne d'office le tagg "label", c'est le cas pour les reports de folios......
Et comme maintenant, les textes sans tagg sont convertis en texte dynamique, vous connaissez la suite.....
Je regarde pour corriger ça le plus rapidement possible.

Il y a longtemps que je voulais faire un truc, mais ce coup-ci, il va falloir le faire :
Dans l'éditeur d'élément créer une fonction qui met à jours tout un répertoire d'éléments, afin que ceux-ci soient conformes avec les dernières spécifications.
Cela évitera un travail toujours plus long (la collection s'agrandit sans cesse) de mise à jours "à la main".

Oui y'a pas de problème

Oui, voici les différents liens qui en parlent :
https://forum.qt.io/topic/71316/qgraphi … removeitem
https://stackoverflow.com/questions/384 … item-class
http://www.qtcentre.org/archive/index.php/t-33730.html
http://tech-artists.org/t/qt-properly-r … items/3063
Dans l'un des forums, il est clairement dit :

Plusieurs choix m'étaient disponibles, j'ai choisi celui qui me semblait le plus propre, c'est-à-dire d'appeler la méthode
SetItemIndexMethod avec comme argument "NoIndex" au lieu de "BspTreeIndex".
Actuellement, la correction est disponible uniquement sur la 0.7 dev.
Si il n'y a pas de retour négatif, la correction sera retro-portée sur la 0.6.
D'après la doc Qt, il ne devrait pas y avoir de ralentissements, voir peut-être même le contraire car "NoIndex" est plus adapté aux scènes avec des items qui sont souvent ajoutés, déplacés ou supprimés.
http://doc.qt.io/qt-5/qgraphicsscene.ht … ethod-enum