Discussion :

[Pgs]

Bonjour,

Existe-t-il un moyen de "Piloter" OpenOffice avec un programme C++ créé sous Code::Blocks ?

Philippe

[ternel]

Piloter? qu'entends-tu par là?

Il y a bien UNO, la bibliothèque de manipulation de fichiers OpenDocument.

[Pgs]

Bonjour Leternel,

a) L'idéal serait de créer un programme compilé en statique, qui soit capable de créer un fichier Calc ou Writer natif, avec des données à l'intérieur (un mini rapport par exemple)

Mais peut-être que je rêve...


b) La solution de repli (si elle existe), serait de lancer des commandes à Calc ou Writer (lancement de l'application, création ou ouverture d'un fichier, écriture etc...).

Philippe

[jopopmk]

Salut,

un fichier ODF est une archive zip contenant un ensemble de fichiers XML, donc oui c'est tout à fait possible.
Je ne connais pas UNO, à toi de voir si ça te convient (ou de chercher une autre lib, ça doit exister).

En tout cas c'est tout à fait faisable de monter un document ODF de toute pièce en C++ (où de se baser sur un document modèle).

[Pgs]

Merci !

Je vais me pencher sur UNO.

Concernant l'autre option, celle d'envoyer des commandes à OOO :
* est-ce ça que l'on appelle de l'automation ?
* est-ce à travers des commandes OLE que l'on peut le faire ?
* quelqu'un a-t-il un exemple sous C++ ?

Bonne journée,
Philippe

[ternel]

La seconde solution est en général très difficile à mettre en place.

UNO est la bibliothèque conçue pour ce que tu veux faire: la manipulation et la création de ce type de documents.

[Pgs]

OK.

a) Penses-tu que ça prendrait longtemps de mettre la bibliothèque UNO et de trouver le code afin de, pour commancer, créer un document ODS avec quelques nombres à l'intérieur ?

b) Est-il possible, dans un même programme, d'utiliser le Framework wxWidgets et la bibliothèque UNO ?

Désolé pour mes questions de débutant... interdit de se moquer !

Merci

[ternel]

Je crois que tu t'embrouilles un peu.
wxwidget sert à afficheir une interface graphique, en dessinant des boutons, des menus, etc.
uno sert à éditer un fichier au format OD* (ODS, ODT, etc)


Si c'est pour faire un rapport, tu pourrais regarder du coté de XML ca va vite à apprendre, c'est simple à générer et il n'y a pas besoin de vraie bibliothèque.
De plus, tu pourras facilement passer à de l'html, dont le support natif du css te permettra de faire de joli rapport, lisible sur n'importe quel ordinateur.

Quel est ton besoin réel avec ce fichier?

[Pgs]

Merci,

J'ai bien compris que ces bibliothèques avait des fonctions différentes.

Mais question était de savoir si, techniquement, je peux compiler (en statique) un seul programme qui :
* utilise les librairies wxWidgets pour sa GUI,
* utilise UNO pour présenter certains résultats sur la forme d'un joli rapport Writer ou Calc.

Philippe

[ternel]

Bien sur, et heureusement

[Pgs]

Merci.

Ce que tu dis à propos de XML m'intéresse beaucoup.

En effet, voici le programme que je veux faire :

a) Lire un fichier XML de programmes TV pour le transformer en un tableau
b) Extraire les lignes qui m'intéressent sur la base de quelques mots clés
c) Les présenter dans mon application sous forme d'une liste avec possibilité de cliquer sur quelques lignes pour les sélectionner
d) Créer un fichier Writer avec un tableau contenant les informations des émissions sélectionnées

Du coup, le fait que tu parles de XML m'intéresse aussi pour le début du programme : balayer le XML pour en faire un tableau.
Mais j'ai peur que ce soit un peu dur...

Salut

Philippe

[Pgs]

(suite)
J'ai vu des infos sur tinyxml2 et sur libxml++.
Tu dis qu'il n'est pas nécessaire d'avoir de vraie bibliothèque. Qu'entends-tu par là ?
Merci,
Philippe

[ternel]

