Merci pour votre réactivité Laurent et Joshua !
Je testerai lors d'une prochaine utilisation.
526 2015-10-30 10:13:44
Re: Erreur Version 0.5-devel+svn4242 (8 replies, posted in FR : Aide, suggestions, discussions, ...)
527 2015-10-28 10:52:29
Re: Gestion des données d'articles (5 replies, posted in FR : Aide, suggestions, discussions, ...)
Hi Aleksandr,
I think you are misunderstanding the subject of the topic.
I've opened this topic in order to collect all ideas about :
how to manage article data in QET for future developments ?
Article data are the informations we need to identify electrical gears that can be buy from industry reseller.
At the moment, we can enter these informations in the fields "designation", "manufacturer" and "manufacturer reference" in each element that is on the wiring diagram. But we have to type them in each element and this is sometimes a lot of work.
So, how could we improve the management of these data ?
Do we need a database ?
If not, how could be the article data linked to the "manufacturer articles" elements of the QET collection ?
528 2015-10-28 10:37:02
Re: Plantage trop fréquent (19 replies, posted in FR : Aide, suggestions, discussions, ...)
cette nuit au boulot : suppression d'un contact esclave, le conducteur reste encore affiché, bon je sauvegarde et a la ré ouverture c'étais bon.
C'est exactement le comportement que j'ai également observé. En fait, le conducteur se comporte comme s'il était effacé : on ne peut alors ni le sélectionner ni le déplacer. Mais il reste affiché.
Un redémarrage de QET supprime définitivement le conducteur récalcitrant. Peut-être que cela à voir avec l'affichage de la scène ?
Quand aux problemes de suppression de renvoi déjà liés j'arrive à planter Qet sous Win7 et même sous ma Sid à jour (avec Qt 5.5.1 mais c'est déjà plus dur) à force de supprimer des renvois et de sauvegarder, comme un sauvage ....
Pareil. J'arrive à reproduire le crash systématiquement :
supprimer des renvois liés et sauvegarder, et supprimer des renvois liés et sauvegarder, et supprimer des renvois liés et sauvegarder... et pouf... c'est le crash.
529 2015-10-27 13:59:36
Re: Création tableau répartition (4 replies, posted in FR : Aide, suggestions, discussions, ...)
Salut Ahocine,
Y'a moyen de faire des tableaux et des mises en armoire avec QElectroTech.
J'ai eu l'occasion de tester sur un cas concret d'armoire électrique pour une machine CNC.
Ca demande un peu de travail préalable, mais après, ca marche vraiment bien.
Je t'ai mis un exemple en pièce jointe comme ca tu peux voir dans les détails comment c'est fait.
Pour faire les plans de mise en armoire, je pars du principe que 1pixel = 1 mm, ca semble très bien pour dessiner des armoires standards de 2m de haut avec socle.
Le folio est configuré en 3552x2328px (24 colonnes x 148 px et 24 lignes x 97 px). Donc toutes mes vignettes sont dessinées sur la base 1px = 1mm.
Exemple : si j'ai un relais qui fait 45mm de large et 68mm de haut, je crée une vignette 45x68px.
Par contre, pour dessiner des petits coffrets muraux ou des petits boitiers de répartition, il faudra vraisemblablement diviser la surface du folio par 4, ce qui nous donne 1776x1164px, soit 12col x 148px et 12lig x 97px.
De cette facon, on peut toujours utiliser les mêmes vignettes 1px = 1mm, pas besoin de créer des vignettes 2px = 1mm.
Evidemment, pour chaque folio de dimensions différentes, il faut créer un cartouche proportionnellement adapté (taille des cellules et des polices). Et ca passe nickel, en sortie pdf, on y voit que du feu :-)
530 2015-10-23 09:18:34
Re: QElectroTech v0.5 beta released (36 replies, posted in News)
Il y a un petit défaut de couleur dans le dernier splash screen (sur la partie droite, le bleu le plus foncé descend sous les textes turquoises, ce qui n'était pas prévu à la base).
Crash :
Il m'est déjà arrivé plusieurs fois que QET crash quand j'efface un report de folio lié à un autre.
Je n'arrive pas à reproduire le problème systématiquement, je peux simplement constater que cela s'est déjà produit plusieurs fois.
531 2015-10-21 12:58:28
Topic: Gestion des données d'articles (5 replies, posted in FR : Aide, suggestions, discussions, ...)
Salut à tous,
après une longue pause estivale, je me remets lentement mais sûrement à mon travail.
Avec ce post, j'ouvre un topic dédié à la gestion des données d'articles. L'utilité de ce topic est de rassembler toutes les idées pour permettre, un jour, de gérer des données d'articles dans QET.
Que sont les données d'articles ?
Grosso-modo, ce sont les données qui permettent d'identifier du matériel électrique disponible le marché.
Soit les champs "désignation", "fabricant" et "référence fabricant" des éléments.
Pour le projet de machine CNC que j'ai réalisé au printemps, j'ai eu besoin de créer des articles constructeurs (Bosch Rexroth, Eaton, Phoenix, etc.). Pour me faciliter la tâche, j'ai écris les données d'articles, non pas dans les champs dédiés des éléments posés sur le schéma, mais directement dans le nom des éléments lors de leur création avec l'éditeur d'éléments.
Ainsi, les données d'articles étaient directement intégrées aux symboles.
Aujourd'hui, avec le recul et l'expérience, j'affirme que CE N'EST PAS UNE BONNE IDÉE de lier les symboles et les données d'articles.
Pour ma machine CNC, j'ai dû réaliser quelques modifications au cours de l'été et j'ai alors constaté que le système que j'avais mis en place n'était pas pratique du tout. Exemple :
sur un folio de répartition de potentiel 24VDC, j'ai placé disons 40 bornes simple étage. Quelques semaines plus tard, mon client m'informe qu'il a préféré acheter 20 bornes double étage.
J'ai du alors effacé toutes mes bornes simples étage (car les données d'articles étaient alors fausses), créer 20 nouvelles bornes double étage, refaire toutes les liaisons de conducteurs en prenant soin de garder les numéros de conducteurs tels qu'ils étaient, etc. Bref, ca m'a coûté pas mal de travail.
Ma conclusion c'est qu'il ne faut pas lier de manière irréversible les données d'articles aux symboles. Quand un élément est placé sur le schéma, il faudrait toujours avoir la possibilité de lui attribuer d'autres données d'articles.
532 2015-07-21 18:29:48
Re: Liaison mécanique et zône rectangle en couleur (25 replies, posted in FR : Aide, suggestions, discussions, ...)
Apres je sent venir les demandes du style : remplissage des basic shapes avec des couleurs.... ne revez pas, c'est pas la peine, c'est niet d’emblée!
...mmm... avec un petit travail au corps pendant quelques mois...
533 2015-07-21 18:26:01
Re: New graphics processing tools (1 replies, posted in News)
FRANCAIS:
Petites précisions :
Le fichier QElectroTech_macros_V02.ods est, comme son nom ne l'indique pas, destiné à créer des tableaux de nomenclature sous forme d'éléments que l'on peut insérer depuis sa collection personnelle.
La macro est encore au stade de bricolage et il est facile de la faire planter, mais elle fonctionne.
La macro ne fonctionne pas encore sous Windows. Toutefois, j'ai fait quelques essais en modifiant des petites parties du code et elle a fini par tourner sous Windows. Cette version n'a pas encore été rendue publique.
Pour l'instant, je n'ai créé aucune documentation. D'une part, parce que le fonctionnement est simple, d'autre part, parce que j'ai pas le temps pour le moment
ENGLISH:
a few explanations:
as its name doesn't indicate, the file QElectroTech_macros_V02.ods is intended to create parts list tables (known as "nomenclature" in QET) as elements that can be drag&droped from your user collection into the folio.
The macro is still in a "rush job" stand and it's easy to crash it, but it runs.
It doesn't work on Windows yet. However I've tried it with small changes in the code and it can run on Windows too, but this version had not yet been made public.
I have not wrote any documentation at this time. On one hand, because it's easy to understand how it has to work, on the other hand, because I've no time these days
534 2015-07-19 10:12:30
Re: Liaison mécanique et zône rectangle en couleur (25 replies, posted in FR : Aide, suggestions, discussions, ...)
Je ne suis pas convaincu de l’intérêt de la chose..!
Evidemment, ces options ne seraient pas destinées à faire les choses représentées dans tes exemples. Dans ce cas, je ne suis moi non plus pas convaincu de l'intérêt de la chose
Je pensais plutôt à des folios de type graphique, genre mise en armoire ou plan d'implantation. Et même si ce ne sont pas des schémas électriques, ces folios sont quand même très importants dans une documentation.
535 2015-07-16 11:04:25
Re: Liaison mécanique et zône rectangle en couleur (25 replies, posted in FR : Aide, suggestions, discussions, ...)
...euh non, sur tous les types de traits, exactement comme dans l'éditeur d'éléments !
Pourquoi être aussi limitatif si (et seulement si) ces fonctionalités peuvent être implémentées aisément ?
(je sais, pour pas faire des schémas avec des basic shapes)
Après, je dis pas que c'est le truc indispensable dont j'ai besoin 30 fois par jour...
Tu peux peut-être aussi voir les choses de cette manière :
Plus c'est facile de dessiner avec QET, plus le logiciel est autonome et indépendant. Donc de moins en moins besoin d'insérer des images ou de travailler avec du dxf en externe. Surtout qu'avec les nouvelles poignées sur les basic shapes, le dessin devient nettement plus aisé.
Pour par exemple dessiner des apercus de machines (comme dans le "parc à bois" sur les folios où tu montres la localisation de tes capteurs/actionneurs avec des images embarquées).
536 2015-07-16 09:00:42
Re: New floating dock is now ready, news colors, patterns, etc. (94 replies, posted in News)
D’après la documentation winrelais, il y a la méthode française et suisse...
Sans oublier la méthode bavaroise et la méthode esquimaux
Plus sérieusement, je pense que l'auteur de WinRelais s'est fixé sur un truc qui n'a pas vraiment de caractère universel.
En revanche, ce dont on est sûr, c'est que chaque bornier à un nom et que chaque borne à l'intérieur d'un bornier à un numéro. Point barre.
Plus tard on pourra discuter sur les options de génération, par exemple "générer des bornes réserve", etc...
Qet avec ces classes peut déjà connaitre les conducteurs branchés sur la borne et leurs numéros de fils.
Est-ce qu'il faudra aller jusqu'à connaître le label de l'appareil à l'autre extrémité du conducteur ?
537 2015-07-16 08:36:59
Re: Liaison mécanique et zône rectangle en couleur (25 replies, posted in FR : Aide, suggestions, discussions, ...)
Apres c'est clair, on peut pas empêcher de mal utiliser un soft surtout à des personnes qui ne prennent pas le temps de lire la documentation.
Ben ouais...
Je vais le rajouter dans la todolist, car beaucoup aussi demandent cette fonctionnalité.
Tant qu'à faire, y'aurait aussi moyen de pouvoir régler l'épaisseur des traits comme dans l'éditeur d'éléments ?
Moi je fais surtout du noir et blanc donc le type et l'épaisseur des traits sont plus importants que les couleurs.
538 2015-07-15 15:38:50
Re: New floating dock is now ready, news colors, patterns, etc. (94 replies, posted in News)
Dans mon esprit au début, je me disais que par "convention" ou habitude du dessinateur, les chiffres paires seraient sur l'étage de devant et impaires derrière. Ensuite, utiliser le bon numéro de borne dans ton exemple : chiffre paire pour le 24V et impaire pour le 0V. Mais effectivement, pouvoir le préciser serait peut-être plus sûr.
Comme je travaille depuis 13 années en tant que prestataire de service pour plusieurs branches de l'industrie, je peux affirmer, sans trop me mouiller, que ce genre de "conventions" n'existe pas. Ce ne sont, dans le meilleur des cas, que des habitudes de conception intra-entreprise.
J'ai même eu des clients qui donnaient des lettres aux bornes (A, B, C, D...). Ou alors des systèmes alphanumériques : a1, a2, a3, b1, b2, b3...
Donc, pour le développement de QET, nous serons obligés d'admettre que le "numéro de borne", ce n'est rien d'autre qu'une chaîne de caractères, ni plus, ni moins, et sans autres précisions.
Sinon, on ne fait que des solutions trop personnalisées et ca ne fait pas avancer le logiciel
Personnellement, je peux facilement faire l'impasse sur les bornes multi-étages. Ce n'est vraiment pas la priorité du moment. Mais c'est bien de garder les idées sous le coude...
Est-ce que tu ouvres un post à part pour ça ? Les câbles et les bornes ... quoi d'autre ?
oui, désolé, mes posts partent dans tous les sens
Et oui, j'ouvrirai certainement un topic juste pour ca, mais pas pour l'instant car j'ai encore rien de présentable.
Sinon, en plus des bornes et des câbles, je verrai bien aussi les entrées/sorties d'automate pour faire des apercus automatiques en post-traitement (dingue le temps que ca prend de faire ca à la main !).
Eventuellement les connecteurs (type Harting ou Ilme) mais c'est vraiment très secondaire, j'aurai même tendance à laisser tomber cela.
Et puis la gestion des données d'article, même si cela ne définit pas un type d'éléments mais plutôt des propriétés supplémentaires.
539 2015-07-15 13:04:45
Re: New floating dock is now ready, news colors, patterns, etc. (94 replies, posted in News)
Des types d'éléments définissables: moi ça me va bien ! J'adore quand on peut faire à sa sauce !
Je pensais pas à des choses trop personnalisables où chaque utilisateur définit ce qu'il veut. Ca me paraît trop flou et ca complique l'apprentissage de QET.
Je pensais plutôt à des types d'éléments qui affichent de manière claire et transparente leurs attributs (et donc avec un minimum de choses codées en dur).
Par exemple, je définie un élément de type "borne". Quand j'ouvre son widget, les champs de données à disposition sont :
- nom du bornier (et non plus "label")
- numéro de la borne (et non plus "commentaire" ou autre...)
- etc...
Faudrait une maquette pour être plus clair...
Parce que si chacun défini ses éléments et ses attributs comme il l'entend, cela rend les opérations de post traitement encore plus compliquées à réaliser. Sans compter la diffculté pour faire la documentation et les fichiers d'aide de QET.
D'où l'intérêt de définir un "socle commun" d'attributs qui vaut pour tous les utilisateurs de QET.
Pour les bornes : est-ce bien intéressant de savoir l'étage (tu parles bien des bornes étagées ?) ?
Oui je parle bien des bornes étagées.
Ben... Par exemple :
Dans tes schémas, tu dessines une répartition de potentiel 24VDC. Admettons que les bornes numérotées de 1 à 10 soient les bornes 24V et les bornes de 11 à 20 soient les bornes 0V.
En construction, on met une barrette pour ponter les bornes 1 à 10 et une autre barette pour ponter 11 à 20.
Donc les bornes 1 à 10 doivent être sur le même étage, disons supérieur, et les bornes 11 à 20 également, disons inférieur (sinon pas de barettes !) .
En post traitement, comment savoir que 1 à 10 sont en haut et 11 à 20 sont en bas ? Ou inversement ?
Quand tu dis amont/aval, tu penses à quoi ?
Je pense à ceci :
Si dans les schémas il n'existe aucune information pour discerner le côté amont ou aval d'une borne, comment savoir automatiquement en post-traitement s'il faut raccorder le cable -WS1 en haut ou en bas des bornes ???
540 2015-07-15 11:03:22
Re: New floating dock is now ready, news colors, patterns, etc. (94 replies, posted in News)
A mon avis, c'est jouable avec LibreOffice d'exploiter le fichier XML du projet et d'en extraire les label et les numéros de bornes associées, puis d'aller chercher les numéro de conducteurs. Pour le moment, rien vu d'intéressant sur le net.
mouais, en principe... dans la pratique bonjour le boulot avec les recherches sur chaînes de caractères
Autant apprendre tout de suite le Qt/C++, ca ira plus vite et ca aura plus d'avenir !
Ce qu'il faudrait apprendre à maîtriser, ce sont les filtres XLST pour convertir le XML d'un projet QET en XML compréhensible par LibreOffice. Là, couplé avec des macros, ca commencerait à devenir intéressant.
Mais on en avait déjà parlé et finalement, personne ne s'y est mis sérieusement.
Revoir le topic suivant :
http://qelectrotech.org/forum/viewtopic.php?id=438
Sinon, y'a aussi un convertisseur xml vers csv que j'ai essayé :
https://code.google.com/p/xml2csv-conv/
Résultat : bof... je vois pas comment on pourrait s'en servir. Ca ne fait que rajouter une étape de conversion supplémentaire dont on aimerait bien se passer. En plus on perd l'arborescence du xml originel.
Effectivement quelques propriétés à ajouter au bornes: comme tu le dis parents/enfants ou juste avec le label et un séparateur, cela ne me choque pas (winrelais utilise cette méthode).
Tiens, en parlant de séparateur, est-ce qu'il serait possible que nos amis francais de France utilisent le séparateur prévu par la norme internationale, c'est-à-dire ":" et non "." ?
Si j'ai un bornier -X01 avec 3 bornes (1, 2 et 3), cela nous donne :
-X01:1
-X01:2
-X01:3
Et si j'ai un bornier -X21.2 avec 2 bornes (L1 et L2), cela nous donne :
-X21.2:L1
-X21.2:L2
Le vieux Eplan 5.70 utilisait aussi cette méthode : [nom du bornier] + [séparateur :] + [numéro de la borne].
Maintenant, avec le nouveau Eplan P8, ils ont séparé [nom du bornier] et [numéro de la borne] en 2 champs de donnée bien distincts, ce qui est, à mon avis, la solution à préférer car cela limite un peu les erreurs dues aux fautes de frappe.
Il faudrait aussi un moyen de dire si c'est une borne de terre : une case à cocher dans le widget ?
Si y'avait que ca...
Faudrait aussi une case pour indiquer l'étage de la borne, le côté amont/aval, etc...
Joshua parlait de créer une nouvelle classe Qt/C++ pour définir des types d'éléments (câbles, bornes, E/S d'API...). De cette manière on pourrait définir des attributs propres à chaque type d'élément.
Mais pour éviter de transformer QET en usine à gaz, il faudrait garder à l'esprit ce qu'on veut faire.
Pour l'instant, le plus facile serait de pouvoir exporter un maximum de données en csv.
Si vous êtes motivés, on peut faire une liste des types d'élément qu'il faudrait créer et, pour chaque type, définir tous les attributs dont on peut avoir besoin. Un peu comme un brainstorming : sans faire de jugement à priori.
Une fois que la liste est établie, on discute des choses utiles et inutiles pour voir comment cela pourrait être implémenté.
541 2015-07-14 10:41:05
Re: New floating dock is now ready, news colors, patterns, etc. (94 replies, posted in News)
Unifier les macros: c'est une bonne idée, mais je pense que tu vas prendre peur en voyant le code! Car je n'ai pas créer de macro dédié au bornes, mais modifiées celles existantes.
Pas trop grave, faut juste renommer les "Sub" et faire attention à ce que les variables "Public" ne soient pas utilisées dans tous les sens.
J'ai fait un petit essai sous Windows et la macro plante à cause des chemins de répertoire.
Donc, faudra aussi légèrement adapter les macros pour qu'elles tournent aussi sous Windows. Ca devrait pas être un boulot énorme.
Petite question: comment sont représentées les bornes doubles et sont-elles représentées habituellement ? Au boulot il y en a jamais ....
Tu veux dire les bornes à plusieurs étages ?
Je verrais bien les choses comme ca :
Mais créer ca à partir du csv, ca va être du sport...
Pour les câbles : cela me parait compliqué. A réfléchir ....
Peut-être pas tant que ca... J'ai quelques pistes mais encore rien de finalisé.
Pour l'instant, je dessine mes câbles comme ceci :
542 2015-07-14 08:35:15
Re: New floating dock is now ready, news colors, patterns, etc. (94 replies, posted in News)
Super Galexis !
En ce moment, je suis sur un petit projet à faire sur QET. Ce projet est tellement petit que ca ne valait pas le coup pour moi d'écrire une macro pour créer les borniers (quand ca va plus vite à la main, hein...).
Ben pour le coup, je pense que je vais utiliser ta macro. Faudra juste que j'adapte un peu à mes besoins.
Si j'ai le temps, j'essairai d'unifier les macros dans un seul et unique fichier ods à partir duquel on peut générer les tableaux de nomenclature et les borniers.
Même si tout ce travail avec les macros risque de devenir obsolète un jour ou l'autre, il a au moins le mérite de nous montrer clairement quels sont les attributs qui manquent encore aux éléments et de quelle facon ils pourraient être implémentés.
Prochaine étape : les câbles ?
543 2015-07-09 08:14:48
Re: New floating dock is now ready, news colors, patterns, etc. (94 replies, posted in News)
Effectivement, pour que les bornes apparaissent dans la nomenclature, j'ai modifié la borne en élément simple. Ensuite, trie par le mot borne. J'ai aussi pensé à trier sur "X"... mais comme tu l'as dis, c'est pas idéal.
Disons qu'avec les macros LibreOffice on peut se faire des petits programmes bien personnalisés qui marchent plutôt pas mal. Mais c'est tellement personalisé que ca ne fonctionne quasiment que pour soi-même, donc l'apport pour la communauté QET est quasi nul.
En l'état actuel des choses, je ne vois pas comment réaliser les blocs de borniers de MANIÈRE UNIVERSELLE.
Toutefois, les macros LO, c'est une bonne "béquille" provisoire en attendant d'avoir du natif en Qt/C++.
Une borne pour bornier est toujours définie et représentée dans un schéma par le nom du bloc, et ensuite son numéro. ex: XS_104/10
Ces éléments doivent avoir en plus de leur attribut : terminal, un attribut parent de type: XS, XA, etc, et un autre de type enfant (numéro/texte de borne).
Pour l'instant, je rentre le nom de mon bornier dans le champ "Label", par exemple "-X01".
Et dans le champ "Commentaire", je rentre le numéro des bornes : 1, 2, 3...
Effectivement, si on avait des attributs supplémentaires, ce serait plus simple.
Depuis le csv, on peut utiliser 4 informations pour créer les blocs de borniers :
- "Label"
- "Commentaire"
- "N° de Folio" concaténé avec "Position" pour créer une ref croisée
Puis éventuellement une 5ème info : "Localisation".
En principe c'est toujours un élément dont l'attribut est de type terminal (borne de continuité), on s'en sert déjà pour garder la même liaison équipotentielle donc la même numérotation de conducteur à ses bornes.
Aaaahhhh ok ! Je me suis toujours demandé à quoi servait l'option "Bornier" dans l'éditeur d'éléments !
C'est donc pour définir l'équipotentialité.
Nuri: te suffit de modifier cette partie.
foreach (Diagram *d, m_list_diagram) {
//Get only simple, master and unlinked slave element.
ElementProvider ep(d);
QList <Element *> list_elements;
list_elements << ep.find(Element::Simple | Element::Master);
list_elements << ep.freeElement(Element::Slave);foreach (Element *elmt, list_elements) {
data += getElementInfo(elmt);
}
}
Merci du tuyau !
Je regarderai quand j'aurai de nouveau un peu de temps et les nerfs solides... --> commander une palette d'aspirine
Est-ce qu'on pourra aussi créer une nouvelle barre d'outils qu'on appellera "Post-traitements" (ou quelque chose dans le genre) ?
Ainsi on pourra regrouper toutes les fonctions de QET réalisables lorsque le dessin des schémas électriques est terminé :
- ajouter un sommaire
- exporter en csv : nomenclature
- exporter en csv : borniers
- exporter en csv : câbles
- exporter en csv : filerie
etc... (selon les idées et ce qui sera vraiment faisable)
544 2015-07-08 20:42:44
Re: New floating dock is now ready, news colors, patterns, etc. (94 replies, posted in News)
Le problème actuellement pour faire les borniers semi-auto à partir du csv généré depuis le projet, c'est qu'on ne sait pas vraiment comment filtrer les bornes que l'on veut éditer sous forme de bloc de bornier.
Finalement, sous forme csv, qu'est-ce qui différencie une borne d'un moteur ou d'un relais ?!?
Je vois quelques possibilités mais rien de vraiment universel qui pourrait marcher pour tous les utilisateurs de QET.
On peut par exemple filtrer sur la colonne "Désignation QET" mais cela pose problème avec les langues (puisque les noms des éléments sont traduits) et avec les bornes créés par les utilisateurs avec désignation personalisée.
On pourrait aussi filtrer sur la colonne "Label". Chez nous en Allemagne, les borniers sont toujours identifiés avec la lettre "X". Mais ce n'est pas toujours le cas et ce n'est pas partout pareil...
Bon... vous voyez la difficulté pour faire un générateur qui fonctionne pour tout le monde ?
En fait, à partir du csv, créer la partie graphique c'est presque le plus facile, car ce ne sont que des calculs arithmétiques.
Par contre, savoir quoi éditer (comment filtrer ?) à partir du csv, c'est une autre histoire...
On en revient alors aux attributs et propriétés des éléments. Est-ce que c'est une bonne idée de rajouter des attributs ?
Par exemple "numéro de borne" pour un élément borne (de bornier). Ou alors "numéro de brin" pour un élément représentant un brin de câble ?
Est-ce que cette différenciation des éléments peut faire l'objet de la v0.6 ?
Ou est-ce que l'évolution du panel a la priorité ?
545 2015-07-08 20:13:47
Re: Add attribut "uuid" for .elmt file. (13 replies, posted in News)
Vous pouvez m'expliquer un truc avec les uuid ?
Alors voilà, si j'ai bien compris, chaque élément de la collection (et les personnels patchés par le script de Laurent) se voient attribuer un uuid, par définition unique.
J'ai fait l'expérience suivante :
Si je prends un projet complètement vierge et que j'insère 2 reports de folio partants et 2 folios arrivants et que je lie les 2 partants respectivement avec les 2 arrivants, je peux observer dans le xml du projet que les 2 folios partants se voient attribuer des uuid différents alors que c'est le même élément. Ensuite, l'attribut xml <links> montre l'uuid des reports arrivants, eux aussi différents l'un de l'autre alors que ce sont les mêmes éléments.
Donc les éléments recoivent un nouvel uuid lorsqu'ils sont insérés dans le projet, juste ?!?
Et ma question pour d'éventuels développements futurs :
est-ce qu'il suffit d'écrire l'uuid d'un élément lié dans l'attribut xml <links> de l'autre élément pour que la référence croisée s'établisse automatiquement ?
546 2015-07-07 10:51:10
Re: Saisie semi-auto référence et fabricant (32 replies, posted in FR : Aide, suggestions, discussions, ...)
@ Nuri: si tu as envie, tu peux les mettre sur le repo dans ton répertoire, je les ajouterai sur l'autre serveur.
Je le ferai quand mon projet sera terminé. Dans les éléments que j'ai créés pour mon client, il y a aussi un numéro d'article propre à l'entreprise et il faudra que je le supprime lorsque je ferai le upload.
J'aimerai bien faire cela d'un seul coup, quand tout sera terminé.
Mais là, je suis reparti pour une semaine sur un projet industrie pharmaceutique (sur Eplan).
547 2015-07-06 17:24:13
Re: New floating dock is now ready, news colors, patterns, etc. (94 replies, posted in News)
Nuri wrote:Bon ben ca marche !
Nuri,
ce serait possible de mettre en ligne ton fichier libreoffice ?
Yop, à télécharger ici :
QElectroTech_macros_V01.ods
J'ai implémenté quelques garde-fous pour éviter que la macro ne plante trop facilement (bon... euh... celui qui veut la faire planter, il y arrivera sans trop de difficulté).
J'ai aussi rajouter quelques options pour configurer l'apparence des tableaux (orientation de l'en-tête, taille des textes, nombre de lignes par fichier, etc...). Normalement, ca devrait déjà couvrir pas mal de variantes.
Par contre, j'ai pas encore testé si ca marchait sous Windows. Normalement oui, car je n'utilise que des chemins sous forme d'URL (mais j'ai pas testé).
Et puis, ne pas oublier :
même si ca marche, mon premier but était d'apprendre les macros avec LibreOffice. Un pro aurait probablement 3 fois moins de lignes de code pour réaliser les mêmes fonctions.
Galexis: Pas sur que les macros de Nuri te soient très utiles, ses éléments contiennent déjà les références dans leur définition!
Oui et non...
En fait, la partie du code qui génère du xml à partir du csv est totalement indépendante de mes propres bricolage. Donc ca, ca marche pour tout le monde.
C'est le bouton "Generate elmt file(s)".
Une fois que les données csv sont importées dans le tableur, l'utilisateur peut classer, trier, ordonner comme ca lui chante en utilisant les fonctions habituelles de LibreOffice.
Pour mes besoins, je me suis fait une macro qui classe et ordonne mes données.
C'est le bouton "Run macro". Donc lui, effectivement, il ne vous servira pas à grand chose.
Pas du tout, tu comptes plancher dessus pour nous, nomicons/tongue
pour générer directement avec LO des éléments XML borniers pour Qet en relation avec le projet (en filtrant avec tes macros sur les éléments bornes). nomicons/happy
A priori, c'est tout à fait faisable. D'ailleurs je comptais aussi faire les borniers semi-auto mais vu le temps que j'ai passé sur les nomenclatures, là j'ai plus trop envie !
En fait, le Basic pour LibreOffice est assez simple. Par contre j'avais clairement sous-estimé l'API de LibreOffice pour faire des interfaces utilisateurs. Ca devient assez rapidement de la POO et je suis vite largué...
548 2015-07-06 16:49:50
Re: Saisie semi-auto référence et fabricant (32 replies, posted in FR : Aide, suggestions, discussions, ...)
Salut Laurent,
pour l'instant, j'ai moyen de bricoler pour que QET fasse ce que je veux avec les données d'article, donc y'a pas urgence.
Ceux qui font de la réfection de projet comme toi, c'est évident qu'il ne peuvent pas passer autant de temps sur leurs schémas que ceux qui font de la conception pour construire des armoires toutes neuves (quoique...).
Donc les besoins diffèrent légèrement concernant la gestion des articles.
Je pense qu'on peux réaliser un système qui convienne à tout le monde, sans gêner ni les uns ni les autres, mais j'y réfléchirai plus tard, là j'ai d'autres chats à fouetter.
Apres tout, pourquoi pas les mettre dans le dépôt d’éléments, chacun pouvant ensuite télécharger des éléments spécifique d'un constructeur, pour enrichir sa collection privé suivant ses besoins?
Oui, depuis le départ je pense que la page web de QET peut jouer le rôle d'extension, par exemple, pour fournir des bibliothèques d'éléments un peu différents. Faudra y réfléchir. A garder sous le coude, pour plus tard...
549 2015-07-03 23:41:31
Re: New floating dock is now ready, news colors, patterns, etc. (94 replies, posted in News)
Bon ben ca marche !
550 2015-07-01 23:13:17
Re: suggestion : variable pour les label etnuméro de fil (23 replies, posted in FR : Aide, suggestions, discussions, ...)
T'as du le remarquer de toi même, rien que sur le fait d'ajouter un simple bouton, que rien n'est facile à faire dans le code..
Tu m'étonnes... quelle chienlit !
Une demi-crise de nerf pour un simple bouton (j'ai pas compté les heures) qui ne fait que présenter autrement une fonction qui existait déjà...
Mais bon, je suis pas programmateur, j'ai quasiment tout fait au flair.
J'ai pas encore essayé de comprendre les corrections de Joshua pour supprimer le workaround .
En fait, avec la pratique, je me rends compte que j'ai quand même des bases de programmation mais la POO c'est de la mystique...
Galexis jette un œil sur les docs de Nuri pour comprendre:
https://download.qelectrotech.org/qet/nuri/
Je suis pas sûr d'avoir fait des docs vraiment utiles. Je ne savais pas trop comment présenter les choses car cela devient vite du charabia à la limite du technocratique. Mais comme je suis le seul francais ici qui parle de ces sujets, c'est peut-être pas si mal pour un début.
Sur le forum, j'ai vu qu'il y avait eu quelques demandes dans ce sens de la part d'utilisateurs non francophones.
Au risque de passer pour un neuneu : ça sert à quoi ?
S'il y a un et un seul document a retenir de mes docs, c'est la présentation :
20150213_identificateurs_de_structure.odp
Je pense qu'elle explique bien le principe des =/+ avec un exemple que tout le monde peut comprendre. Mais c'est sûr qu'il faille quand même s'y pencher dessus quelques dizaines de minutes.
Sache pour ton information que la prise en charge et refonte du projet se fera que sur une nouvelle release de Qet, vu les changements profond à faire dans le code..
Joshua pourra carburer aux amphétamines, car je risque de n’être qu'inutile dans cette voie trop complexe du code.
Je suis déjà très satisfait que vous preniez la problématique en compte. Tôt ou tard, les =/+ seront un passage plus ou moins obligé pour QET.
Après, la réalisation, je sais bien que c'est une autre histoire et que c'est du boulot pour au moins une release entière : le panel, les textes de ref croisées, les propriétés des folios... Y'en a peut-être même pour 3 releases !
Va falloir que je change de métier alors !!!
Développeur Qt/C++ ?