Search options (Page 15 of 33)

No JSON was not proposed.
Elements file are in xml and will stay xml for the following reasons :
-It's the original file format and everything in the code about element are for xml.
-Elements are embedded in the .qet file and .qet file is xml, we don't embedded a JSON collection inside the xml of the .qet.
-JSON need to write new code and so need lot of time and debbuging.
-Not retrocompatible with xml element file (or have two codes, one for xml another for JSON, a big headache and a big sources of bug and weird behavior)
-I think JSON is not faster than xml (pugi xml vs Qt JSON) and if so I think we will don't gain a lot.
They look the problem come from  how Windows access to file, I search if something like ram disk can improve the loading of collection.
Don't forget even if qet start-up on windows is slow, he is much faster than before since we use pugixml and multithreading..... but I hope we can do better

We load all the collection at the start up for use the search engine. If we not do that the search engine will search only for folder already expanded.
Exactly in the sources code, at the start up of Qet we get all files of the element collection and on each of these files we get the name and the information of the element and that all.
The icon of the element are created when the folder is expanded for both speed up the start of qet and limit the memory foot print of qet.
So load only expanded folder could be a great solution (qelectrotech will start instantly) but we lose the search engine.
A solution could to add in each folder a new file with inside the name and information of each element present in the folder but :
1: we must to write new code for that instead of improve existing (And in current state of devel for the 0.8 I don't make big change, I polish existing before the release)
2: We also write code to update these new files with :
-automatic update when add/remove/update new element
-and manual update if a change are made outside of qet)

May be we will do this in future but I prefer to find a magic solution for improve existing code.

No, this part of code is used when you drag an element from the common collection to the user collection and so is not called when the collection is loaded or when user drag and drop element into the folio.

Oui je vais regarder ça.
Il faudrait que ce soit en fonction de la local

Actuellement ce n'est pas pris en compte pour l'export du bon de commande.
Il faut que je refasse la fonctionnalité pour qu'elle fonctionne sur la bdd interne du projet.
En attendant tu peut toujours créé une requête perso.

I will see that tomorrow

Cool, j’espère qu'au passage ça corrigera quelque bug et crash propre à windows.

Étrange, je vais regarder ça.

Merci

Corrigé merci.

Question sur un comportement :
Quand on supprime un tableau qui est liée à d'autre tableau, faut il :
-1 supprimer uniquement le tableau
-2 supprimer tous les tableaux liée à celui-ci
-3 poser la question.

Perso je penche pour le 2eme car je pense que cela évitera des erreurs du style oublier d'en enlever un.
Ça n'a aucun sens de supprimer un tableau et garder les autres qui étais liée car que l'on supprime un tableau du début, de fin, ou au milieu dans tous les cas il manquera des infos étant donné qu'il manquera un tableau ou alors (en fonction de la config) le dernier sera beaucoup plus gros et donc dépassera du folio.
Et pour finir mettre en place des tableaux est maintenant assez simple et rapide c'est pas comme si on perdais 1h de boulot..

Hello, thanks for the patch, but in the Qt documentation I see the follwing note:

for both QList<T> QSet::toList() const and QList<T> QSet::values() const.
May be it's will be better to use range constructor, because values will probably be deprecated in future.