|
| probleme avec les etats externes a l'executable |
| Iniciado por AGROLOG.DURIX, 03,may. 2019 15:58 - 10 respuestas |
| |
| | | |
|
| |
| Publicado el 03,mayo 2019 - 15:58 |
Bonjour à tous,
Nous avons un projet qui contient des états intégrés à l'exécutable (par exemple l'état FACTURE)
Pour chacun de nos clients, nous avons un format de FACTURE spécifique. L'état s'appelle toujours FACTURE
Chez le client, nous avons dans le dossier d'installation, les EXE, les DLL et les états WDE spécifiques.
Lors du lancement de l'impression, c'est toujours l'état présent dans le dossier de l'exécutable qui est prioritaire, (enfin c'est comme cela depuis WinDev 4.5...jusqu'à WinDev 22)
Aujourd'hui avec WinDev24, l'exécutable ne tient pas compte des états externes et utilise toujours l'état intégré.
Quelqu'un a t'il rencontré ce problème ?
Merci pour votre aide, |
| |
| |
| | | |
|
| | |
| |
| Publicado el 03,mayo 2019 - 19:42 |
CHRISTIAN DURIX a présenté l'énoncé suivant :
Bonjour à tous,
Nous avons un projet qui contient des états intégrés à l'exécutable (par
exemple l'état FACTURE)
Pour chacun de nos clients, nous avons un format de FACTURE spécifique.
L'état s'appelle toujours FACTURE
Chez le client, nous avons dans le dossier d'installation, les EXE, les DLL
et les états WDE spécifiques.
Lors du lancement de l'impression, c'est toujours l'état présent dans le
dossier de l'exécutable qui est prioritaire, (enfin c'est comme cela depuis
WinDev 4.5...jusqu'à WinDev 22)
Aujourd'hui avec WinDev24, l'exécutable ne tient pas compte des états
externes et utilise toujours l'état intégré.
Quelqu'un a t'il rencontré ce problème ?
Merci pour votre aide,
Bonjour,
Je n'ai pas encore essayé en 24 mais par le passé j'ai déjà rencontré
le souci.
Pour contourner, je teste la présence de l'état dans le répertoire.
S'il est présent, je renseigne le chemin complet à iImprimeEtat() sinon
j'utilise le nom logique de l'état.
Bon WE
--
Cordialement,
Pierre |
| |
| |
| | | |
|
| | |
| |
| Publicado el 06,mayo 2019 - 10:58 |
Merci pour votre reponse mais nous avons environ 50 projets et plus de 250 états dans les plus gros projets.
C'est un peu penible de reprndre toute cette programmation pour simplement tester la presence de l'etat.
J'ai ecrit un petit projet tres simple en wd22, wd23 et wd24 avec un etat integré et le meme etat en etat externe (avec un titre different)
- en wd22 - ca fonction
- en wd23 (derniere version) - ca ne marche pas
- en wd24 - ca ne marche pas
Suis je le seul à avoir eu ce probleme ?
Cordialement,
Christian |
| |
| |
| | | |
|
| | |
| |
| Publicado el 06,mayo 2019 - 12:20 |
Bonjour à tous,
j'ai testé sous Windev23 dernière version et on a le meme problème.
J'attends une réponse de PCSOFT. Peut être un nouveau paramètre à cocher ?
En attendant, comme je n'avais pas envi de modifier toutes les lignes de code ou il y a IIMPRIMETAT() pour verifier l'existence de l'état dans le repertoire des executables, j'ai surchargé l'instruction IIMPRIMETAT() comme ci dessous et ca fonctionne. (Mais il faut que je mettre cette procedure global dans tous nos projets...un peu pénible quand meme)
Je donne l'info pour ceux que ca intéresse.
PROCÉDURE iimprimeetat(*)
LOCAL
nbparametre est un entier = MesParamètres..Occurrence
nometat est une chaîne = MesParamètres[1]
IF fFichierExiste(fRepExe()+"\"+nometat+".wde") ALORS nometat = fRepExe()+"\"+nometat+".wde"
SELON nbparametre
CAS 1 : WL.iImprimeEtat(nometat)
CAS 2 : WL.iImprimeEtat(nometat,MesParamètres[2])
CAS 3 : WL.iImprimeEtat(nometat,MesParamètres[2],MesParamètres[3])
CAS 4 : WL.iImprimeEtat(nometat,MesParamètres[2],MesParamètres[3],MesParamètres[4])
FIN |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,mayo 2019 - 10:57 |
Bonjour Pierre,
je viens de tester votre solution qui consiste à préciser le chemin d'accès aux états si nécessaire et surprise, en WD22, ca ne marche pas non plus (j'ai envoyé des projets à PCSOFT)
- Si je fais IIMPRIMETAT(nom de l'état), ca fonctionne comme on le souhaite, c'est à dire que ca prend l'état personnalisé présent dans le répertoire de l'exécutable s'il existe, sinon ca prend l'état standard intégré dans l'exécutable.
Par contre, si je spécifie le chemin d'accès IIMPRIMEETAT(frepexe()+"\"+nom de l'etat.wde), ca prend toujours l'état intégré dans l'exécutable. Ca ne prend pas l'état dans le dossier de l'exécutable.
Comme nos projets ont été migrés de version antérieure, peut être y a t'il un truc à cocher ? Mais pour envoyer des projets à PCSOFT (un sous WD22 et un sous WD24), j'ai écrit 2 nouveaux petits projets...donc je ne pense pas qu'il y est un rapport avec les migrations…
Par contre, le comportement est diffèrent si je décoche dans l'état "autorisé etat et requete" . La il me prend systématiquement l'état intégré au projet...je pense que c'est de ce coté qu'il y a un truc bizarre.
Avez vous une idée ?
Merci pour votre aide,
Christian |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,mayo 2019 - 15:54 |
Bonjour,
Ce problème a été résolu en supprimant l'état de la bibliothèque.
l'exécutable recherche alors l'état dans le répertoire d'exécution.
Cordialement
benoît |
| |
| |
| | | |
|
| | |
| |
| Publicado el 09,mayo 2019 - 08:25 |
Bonjour Benoit,
Oui mais j'ai besoin que l'état s'exécute en tant qu'état intégré à l'exécutable s'il n'existe pas d'état externe.
Est ce que si je retire l'état de la bibliothèque, cas ca va fonctionner ?
Merci,
Christian |
| |
| |
| | | |
|
| | |
| |
| Publicado el 09,mayo 2019 - 08:32 |
Re bonjour Benoit,
J'aurai du commencer par cela.
Je viens d'exclure l'état de la bibliothèque et dans ce cas, si l'état n'existe pas dans l'exécutable, ca ne fonctionne pas. (plantage)
Notre problème est qu'un état "standard" placé dans l'exécutable peut convenir à 90% de nos clients et que les 10% restant ont un état personnalisé.
On ne peut pas avoir un exécutable diffèrent par client (un avec l'état intégré et un autre avec l'état exclu de la bibliothèque), d'autant que le projet principal doit comporter environ 200 états et que ce ne sont pas les mêmes états qui sont personnalisés…
Merci,
Christian |
| |
| |
| | | |
|
| | |
| |
| Publicado el 21,mayo 2019 - 09:59 |
Bonjour Benoit,
je viens de recevoir un correctif de PCSOFT permettant de retrouver le mode de fonctionnement qui existait jusqu'à la version 22 de WinDev.
Rappel : si je fais IIMPRIMEETAT(nom de l'état) sans préciser le chemin d'accès, c'est l'état qui est dans le dossier des exécutables qui est utilisé s'il existe sinon c'est l'état intégré au projet. (l'état par défaut est toujours intégré au projet). Ce type de fonctionnement permet d'avoir un état standard dans le projet et éventuellement un état personnalisé dans le dossier des exécutables.
Par contre :
IIMPRIMETAT(chemin d'accès + etat.wde) ne fonctionne toujours pas sauf si je retire l'état du WDL (du projet)
C'est pas ce qui est dit dans la documentation.
Est ce moi qui ne fait pas ce qu'il faut ? quelqu'un a t'il réussi à lancer un état en précisant son chemin et en laissant l'état dans le WDL ? (créé avec WinDev avec l'éditeur d'état)
Merci de votre aide,
Christian |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
405 mensajes |
|
| Publicado el 22,mayo 2019 - 11:28 |
Bonjour,
Sur notre projet juste migré en WD 24 pour test, cela fonctionne.
Nous avons un état Facture avec le nom « Facture.wde» et intégré au projet.
Dans le cas d’un nouveau client on ouvre cet état puis « Enregistrer sous » « NomClient.WDE ». Etat qui est aussi intégré au projet.
Par contre comme l’appli est en réseau les états persos sont copiés dans un dossier partagé pour les utilisateurs. Avantage modifier l’état d’un client sans compiler est sans mise à jour, juste a déposer l’état modifié sur le serveur. (Sauf si c’est modification d’analyse bien sûr).
Dans l’apli soit c’est l’état standard qui est paramétré et donc on fait un :
iImprimeEtat(Facture)
soit c’est le modèle du client
iImprimeEtat(\\Sevreur\dossier\NomClient.WDE)
Cela fonctionne depuis des années ainsi pour nous.
BON DEV |
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,mayo 2019 - 13:29 |
Bonjour et merci de votre réponse,
je n'ai pas essayé de renommer l'état (je vais essayé cet après midi).
Nous faisons quasiment la même chose sauf que nous ne renommons pas l'état.
IIMPRIMETAT(FACTURE.WDE) fonctionne maintenant comme jusqu'à la version WD22. (état présent dans le dossier de l'exécutable s'il existe sinon état intégré au projet)
par contre, PCSOFT a bien constaté que IIMPRIMEETAT(\\serveur\dossier\facture.wde) ne fonctionne pas en WINDEV24 ni en windev22. J'attends un second correctif.
Cordialement,
Christian |
| |
| |
| | | |
|
| | | | |
| | |
|