Nuri a bien résumé le problème,
le sommaire n'est plus adapté au nouvel fonctionnalités, et le sera encore moins avec les prochaines.
Il faudra nécessairement passer par une réécriture complète de la fonctionnalité sommaire.

Nuri wrote:

Penser à corriger les fautes de grammaire :

La formule du nouveau potentiel contient des variables incompatibleS avec les reports de folio.

Les variables suivanteS sont incompatibleS :

Étant très médiocre en grammaire, d'habitude je fait relire à ma copine avant de comité, mais pas ce coup ci.
Ça confirme que c'est une erreur de ne pas le faire. nomicons/smile

scorpio810 wrote:

Et bien cela reviendrais à demandé à l'utilisateur de viré %id dans la formule, car il y aura forcement une incohérence entre les folio.

Exactement ! empêcher la liaison de deux conducteurs par un renvoi si ils sont basés sur une formule, quelque soit la .... formule.
Apres c'est à l'utilisateur de corriger, mais au moins il est informé et ça évite de grosses erreurs par la suite.
C'est la solution la plus adaptée il me semble AMHA.

Ok c'est bien ce que j'avais en tête (c'est pas facile de toujours bien expliquer quelque chose par texte interposé).
Et bien je m'atteler à ça.

Ou plutôt détecter si les conducteurs a relier par des renvois sont basés sur des formules, le signaler, et empêcher la liaison tant que les conditions requises ne sont pas valables..

Et bien cela reviendrais à demandé à l'utilisateur de viré %id dans la formule, car il y aura forcement une incohérence entre les folio.
Après si tu veut garder les %id, mais dire "je veut que %id fasse référence au folio X", premièrement il n'y à absolument rien dans le code pour gérer ça, ensuite il faudrait aussi gérer ça dans le .qet.
Bref je sais pas si vous vous rendez compte mais c'est une usine à gaz.
Regardé déjà le temps qu'il à fallu pour réglé tout les problème de %id et compagnie pour les éléments.
Et pourtant c'est plutôt simple (un éléments étant seulement sur un folio) comparé aux conducteurs, qui je le répète, un potentiel peut être sur 10, 20 ou plus folios, c'est obligé de se planter.

Les conducteurs basés sur des formules avec %id (c'est a dire position du folio dans le projet) %id qui peut changer avec l'insertion d'un sommaire. (le management policy peut figer les variables)

Peut changer avec l'insertion du sommaire, mais aussi si on déplace le folios, bref c'est le but de %id, si on veut pas que ça change il y a deux solutions :
-1 ne pas mettre %id, mais un texte fixe.
-2 comme tu l'a dit, le management policy peut figer les variables.

Sinon pour dessiner et câbler rapidement des cartes d'entrée/ sortie c'est un outil qui apporte beaucoup de gain de temps.

Ça se défend, tu peut noter les conducteurs en fonction du numéro de la carte + numéro de l'entré/sortie de la carte genre E2.01 (ce qui est assez fréquent)
Ou alors utilisé entre autre, une variable %id, ce qui je l'accorde peut grandement aider au dépannage.

Captaindoc wrote:
scorpio810 wrote:

Attention avec les renvois et les noms de conducteur basés sur les formules, surtout avec les %id !
On pense d'ailleurs supprimer cette variable dans les formules d'auto numérotation, car elles peuvent vous engendrer de gros soucis par la suite, et ne conserver que celle basée sur le label du cartouche (%F).


Je m'explique, tu as presque fini ton projet, et commencé ou fini le câblage de tes armoires, et tu te dis : zut j'ai oublié de créer un sommaire, ou pire ton projet s’étend et le sommaire crée de nouvelles pages automatiquement, du coup toute ta numérotation conducteurs basé sur %id%seq a changée !
"tes fils nommé 302 (%id%seq) devient 402"

Ce qui n'est pas acceptable et peut produire des schémas faux ! ce que nous ne voulons absolument pas. 

Même si vous pouvez utiliser l'outil de management pour figer les formules et leurs labels.

Au final, rien ne change. Je vous mets le lien du fichier test. %F sur le conducteur change de nom sur le folio d'après. 0209 ---> 03%seqt_1

Bon je vient donner mon avis de dev :
J'avais entrevue le problème il a quelque temps déjà, et il ce confirme.

C'est normal que le texte change car %F est une "variable de folio".
Dans ton cas, dans le folio 2 c'est 2 et dans le folio 3 c'est 3.
Le problème, c'est qu'un conducteur peut être présent sur plusieurs folio alors quand la formule comporte %F on choisis quelle variable ? celui du folio 2 ou du 3 ?
Et encore dans ton cas il n'y a que 2 folios, mais imagine un conducteur présent dans 10 folio, on fait comment???
C'est un problème sans fin, car il y aura toujours un cas de figure qui produira des erreurs.
Bref personnellement j’enlèverais les variables :
%id %F %M %LM %sequf_ %seqtf_ %seqhf_
car ce sont des "variables de folio" et par nature totalement incompatible avec les conducteurs, car peuvent être présent sur plusieurs folio.
Seul les éléments peuvent utiliser ces variables, car ne sont présent que sur un folio.

Voila vous avez mon avis qui est clair : enlever les variables %id %F %M %LM %sequf_ %seqtf_ %seqhf_ pour les conducteurs.

Résolu.
Merci du retour

J'arrive à le reproduire, mais pour ça il faut sauvegarder puis recharger le projet, et la, les textes se trouvent en haut à gauche du folio (j'ai pas regardé, mais à mon avis en position 0,0).
Je regarde ce bug (qui doit pas être grand chose) après avoir fini ce sur quoi je suis en ce moment.

Fixed,
I accidentally removed  a wrong part of sources code in a previous commit

This is the same bug, conductor and all shapes item share the same code for draw the little square use to grab the item, and the crash come from how the square is managed.
I think I need to totally revamp this part of code to avoid this crash.

Want me to put 3) about the %id in the bugtracker?

