Bonjour.

Mon problème est peut-être un peu long à expliquer, mais je galère vraiment, alors je vous en supplie, aidez-moi.

Je vais essayé d'être précis et rapide.

J'ai une appli utilisant des états.(par exemple, une facture)

Je souhaite pouvoir créer une facture adaptée à chacun de mes clients. (logo de la société, emplacements des totaux...).

Donc, dans mon appli, j'ai un état qui s'appelle "Etat_Facture".

J'ai programmé que l'appli le recherche dans un répertoire précis (\Etats\).

Je peux donc créer des états de même nom, mais différents à partir de mon bureau (pas de WDEtatUtilisateur).
Ces états portant tous le même nom, mais sont situés dans des répertoires différents à mon bureau, ces répertoires étant spécifiques à chaque client.

Par contre, chez le client, ces états seront installés dans le répertoire \Etats\.

Sur mon ordinateur au bureau, j'ai aussi un répertoire \Etats\.

Le problème est que lorsque je copie dans ce répertoire les états d'un client, l'appli les lance bien, mais sans en exécuter les codes, malgré le fait que la coche soit bien présente dans les descriptions des états.

Si vous avez un tuyau, je suis archi preneur car là, je n'en peux plus!!!!

Merci d'avance.

Bonjour,
Est-il possible d'éclaicir ce point :
Citation :
En effet, vous livrez en clientèle un exécutable (avec un WDL). Par conséquent les états définis dans votre éditeur sont compilé dans cet exe et WDL et non dans un répertoire.

Dans notre cas, nous avons résolu ce problème en ajoutant à notre projet un exécutable indépendant (y compris de l'analyse !!!) qui contient l'ensemble des état adaptés aux clients. Evidement nous utilisons un système de configuration (déclaration de l'état "réel" utilisé en face de tel état "logique" pour le client lors de l'installation/paramétrage).

L'impression est alors exécuté par notre exécutable additionnel qui recoit en paramètre le nom de l'état réél.

Pour arriver à proposer l'exécutable additionnel de manière indépendante nous assurrons les liaisons source de données de l'état - fichiers de données par programmation.
Evidement, nous avons travaillé sur la concordance des rubriques (nom et présence) pour afficher ou pas les champs des état.

Une peu de travail mais beacoup de gain en administration/maintenance.

Merci de votre réponse, il est vrai apparement efficace.

Pour répondre à votre interrogation, j'imprime les états avec ce bout de code :


w_nom_etat est une chaîne

w_nom_etat = "C:\Program_Files\Mon_Appli\Etats\Etat_Facture.wde"

// impression de l'état
iAperçu(75, "Impression d'un Avoir")
iInitRequeteEtat(w_nom_etat, Tabl_Avoirs.Num_Avoir)
iImprimeEtat(w_nom_etat)


Mon souci est que la coche ou la décoche de l'option "Intégrer le code compilé" dans la description de l'état ne change rien, on dirait qu'il ne tient pas compte de cette option.

Ce n'était ce problème, tout marche bien car ce sont bien les états présents dans le répertoire qui s'affichent.

Juste une petite chose, ces états ne sont pas intégré au projet, mais cela devrait fonctionné quand même, non ?

Citation :

J'avoue qu'avec notre solution, je n'ai pas évalué cette capacité de WinDev de permettre l'extration des wde.
AHMA, les WDE libres ainsi difusé ne sont disponible qu'à wdetat utilisateur qui doit se charger de les compiler à la volée (analyse des fichiers + Compile())

Une autre solution consiterait à utiliser une DLL externe pour vos états.

Pour se faire il faut compiler vos états dans une DLL (bibliothèque) à part (Menu>Atelier>Bibliothèque>Générer la bibliothèque) qui contiendra alors les états, leurs codes et leurs dépendances (images...).

A vous de diffuser la dll sous forme de patch et de configurer vos clients de manière à utiliser tel ou tel état.