Discussion :

[AgriPacTe]

J'utilise depuis peu, mais avec bonheur, QxOrm.
C'est une bibliothèque dans laquelle je retrouve une façon facile de remplacer les fonctionnalités
de ma bibliothèque concoctée par 30 ans d'expérience sur des logiciels "métiers" à base
de DAO (pour les bases) et de COM (pour servir sur le réseau les objets d'application)

J'ai "bricolé" avec QxOrm une application BaseAgri qui tourne très bien (après quelques adaptation à
cette culture "Linux(Ubuntu)/Qt/model-view/..." nouvelle pour moi), mais dans laquelle, pour commencer,
je n'ai pas exprimé les relations (dans mes objets, la relation à un autre objet est un "long IdXXX"
de l'IdObj -clé primaire- dans l'autre table, et apparaît donc comme un nombre dans les colonnes de
l'interface utilisateur -et les "model/view", ...-)
(toutes mes relations sont ici des "n-1" vues des objets, et des interfaces utilisateurs; la seule
exception est "interne", quand l'utilisateur demande à supprimer, une définition d'unité de mesure
par exemple, je dois savoir si elle est utilisée quelque part pour ne pas supprimer)
J'ambitionne maintenant de passer à l'expression des relations par des pointeurs d'objets et des listes.

A cette occasion, je fais entrer QxEE dans le manège.
Et là, dur-dur ... je dois manquer de culture pour faire les liens entre ce que me génère QxEE et
Qt/model-view/... (le nom de mon projet dans QxEE est BaseAgri -fichier BaseAgri.qxee-)

