Search options (Page 40 of 55)

galexis wrote:

Yes ! Super rapide !  

Pour le test j'avais fait les changements en dur dans le code, mais Davi aura été plus rapide : il propose en plus un bouton permettant de switcher les XREfs à la volée du mode classique basé sur l'index des folios au mode basé sur le nouveau label folio.  

galexis wrote:

Je me pose la question du positionnement du texte : si texte à rallonge du genre "=ARMOIRE", est-ce l'xref ne risque pas de chevaucher le symbole ?

Oui, tu fais bien, un texte long est tronqué car alignement droit, si je me rappelle bien à cause des références en affichage en mode croix, il faudra regarder ça de plus prés.

Nuri wrote:

scorpio810 wrote:

Ajout de folios non conséquents par leur numérotation, possibilité de numérotation avec des lettres et des caractères */=- +, etc

C'est bon ca ! c'est Galexis qui va aussi être content !

Ça risque d'être très utile, exemple : on doit modifier les schémas d'un ancien projet papier (fait avec un autre logiciel) et donc redessiner les folios puissance : {178,179}  et commande : {203, 204} de ce projet !

Tu n'auras plus besoin d'utiliser de tours de magie et de workaround, et de copier péniblement des Xrefs, renvoi, etc à la main, juste besoin de créer tes 4 folios, ajouter la variable %autonum sur le projet, renommer tes folios ou te servir du widget règles de folio pour les créer, tes XRefs, renvois de folios, etc ne seront plus basés sur le numéro d'index folio dans le projet mais liront ce nouveau %autonum/%id du cartouche.

Le but de Davi c'est d'ouvrir la voie vers une numérotation automatique d’éléments, de câbles, etc suivant la localisation: tes =+-, etc.

Bonjour f.franck,

je vais laisser Nuri t'expliquer sa méthode, mais aussi ses inconvénients.
Un nouveau développeur nous a rejoint "Leonardo", nous sommes en discutions avec pour la mise en place coté utilisateur d'une base de données pour stocker justement ces informations dans des tables, afin d’éviter d'avoir à chaque fois à les re rentrer dans le dock.

scorpio810 wrote:

en plus de réduire la consommation RAM.

Alors oui, la conso ram devrait beaucoup baisser, mais le panel d'élément n'est qu'une partie du problème, après avoir fini le panel d'élément (qui est déjà bien avancé), il reste la partie immergé de l'iceberg...

Nuri wrote:

scorpio810 wrote:

Regarde les liens sur la doc Qt qabstractitemmodel, The model/view architecture.

wi wi, j'ai déjà mangé ca :
https://openclassrooms.com/courses/programmez-avec-le-langage-c/l-architecture-mvc-avec-les-widgets-complexes
La doc Qt je commence à comprendre, ca me paraît pas impossible. Le problème c'est les lacunes C++... Que dis-je... les trous noirs en C++.

La finalité du nouveau panel sera-t-elle aussi d'intégrer l'arbo du projet dedans ou non ?
Pour l'instant, les onglets ca me va bien.
Euh.. je vais formuler autrement :
Est-ce qu'à terme les projets seront dans le même QDockWidget que les collecs ou dans un autre ?

Même question .... ;-)

La collection d'élément restera seul dans sont QDockWidget, l'arborescence du projet sera dans un autre QDockWidget, surtout quand il y aura les =/+, ce sera pas superflus.

scorpio810 wrote:

Oui, avec des onglets, mais surtout une plus grande facilité d’insérer un nouveau folio là ou l'on le veut, voir même un déplacement d'un ensemble de folios, pouvoir aussi découper l’arborescence du projet en sous dossiers comme sur ton Eplan adoré.
Mais bon, je m'avance un peu, seul Joshua travaille dessus, et est à même de vous répondre correctement de ce qu'il sera possible de faire, ou pas.

Du point de vue de l'arbre (QTreeView) beaucoup de chose sont possible (je dit pas que c'est toujours simple à coder). Mais la plus grosse difficulté sera de créer un "cahier des charges" et de mettre ça en œuvre dans QET, car comme à dit nuri, "ça sous entend de refaire tout le système des ref croisées" mais pas que...

OK !
J'avais pas vu qu'il y avait 2 panels pour les éléments. "Panel d'éléments" est destiné à disparaître ?