Impossible de créer le fichier .exe associé au projet
srr2020
Messages postés
1
Date d'inscription
mardi 15 septembre 2020
Statut
Membre
Dernière intervention
15 septembre 2020
-
15 sept. 2020 à 11:08
JeuDuTaquin Messages postés 249 Date d'inscription mardi 4 juillet 2017 Statut Membre Dernière intervention 31 mai 2023 - 19 sept. 2020 à 08:52
JeuDuTaquin Messages postés 249 Date d'inscription mardi 4 juillet 2017 Statut Membre Dernière intervention 31 mai 2023 - 19 sept. 2020 à 08:52
A voir également:
- Impossible de créer le fichier .exe associé au projet
- Fichier .ini - Conseils pratiques -Visual Basic / VB.NET
- Vbs to exe - Forum VBScript (VBS)
- Fichier class - Forum Java
- Grille de mots mélés à créer - Forum Java
- Fichier json - Conseils pratiques -Javascript
3 réponses
vb95
Messages postés
3472
Date d'inscription
samedi 11 janvier 2014
Statut
Contributeur
Dernière intervention
13 avril 2024
169
Modifié le 15 sept. 2020 à 21:40
Modifié le 15 sept. 2020 à 21:40
Bonjour
As-tu une version officielle de Visual Basic 6 avec un numéro de licence valable ?
Si oui tu utilises certainement dans ton projet un composant additionnel dont tu n'as pas la licence .
As-tu une version officielle de Visual Basic 6 avec un numéro de licence valable ?
Si oui tu utilises certainement dans ton projet un composant additionnel dont tu n'as pas la licence .
Notpa
Messages postés
125
Date d'inscription
dimanche 13 janvier 2019
Statut
Membre
Dernière intervention
8 janvier 2021
1
18 sept. 2020 à 18:39
18 sept. 2020 à 18:39
Hello,
Quels sont les composants que tu utilises ? J'ai eu un problème similaire dans le passé à cause d'un composant dont j'ai hélas oublié le nom ! Je l'ai remplacé un un autre et j'ai pu compiler mon programme.
Quels sont les composants que tu utilises ? J'ai eu un problème similaire dans le passé à cause d'un composant dont j'ai hélas oublié le nom ! Je l'ai remplacé un un autre et j'ai pu compiler mon programme.
JeuDuTaquin
Messages postés
249
Date d'inscription
mardi 4 juillet 2017
Statut
Membre
Dernière intervention
31 mai 2023
7
Modifié le 19 sept. 2020 à 09:07
Modifié le 19 sept. 2020 à 09:07
Salut,
Oui, question récurrente lors d'utilisation de fichiers OCX ou DLL en import dans certains projets.
En effet, l'utilisation d'objets esclaves issus d'Office, Excel ou Access... est tentante car pratiques, utiles et évite un code maison acrobatique.
Mais dans les faits, le fichier exécutable fera appel à des dépendances propriétaires installés sur la machine de programmation.
Il suffira donc d'utiliser le programme sur une autre machine pour s'apercevoir qu'il ne fonctionnera pas.
En effet, ces OCX sont basés sur l'utilisation de nombreuses sous-dépendance (DLL, clés de registres) qui ne seront pas installées et donc manquantes.
Même si le terme de "Licence" nous fait penser au piratage, dans les faits, l'OCX ne trouve pas les fichiers dont il a besoin.
Il faut prioriser les "Kits" d'installation d'OCX indépendants, et éviter les OCXs d'applications intégrées qui ne seront pas exportables, sans l'installation d'une solution intégrée du type "Pack Office" et autres produits se greffant au système.
Donc, ces OCXs, même disponibles comme dépendance à utilisation "stand-alone", ont très souvent des impératifs au niveau des versions du système d'exploitation et de l'installation de patchs de mise à jour.
Leurs utilisation sont à déconseiller pour des applications portables, compatibles et distribuables.
Dans le cas d'un arrêt de compilation, voir un plantage du compilateur, et que le code vient d'une autre machine, le problème peut se résoudre en créant un nouveau projet avec les même OCX, en les ajoutant au nouveau projet.
On le sauvegarde, puis en mode texte, dans les fichiers *.VBP, il faut substituer les lignes de déclaration des OCX avec leurs versions et clés de registre du nouveau projet vers l'ancien qui ne se compile pas, (et effacer les anciens avec des références erronées)
Oui, question récurrente lors d'utilisation de fichiers OCX ou DLL en import dans certains projets.
En effet, l'utilisation d'objets esclaves issus d'Office, Excel ou Access... est tentante car pratiques, utiles et évite un code maison acrobatique.
Mais dans les faits, le fichier exécutable fera appel à des dépendances propriétaires installés sur la machine de programmation.
Il suffira donc d'utiliser le programme sur une autre machine pour s'apercevoir qu'il ne fonctionnera pas.
En effet, ces OCX sont basés sur l'utilisation de nombreuses sous-dépendance (DLL, clés de registres) qui ne seront pas installées et donc manquantes.
Même si le terme de "Licence" nous fait penser au piratage, dans les faits, l'OCX ne trouve pas les fichiers dont il a besoin.
Il faut prioriser les "Kits" d'installation d'OCX indépendants, et éviter les OCXs d'applications intégrées qui ne seront pas exportables, sans l'installation d'une solution intégrée du type "Pack Office" et autres produits se greffant au système.
Donc, ces OCXs, même disponibles comme dépendance à utilisation "stand-alone", ont très souvent des impératifs au niveau des versions du système d'exploitation et de l'installation de patchs de mise à jour.
Leurs utilisation sont à déconseiller pour des applications portables, compatibles et distribuables.
Dans le cas d'un arrêt de compilation, voir un plantage du compilateur, et que le code vient d'une autre machine, le problème peut se résoudre en créant un nouveau projet avec les même OCX, en les ajoutant au nouveau projet.
On le sauvegarde, puis en mode texte, dans les fichiers *.VBP, il faut substituer les lignes de déclaration des OCX avec leurs versions et clés de registre du nouveau projet vers l'ancien qui ne se compile pas, (et effacer les anciens avec des références erronées)