J'obtiens une erreur de compilation parce que "BaseAgri_export.gen.h" n'existe pas.
J'ai suivi la démarche:
- Faire un projet QT BaseAgri d'application Widgets vide (avec seulement une mainwindow)
(dans le répertoire "AteliersLogiciels/BaseAgri")
- Paramétrer QxEE pour "Export C++ model/view project" (le seul qui m'interesse -a priori-)
(vers le répertoire "AteliersLogiciels/BaseAgri/QxModel")
- Paramétrer QxEE pour "Export C++ project" (parce qu'il apparait en grisé dans celui de dessus
(vers le répertoire "AteliersLogiciels/BaseAgri/QxBase"; il n'accepte pas que ce soit le même -très bien!-)
- Exporter avec "Export C++ model/view project"
- Compiler donne l'erreur "../../QxBase/include/BaseAgri_export.gen.h n'existe pas"; bien noter qu'"il"
cherche dans QxBase et pas QxModel.
- Exporter avec "Export C++ project" (esperant que QxBase ne soit plus vide)
- J'ai toujours la même erreur (logique car toujours QxBase vide)

Accessoirement, je donne ici une liste des "astuces" que j'ai du utiliser pour contourner des contraintes
(dans le projet qui fonctionne sans l'expression des relations) pour le cas où il y aurait des façons
moins contraignantes et surtout plus élégantes de faire; si je dois plutôt ouvrir un trait pour
chaque point, je pourrai le faire progressivement:
- dans la template d'une classe (dans oCulture.cpp par exemple), le "t.data" du "Libelle" à la fin de la liste
si je veux que le "StrechLast" d'une tableView s'applique au libellé; je n'ai pas réussi à reclasser
les colonnes du "model" avec "modelSchemas->setListOfColumns(lstCol);"
où "modelSchemas = new qx::QxModel<oCulture>();" (seulement à sélectionner ce qui intéresse l'iu).
Code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
// Les volets du bureau
QStringList lstCol;
QStringList lstHdr;
QList<int> lrgCol;
QHash<QString,QString> tmpHash;
query="WHERE KType=";
 
// Le Volet "Schémas de culture"
// Create a model for oCulture/Schemas and fetch data from database
modelSchemas = new qx::QxModel<oCulture>();
lstCol << "Abrege" << "dtDebut" << "dtFinPrevue" << "NbUeK_Rang" <<
          "Sem_Plant_Rang" << "idUniteSem_Plant" << "Prod_Rang" << "idUniteProd" << "Libelle";
lstHdr << "Abrégé" << "Déb." << "Fin" << "nU" << "SemPl" << "Unité" << "Prd" << "Unité" << "Libellé";
lrgCol << 55 << 40 << 40 << 40 << 40 << 50 << 40 << 50 << 80;
for(int i=0; i<lstHdr.count(); i++) tmpHash.insert(lstCol[i],lstHdr[i]);
modelSchemas->setListOfColumns(lstCol); modelSchemas->setListOfHeaders(tmpHash);
if(!modelSchemas->qxFetchByQuery_(query+QString::number(KType_Schema)))         {qDebug() << "err: Schemas";}
ui->tableViewSchemas->setModel(modelSchemas);
for(int i=0; i<lrgCol.count(); i++) ui->tableViewSchemas->setColumnWidth(i,lrgCol[i]);
ui->tableViewSchemas->show();

A noter que cela peut être une contrainte majeure: j'ai pour habitude, pour la santé des bases et la
"versionalisation", de toujours rajouter les nouveaux champs à la fin (ce que cette astuce contredit)

- ... (j'arrête pour aujourd'hui; il vaut mieux que j'ouvre un trait pour chaque point ...)

[QxOrm]

J'utilise depuis peu, mais avec bonheur, QxOrm.

- Paramétrer QxEE pour "Export C++ model/view project" (le seul qui m'interesse -a priori-)

Non, le projet model/view dépend du projet contenant les classes persistantes enregistrées dans le contexte QxOrm (celui généré par le menu "Export >> Export to C++ project").

bien noter qu'"il" cherche dans QxBase et pas QxModel.

C'est normal : voir mon commentaire précédent : le projet model/view ne peut pas fonctionner tout seul.

Si on parle en langage Windows (remplace .DLL par .SO pour Linux), tu as par exemple :
1- la DLL de la bibliothèque QxOrm que tu as compilé ;
2- la DLL contenant les classes persistantes enregistrées dans le contexte QxOrm (void qx::register_class<T>) : cette DLL (générée par le menu "Export >> Export to C++ project") dépend de QxOrm.DLL ;
3- la DLL model/view qui dépend de QxOrm.DLL + ta DLL contenant les classes persistantes ;
4- ton EXE qui dépend de toutes ces DLL.

J'ai toujours la même erreur (logique car toujours QxBase vide)

Ce n'est pas normal : si tu as paramétré QxBase comme le dossier de destination du plugin "Export to C++ project", alors c'est que tu n'a pas exécuté le plugin.

modelSchemas->qxFetchByQuery_(query + QString::number(KType_Schema))

Les méthodes préfixées "qx" et suffixées par "_" sont définies : Q_INVOKABLE ==> ça signifie qu'elles sont accessibles en QML.
Dans ton cas, comme il s'agit de code C++, tu devrais plutôt utiliser : qxFetchByQuery (sans le "_") ==> tu récupères ainsi un objet de type QSqlError en cas d'erreur.

Autre remarque : au lieu de construire ta requête SQL avec + QString::number(KType_Schema), tu devrais plutôt utiliser les placeholder (ton moteur SGBD pourra ainsi plus facilement mettre en cache les requêtes, ce sera plus optimisé et performant).
Plus de détails dans la FAQ ici : http://www.qxorm.com/qxorm_fr/faq.html#faq_210

je n'ai pas réussi à reclasser les colonnes du "model" avec "modelSchemas->setListOfColumns(lstCol);"

C'est plus au niveau de la vue qu'il faut faire quelque chose, pas au niveau du modèle.
Je pense que tu trouveras la solution ici : https://forum.qt.io/topic/4499/chang...a-qtableview/9
QTableView provides access to the header view via QTableView::horizontalHeader(). QHeaderView has a method called moveSection, that allows you to reorder the sections (in this case: columns) as you please.

il vaut mieux que j'ouvre un trait pour chaque point

Oui c'est beaucoup mieux, merci

[AgriPacTe]

Non, le projet model/view dépend du projet contenant les classes persistantes enregistrées dans le contexte QxOrm (celui généré par le menu "Export >> Export to C++ project").

Ok. J'ai compris.

C'est normal : voir mon commentaire précédent : le projet model/view ne peut pas fonctionner tout seul.

J'ai re-compris; ça fait plaisir de discuter avec des gens cohérents; ça repose ...

Si on parle en langage Windows (remplace .DLL par .SO pour Linux), tu as par exemple :
1- la DLL de la bibliothèque QxOrm que tu as compilé ;
2- la DLL contenant les classes persistantes enregistrées dans le contexte QxOrm (void qx::register_class<T>) : cette DLL (générée par le menu "Export >> Export to C++ project") dépend de QxOrm.DLL ;
3- la DLL model/view qui dépend de QxOrm.DLL + ta DLL contenant les classes persistantes ;
4- ton EXE qui dépend de toutes ces DLL.

Je n'ai pas creusé la question car ... (voir point suivant)

Ce n'est pas normal : si tu as paramétré QxBase comme le dossier de destination du plugin "Export to C++ project", alors c'est que tu n'a pas exécuté le plugin.

Pourtant si. Je recommence, et là c'est bon, QxBase est rempli.
J'ai l'impression que c'est une nouvelle ligne dans BaseAgri.pro
"unix:!macx: LIBS += -L$$PWD/../Libs/QxOrm/lib/ -lQxOrmd"
qui a changé la donne.
(ceci peut aussi répondre à la question précédente ...)

C'est plus au niveau de la vue qu'il faut faire quelque chose, pas au niveau du modèle.
Je pense que tu trouveras la solution ici : https://forum.qt.io/topic/4499/chang...a-qtableview/9
QTableView provides access to the header view via QTableView::horizontalHeader(). QHeaderView has a method called moveSection, that allows you to reorder the sections (in this case: columns) as you please.

Effectivement, je vais voir ce moveSection que je ne connais pas.

J'ai encore des erreurs, mais je vais voir et progresser.
J'ouvrirai éventuellement d'autres traits si je ne m'en sort pas.
Je joint le dessin de BaseAgri à toute fin utile. (B'en non j'ai pas réussi ...) (ça y est, ... je progresse!)

Pour les deux points, c'est répondu. Deux grands merci.

Qui "ferme" ce trait ?
(je suis aussi nouveau sur "Developpez.net")

[QxOrm]

Pour les deux points, c'est répondu. Deux grands merci.

Qui "ferme" ce trait ?

Je vois que tu as mis le sujet en [Résolu], donc c'est parfait !