J'entendais par là qu'écrire de l'xml c'est pas difficile, et tu peux faire une mini-bibliothèque d'écriture rapidement.
Par contre, pour extraire des données, il vaut mieux passer par une bibliothèque.

libxml2 est le standard sous linux, elle est à la fois souple et performante.

a) Lire un fichier XML de programmes TV pour le transformer en un tableau
b) Extraire les lignes qui m'intéressent sur la base de quelques mots clés
c) Les présenter dans mon application sous forme d'une liste avec possibilité de cliquer sur quelques lignes pour les sélectionner
d) Créer un fichier Writer avec un tableau contenant les informations des émissions sélectionnées

Je te propose de réfléchir en terme de données:

1. avant a, tu as un xml
2. entre b et c, tu as un ensemble d'informations pré-choisies
3. après c, l'utilisateur a fait son choix, et tu devrais disposer d'un ensemble d'information du même aspect qu'avant c.
4. après d, cette forme est changée, pour être plus informative.

Les opérations a et b sont des étapes du même traitement: les données n'ont pas changé après à (sauf de forme). De même pour c et d.

Les deux traitements critiques sont b et c, car ce sont eux qui changent les informations.
Ce sont donc eux qu'il faut soigner.
Concrètement, tu pourrais utiliser en a+b n'importe quel outil qui filtre un xml et qui donne un résultat acceptable en c.
Si tu optes effectivement pour le C++, j'espère que par tableau, tu entendais std::list ou std::vector.

Pour l'étape de sélection, tu veux a peu près une liste de ligne à sélectionner. La forme la plus simple est un formulaire contenant des cases à cocher.

[Pgs]

Bonjour Leternel,

Merci beaucoup.

C'est très clair et c'est un bon guide.

Je suis malheureusement bloqué par une étape technique.

Je code sur win7 avec Code::Blocks / MinGW.

J'ai réussi à compiler, grâce à wxXav, la bibliothèque wxWidgets pour la GUI de mon futur programme.

Mais mes compétences se limitent à des opérations basiques.

Je voudrais utiliser la lib tinyxml mais je ne sais pas comment l'intégrer dans mon projet :
* suffit-il de récupérer les fichiers et de spécifier le path au compiler/linker ou bien dois-je compiler la lib ?
* s'il faut la compiler :
- dois-je la compiler en statique puisque j'utilise par ailleurs la lib wxWidgets en statique ?
- comment le faire ?

Merci pour toute aide.

Philippe

[ternel]

Version courte:
A priori, tu ne devrais pas avoir à compiler la bibliothèque.
Par contre, tu devras quand même te demander si tu veux utiliser une bibliothèque statique ou partagée.

Le choix d'utiliser une bibliothèque en statique ou non est indépendant du choix pour une autre.
Cela dit, les arguments qui t'ont fait choisir pour l'une s'appliquent en général à l'autre.

Version longue:
Une bibliothèque est essentiellement du code précompilé.

Comme tu l'as remarqué, il y a deux grands modes d'utilisation: la liaison statique et la liaison partagée.
La différence, c'est le moment où le code est ajouté à l'application qui veut s'en servir.
il existe aussi le chargement manuel par le programme, mais tu n'es pas du tout dans ce cas. C'est plus adapté aux plug-in.

Revenons un instant à la compilation d'un programme C++.
Supposons un programme construit ainsi:

Code main.cpp :

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

1
2
3
4
5
6
7
8
#include "afficher.h"
#include <string>
using namespace std;
int main() {
   string message = "bonjour";
   afficher(message);
   return 0;
}

Auquel il faut ajouter l'en-tête

Code afficher.h :

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

1
2
3
4
5
6
7
8
 
#ifndef INCLUDE_AFFICHER_H
#define INCLUDE_AFFICHER_H
#include <string>
 
void afficher(std::string const&);
 
#endif

Et enfin, l'implémentation de cet en-tête

Code afficher.h :

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

1
2
3
4
5
6
7
#include "afficher.h"
#include <string>
#include <iostream>
 
void afficher(std::string const& s) {
   std::cout << s << std::endl;
}

Quand tu compiles un programme, il y a un certain nombre d'étapes, qui se résument aux suivantes:

1. passage du préprocesseur
2. compilation proprement dite
3. édition des liens