No need, fixed in commit 4776

...and then, can you also make references in cross referenced Master and Slaves be clickable and work alike?20x20
Pleease? <3 

I agree they will be better, but they need a lot of work, and for the moment we focus on big missing features.
This kind of detail will be fixed after big features, or when QElectroTech get more developeur.

And, all mentionned links in this post, also clickable in pdf export.  Would be reeeally professional to give such "active" documentation to customer!20x22

I already thought about this.
QET use a ready made "export to pdf" class provided by Qt framework.
For use link between Xref in pdf (and more, like summary, bill of éléments ect....), we must to write our own pdf export, and this is a very big work.
Like I say upper, we focus on big missing feature

Now, I can reporduce this bug around 70% of time with your project morganol.
The first strange thing, is that I can't reproduce bug if I follow your procedus.
But if I select the pump and valve move it and delete it, like I say 70% of time a can reproduce the bug.
Bad news, yesterday I spend around 4 hours and I have no idea where this bug come from. It is very very strange.
In the code, when the bug occur, conductor have no QGraphicsScene, the scene have no Conductor, but something call the method paint of the conducteur and I don't know who call this method.

The only good news, I can now reproduce this bug and it's a big step.
 
PS : I want to say "it's a Qt bug" , but this appear only with conductor so "it's a QET bug"

Corrigé avec le commit 4747.
Par contre ce ne sera pas actif sur les conducteurs déjà existants.
Il faudra corriger la valeur avec le dialogue de propriété du conducteur et sauvegarder.
Les réouvertures suivantes n'auront pas de problème.

Si vous voulez plus d'explications faite moi signe.

Be carefull, this commit can solve this crash, but I'm not sure, because we can't reproduce it every time.

The only thing I'm sure, QUndoCommand is now used as recommended by the Qt documentation, and the part of the source code where I make this change is related with the element/conductor/conductor autonum.

Only long test can say if "yes this bug is fixed".
Twist your fingers and hope this bug is an old story

Morganol wrote:

Hooray, i caught a crash: https://qelectrotech.org/bugtracker/view.php?id=98
(a type i have not experienced before, but anyway...)

Crash fixed with commit N° 4736. Thanks for the report

Arf c'est vraiment ennuyeux, ce foutue crash qui arrive lorsque il y a des artefacts de fils ou basic shape supprimé.
Sa m'est déjà arriver en cours de développement mais je n'ai jamais réussi à trouver la source du problème car toujours aléatoire. Et cela fait maintenant un moment que je n'ai pas rencontré ce bug.
N'hésiter pas à remonter toutes les info disponible sur ce bug afin que l'on puisse le régler le plus vite.

692

(113 replies, posted in FR : Aide, suggestions, discussions, ...)

scorpio810 wrote:
nuri wrote:

Peu importe si l'utilisateur emploie des variables ou écrit directement, il ne faut pas faire comme ca !
C'est ce que je voulais dire avec "= et + n'ont rien à faire dans le champ label".
L'idéal serait d'avoir le widget "propriétés de la sélection" comme ceci :

Heuu, là tu nous compliques beaucoup la vie  d'un coup nomicons/getlost, et ça va à contre sens des commits de Davi et des miens.
Je pense qu'il te faudra t'y habituer et faire Label = %M-%LM-M1, et même si je pense que tu as raison et que c'est bien plus logique, le code ne se change pas en trois coups de cuillère à pot. nomicons/smile

Ba pour le coup, vous avez inclue énormément de variable Davi et toi (ce qui est bien).
Mais pour l'histoire des + =, comme je l'avais déjà expliqué cela sera géré par le projet lui même (pas les folios ni les cartouches).
Ainsi si un folio se trouve être dans =G01 +L01, il va de soi que tout les éléments présent dans ce folio le sont aussi (ce qui rend les choses nettement plus rapide que de renseigner individuellement chaque éléments) à l'exception des éléments appartenant à une autre localisation, qui seront déterminé explicitement, par exemple en les entourant d'un cadre.
Du fait, une fois ce système mis en place les actuelles variables de localisation seront inutile (à moins de changer leurs comportement, et d'aller chercher directement les info dans le nouveau système).

scorpio810 wrote:

Revision: 4576
Author:   blacksun
Date:     2016-07-14 13:58:56 +0200 (Thu, 14 Jul 2016)
Log Message:
-----------
ElementsCollectionModel : model use multithreading itself for load collections

Qet utilise maintenant tous vos cœurs CPU pour charger plus rapidement vos gros projets.

Petite précision, il s'agit toujours du chargement des collections d'éléments. Les projets n'utilisent pas le multithreading.

Content de lire ça. La refonte du panel porte ses fruits nomicons/smile

Bonjour,
Merci de nous remonter ce bug, afin de rendre qet plus stable.
Hélas nous n'arrivons pas à le reproduire, ce qui rend très difficile d'en trouver la cause.
Néanmoins, j'ai fait un petit hack sur ma version de développement, et j'ai pu récupéré environ 90% de votre schéma.

Nuri wrote:

Pareil chez moi sous Ubuntu avec l'intel i7-4750HQ, pas le temps de voir le splash. Par contre, le chargement des collections ne se fait plus en arrière plan et je peux maintenant voir la barre de chargement.

Avant, le chargement de la collection se faisais pendant le splash screen.
À présent, il se fait lors de l'affichage de la fenêtre principal, l'utilisateur voit mieux ce qu'il se passe.

Nuri wrote:

Petite différence avec Laurent :
je viens d'installer le dernier build Windows en VM avec Win10. La VM utilisant seulement 2 cores du CPU parmi les 4 disponibles, le chargement est aussi très rapide.
Petite démo :

Tu me rassure, comme Laurent je commençais à me poser des questions (et en plus installé une VM pour tester sous windows.....).

Le prochain commit sera probablement une amélioration des recherches dans le panel d'élément.
Actuellement quand on cherche par ex omron, le champ bloque bloque sur le o puis mron s'écrit plus tard, y'a quelque secondes ou qet mouline. J'ai mis le doigt sur le problème, bientôt corrigé.

Nuri qu'elle est ton thème d’icône sur ubuntu?
C'est la première fois que je voie une icône de qet dans un thème.

scorpio810 wrote:
galexis wrote:

Avec l'autre panel, je n'avais pas de soucis.

Ça m'étonne un peu, ce fonctionnement n'est pas propre au nouvel panel.

Le fonctionnement est le même, mais j'ai retoucher le bout de code qui gère ça (dans la class QetProject). Donc il est possible qu'un bug s'y soit glissé.
Cela dit, ce que montre Laurent dans la vidéo est le comportement normal de QET.

Actuellement la fonction nettoyage ne fait rien.
Elle étais active avec l'ancien panel, mais n'a pas été implémenté dans le nouveau.
J'ai volontairement mis de coté cet fonction "secondaire" (qui reviendra ne vous inquiétez pas) afin de sortir le nouveau panel le plus rapidement possible.

Oui, au premier lancement la bdd est inexistante, donc celle ci est crée et remplis durant le démarrage ce qui effectivement est très long.

Bravo Laurent, c'est une bonne nouvelle nomicons/wink