Utilisation d'une classe contenue dans une bibliothèque

Le
Romain PETIT
Bonjour,

je n'arrive pas à mettre en pratique ce code :
http://doc.pcsoft.fr/?1000003013020&name=chargewdl_fonction

// code du projet
GLOBAL
oTest est un objet dynamique
// cette bibliotèque contient la classe cTest
gf_sNomWDL est une chaine = "C:TestMabiblioTest.WDL"

gf_eHandleBiblio est un entier
gf_eHandleBiblio = ChargeWDL(gf_sNomWDL)
SI gf_eHandleBiblio>0 ALORS info("Ok, WDL chargée")

LOCAL

sErrCompil est une chaine
sErrCompil = Compile("AllouerObj","oTest=allouer un objet cTest")
// -> j'ai un retour sErrCompil = Le type 'cTest' est inconnu
SI sErrCompil = "" ALORS
ExécuteTraitement("AllouerObj", trtProcédure)
Compile("AllouerObj", "")
Info("Allocation Ok")
SINON
FinProgramme("Pb d'allocation de l'objet" + RC + sErrCompil)
FIN




En gros je souhaiterais avoir un petit EXE qui charge une bibliothèque
qui contiendrait tous le code, y-compris des classes globales.
Une idée ?

A+

--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Romain PETIT
Le #26403426
Romain PETIT a exposé le 04/07/2016 :
Bonjour,
je n'arrive pas à mettre en pratique ce code :
http://doc.pcsoft.fr/?1000003013020&name=chargewdl_fonction

Bon, j'y suis arrivé.
Mon erreur était de croire que je pouvais utiliser le même projet pour
faire la bibliothèque d'un côté, avec une configuration incluant tout
et le petit exe chargeur de l'autre, dans une autre configuration (en
excluant tous les éléments du projet).
Etrangement ça ne fonctionne pas, il semble qu'on soit obligé
d'utiliser un autre projet pour charger correctement les classes....
A+
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
tt
Le #26403429
Le Mon, 04 Jul 2016 14:13:35 +0200, Romain PETIT écrit:
Romain PETIT a exposé le 04/07/2016 :
Bonjour,
je n'arrive pas à mettre en pratique ce code :
http://doc.pcsoft.fr/?1000003013020&name=chargewdl_fonction

Bon, j'y suis arrivé.
Mon erreur était de croire que je pouvais utiliser le même projet pour
faire la bibliothèque d'un côté, avec une configuration incluant tout
et le petit exe chargeur de l'autre, dans une autre configuration (en
excluant tous les éléments du projet).
Etrangement ça ne fonctionne pas, il semble qu'on soit obligé d'ut iliser
un autre projet pour charger correctement les classes....
A+


Merci du retour !
--
Thumain Thérèse
R&B
Le #26403851
Le 04/07/2016 14:13, Romain PETIT a écrit :
Romain PETIT a exposé le 04/07/2016 :
Bonjour,
je n'arrive pas à mettre en pratique ce code :
http://doc.pcsoft.fr/?1000003013020&name=chargewdl_fonction

Bon, j'y suis arrivé.
Mon erreur était de croire que je pouvais utiliser le même projet pour
faire la bibliothèque d'un côté, avec une configuration incluant tout et
le petit exe chargeur de l'autre, dans une autre configuration (en
excluant tous les éléments du projet).
Etrangement ça ne fonctionne pas, il semble qu'on soit obligé d'utiliser
un autre projet pour charger correctement les classes....
A+


Merci Romain.
La gestion des WDL a fait son temps.
Partant du chemin inverse... c'est à dire faire en sorte de partager des
portion d'un projet avec différents projets, il existe désormais deux
possibilités avec respectivement des avantages et inconvénients.
1- les composants internes
Il s'agit d'une extension de la notion de perso dossier mais en
nettement plus puissant. Un composant interne réagit comme une "partie"
du projet qui est ajouté au projet hôte. La spécification "interne"
indique que le code source du composant est intégré au projet hôte.
Outre les classes, on peut ajouter tout type d'élément de projet à un
composant interne (fenêtre, collection de procédure, et même analyse...
ce qui représente un point à détailler plus tard si nécessaire).
Les avantages du composant interne résident :
- dans l'usage du partage entre les projets via le GDS. Prévoir alors un
projet dédié au composant pour, depuis ce dernier effectuer les tests.
Dans les projets hôtes, le composant est alors partagé. la modification
du composant est alors propagée à la réintégration GDS dans le projet
hôte. A un instant il n'existe donc qu'un seul et unique source du
composant. Tous les projets hôtes sont alors modifiés.
- dans la possibilité de limiter ce qui est visible ou pas du composant
dans le projet hôte. Ainsi, il est possible et fortement recommandé de
ne laisser visible que ce qui est utile au projet hôte (les
entrées/sorties du composant). Le composant se charge alors de faire sa
sauce sans que le développeur du projet hôte ait à s'en soucier.
C'est pour cette raison qu'un projet dédié au composant est important :
on peut alors tester tous les scénarios d'entrée sortie avant de
propager les modifications.
- Les dépendances, il est possible qu'un composant ai besoin d'un autre
composant. Son ajout dans un projet se charge d'ajouter les partage des
dépendance (et leur propagation en cas de modification).
- Le composant interne utilise le même espace de nom que le projet hôte.
Il est capital d'utiliser des noms d'élément unique au composant.
Les inconvénient des composants interne sont :
- la gestion de l'analyse propre au composant. Chaque composant interne
disposant de son analyse réalise alors sa propre connexion au serveur de
données... il faut en tenir compte en exploitation. Si de très nombreux
composants d'un même exécutable ont chacun une analyse, c'est autant de
connexions au serveur pour une seule session utilisateur.
- La "protection" des source n'existe pas.
- Le composant interne utilise le même espace de nom que le projet hôte.
L'intégration dans un projet peut générer un conflit de nom d'élément si
on n'y prète pas garde.
2- Les composants externe. La version des DLL en plus puissant.
Les composants externes fonctionnent comme les composants interne avec
deux différences majeures:
- Ils sont livrés compilés. le code source n'est donc pas visible par le
développeur du projet hôte. Attention à la maintenance, seule les
prototypes d'appel des éléments visibles sont donnés au projet hôte.
- Il ne partagent pas l'espace de nom (compilation oblige) du projet
hôte. En cas de conflit de nom avec le projet hôte, il y a donc surcharge.
L'avantage du composant externe réside dans la possibilité de le
distribuer individuellement, ses sources sont protégés.
Comme pour le composant interne, le composant externe dispose de sa
propre connexion.
Voila donc deux évolution interessantes des bibliothèques externes.
++ R&B
WDForge.org
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com
tt
Le #26403958
Merci, intéressantes réflexion et expérience.
--
Thumain Thérèse
Publicité
Poster une réponse
Anonyme