La première étape prend un unique fichier en entrée, et exécute les commandes #, dont les includes, et remplace les macros par leur texte de substitution.
Le fichier produit forme un code C++ complet, que le standard appelle une unité de compilation.
Par exemple, l'unité correspondant à main.cpp est constituté du code suivant:

Code main.cpp :

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

1
2
3
4
5
6
7
8
9
10
11
12
//le contenu préprocessé de <string>
 
void afficher(std::string const&);
 
//le contenu préprocessé de <string>, qui s'avère être rien du tout, car la garde de double inclusion est là pour ca.
 
using namespace std;
int main() {
   string message = "bonjour";
   afficher(message);
   return 0;
}

Tu peux obtenir ce fichier avec gcc -E main.cpp.

La deuxième étape transforme ce code source en un code compilé, mais avec plein de symbole externe (dont la fonction afficher)
La même chose est faite sur afficher.cpp, mais pas forcément en même temps, c'est ce qu'on appelle la compilation séparée.

La troisième étape, l'édition des liens (linkage), consiste à concaténer les deux unités compilées, et à remplacer les symboles externes par les symboles trouvé dans les bonnes unités.
Les erreurs de types "undefined reference to symbol ..." et "multiple definition of ..." surviennent à ce moment là, quand le compilateur ne trouve pas un symbole, ou trop de fois.

Voila pour les rappels.

Une bibliothèque est vue par le compilateur exactement comme une unité de compilation.
Par exemple, tu pourrais compiler afficher.cpp comme une bibliothèque, ca ne changerait rien (ou presque).

Une bibliothèque statique est précisément une unité déjà compilée, que l'édition de liens incorpore comme du code "normal".
Une bibliothèque partagée au contraire n'est pas incorporée dans le code final, mais simplement marquée pour intégration.

Quand le programme est exécuté, la bibliothèque statique est déjà dans le code, alors que l'édition de lien de la bibliothèque partagée est terminée à la volée.

Les deux situations ont des avantages, qui sont précisément les défauts de l'autre. Le choix est une histoire de compromis.
Une bibliothèque partagée n'a besoin d'être présente qu'une seule fois pour l'ensemble des programmes s'en servant. Elle n'est pas chargée plusieurs fois en mémoire si plusieurs de ces programmes s'exécute.
Une bibliothèque statique n'a pas de risque d'embrouille entre les versions, et n'a pas besoin d'installation séparée.

Pour exécuter un programme, il faut avoir à disposition de celui-ci l'ensemble des bibliothèques partagées qu'il réclame. En général, c'est assuré par l'OS lui-même (pour les bibliothèques systèmes) et l'installeur de l'application (pour les autres).
En général, ca se résume à avoir les dll (pour windows) dans le dossier d'installation de l'application ou dans les dossiers dédiés (c:\windows\Je-ne-sais-plus-quoi).

Pour compiler un programme, il faut en plus de la forme compilée (quelle que soit le type de liaison), les en-têtes pour pouvoir déclarer les fonctions dans le code.

C'est la personne qui compile la bibliothèque qui choisit s'il veut une compilation pour liaison statique ou partagée.

Compiler une bibliothèque demande souvent d'avoir accès aux en-têtes des bibliothèques que elle-même utilise. C'est pour cela que la plupart des bibliothèques proposent une forme compilée.

Conclusion:
Tu n'as probablement pas à compiler libxml2, mais tu devras quand même te demander si tu veux utiliser une bibliothèque statique ou partagée.
Compiler une bibliothèque permet d'utiliser une version spécifique, ou modifiée.

[Pgs]

Merci pour toutes ces explications, très pédagogiques.

Le choix d'utiliser une bibliothèque en statique ou non est indépendant du choix pour une autre.

Ce qui m'avait fait poser la question, c'est que sous Code::Blocks, j'ai l'impression de devoir choisir DLL oui/non pour l'ensemble du projet.
Mais c'est certainement parce que je passe par l'assistant et que je choisis un projet wxWidgets : la question ne concerne peut-être que cette lib.

Merci encore, et bonne journée,

Philippe

[ternel]

Je pense aussi.
Bonne continuation