Search options (Page 12 of 33)

oui

Si la première colonne est composé de chiffres alors c'est trier par chiffre, en revanche si c'est des lettres alors c'est par ordre alphabétique (ce que montre très bien l'exemple de Xander).
Donc dans le cas de numérotation par lettre bien que cela soit lue comme des chiffres par un être humain (1/20, 10/20......2/20, 20/20) ce n'est pas trier dans l'ordre numérique mais alphabétique, cependant je n'explique pas pourquoi d'une installation à une autre le résultat est différent.
A savoir tout cela est gérer par une base de donné sqlite avec une requête sql (je vous laisse chercher sur internet pour ceux à qui cela ne dit rien) et il est possible d'éditer la requête sql donc :
Pour un sommaire "num de folio, titre, auteur, date" la requête est :
SELECT folio, title, author, date FROM project_summary_view ORDER BY folio, title, author, date
il suffit de modifier la requête par :
SELECT folio, title, author, date FROM project_summary_view ORDER BY pos, folio, title, author, date

Noté bien le "pos" après le "ORDER BY" qui aura pour effet de trier le sommaire en premier lieu par la position des folios sans pour autant affiché la position dans le sommaire.

Le champ "Requête SQL" tout en bas de la fenêtre pour ajouter un sommaire ou nomenclature est prévue pour.

Sauf erreur de ma part, je ne voie pas dans qu'elle situation tu peut avoir ça.
Un couple maître/esclave représente physiquement un seul et unique élément.
-Dans ton cas le contacte est, je suppose, un contacte auxiliaire ajouter à ton disjoncteur et donc un même élément avec le même nom (DS), donc cela est normal que sont nom devienne celui du maître c'est le comportement attendu.
-Idem pour la nomenclature c'est deux éléments sur ton schéma mais un seul pour de vrai donc apparaît qu'une seul fois. Dans ton cas d'un module contacte ajouté au disjoncteur, il faut aller dans l'élément maître et renseigner le champ 'Bloc auxiliaire' 1 et ou 2.

@Galexis :
le fichier cinammon.css doit être pour le shell j'imagine, et l'autre ba pour gtk, donc ni l'un ni l'autre.
Je vais regarder ça dans une vm.

Au sujet de la doc cité plus haut.
C'est très intéressant et peut donné des idées. N'hésiter pas à la lire et si des choses vous intéresse venir en parler dans un autre topic.

Great

By the past the attribute was sorted in qet. It was used to check if an element was changed or not by checking the string of the xml.
But Qt changed the way how work the dom xml writer, and the attributes was never write in the same order.
So from this change, we can't check if element was changed or not even if attributes wasn't changed.
This is why we have an 'element definition' uuid. Uuid is much much better for qet (not for git diff).

When you think you've finished your work, I've some ideas to test (if you want to code it of course).

Bon comme quoi en faisant un bout de code à coté pour bien isoler le problème porte ses fruits .
A tester donc si le problème est réglé chez vous aussi.

Est ce que tu utilise un theme sombre pour les aplications Qt ?
Dans tous les cas change de theme Qt, si possible le theme par défaut.
Une petite vidéo sur mon pc.

https://download.qelectrotech.org/qet/f … csitem.mp4

Bon sur la vidéo c'est carrément invisible, mais en fonction du thème ça peut être gris comme toi. J'ai jamais pris le temps de faire un petit bout de logiciel afin d'isoler le problème et faire un report de bug (car je ne pense pas que ça vienne de chez nous ce truc)

Je relance ce vieux sujet, car c'est la prochaine fonctionnalité que je développe.
Il reste encore des choses à voir, est sûrement des choses que l'on aura pas pensé.
Entre autre :
-Faut-il pouvoir (je pense que oui) et comment définir pour les bornes (au sens point de connexion de qet, j'utiliserais ce terme par la suite) si elles sont coté haut/bas armoire/extérieur ? C'est pas facile car un bornier peut être dans une boite de dérive et donc les bornes sont extérieur. Bref vous m'avez compris le but étant de définir explicitement cela afin de bien créer le plan de borne. Attention pas de comportement implicite je sais par expérience que cela pose trop de problème par la suite, en revanche on pourra créer un comportement par défaut.

-Je pense en même temps du générateur de bornier créer un générateur de connecteur (genre prise harting) le code sera probablement partagé car la fonctionnalité reste sensiblement la même :
-Un groupe de bornier par exemple X1 peut tout aussi bien être un connecteur X1.
-Les bornes peuvent tout aussi bien être les pins du connecteur avec pour chaque point de connexion sont type ( mâle " --= )-- " femelle, ou terre,  beau dessin en ASCII art )
-Un ajout par rapport aux borniers sera de définir les deux prises (par exemple coté A est un socle sur armoire et coté B une prise sur câble) puis de définir pour chaque point de connexion si il est sur le coté A ou B (car des prises peuvent être mixé sur un même coté) avec un comportement par défaut (par exemple point de connexion mâle sur B).

Je me répète, mais toutes les propriétés devront être explicitement crée, par le passé nous avons définie (sur d'autre fonctionnalité) des propriétés implicitement et cela à toujours fini par poser des problèmes car une personne voulais le comportement X et une autre personne voulais le comportement Y, au final grosse rustine dans le code incompréhensible car pour des cas bien spécifique + création des propriétés explicitement.
En revanche on pourra mettre en place des comportements par défaut afin de minimiser le paramétrage manuel car bien souvent c'est toujours la même chose.

Je ne me fait pas trop de soucis pour la représentation du plan de bornier, car comme sont nom l'indique c'est une représentation donc si tout est bien définie au préalable ce qu'il reste à faire est "juste" du dessin.

Retour sur la 4g.
SFR n'a pas de technicien ? (c'est une vrai question)

Something like this could be a solution ? (it's just a proof of concept). I can add it to the roadmap.
https://download.qelectrotech.org/qet/f … g/cote.mp4