Erreur d'exécution d'appli avec runtime

[Rick]

Bonjour,

J'ai empacketé mon appli access avec le runtime.
L'installation sur un poste ne possedant pas access ne
pose pas de problème. Le message d'erreur "Cette
application a été arrêtée à cause d'une erreur
d'exécution. Elle ne peut pas continuer et va être
arrêtée" apparait lorsque je me trouve dans l'appli
installée.
Après plusieurs tests voila les faits :
- l'installation passe correctement
- lors de l'empacketage certaines DLL se placaient dans
le répertoire de l'appli et non pas dans le répertoire
system32
- les pages ne contenant pas d'activeX onglet ou
treeview s'affichent sans déclencher l'erreur.

Connaissez vous ce problème?
Cela peut il venir de fichiers .ocx ou .dll manquant sur
le poste d'installation?
Comment déterminer quels sont les fichiers .ocx ou .dll
utilisée par des controles activeX?

Merci d'avance

[Benoit Compoint [MS]]

Bonjour,

Tout d'abord il est important de retenir qu'Access 97 et les versions
suivantes intègrent un contrôle "Onglet".
Il n'est donc pas nécessaire d'utiliser un contrôle ActiveX pour gérer des
onglets dans une application Access.

Pour afficher la liste des contrôles ActiveX utilisés dans votre application
MDB,
vous pouvez ouvrir un module VBA de l'application sur votre poste de
développement
et choisir la commande "Références" dans le menu "Outils".
Quand un contrôle ActiveX est inséré dans un formulaire, le fichier
correspondant est automatiquement ajouté à cette liste.
Cependant si vous supprimez ultérieurement le formulaire concerné (ou le
contrôle ActiveX qu'il contient),
la référence vers ce contrôle est conservée.
La liste des références peut donc contenir les noms de contrôles ActiveX
inutilisés.
Dans ce cas il est conseillé de décocher manuellement ces références avant
de redistribuer l'application MDB.

Vous pouvez ouvrir le fichier d'extension DEP associé à chaque fichier OCX
pour lire la liste des DLL à redistribuer avec le contrôle ActiveX :
par exemple COMCTL32.DEP est associé à COMCTL32.OCX.

Enfin je vous recommande de lire la page Web suivante :
http://support.microsoft.com/?id=194374

Benoit Compoint

"Rick" <***@wanadoo.fr> wrote in message news:06cb01c3da7d$7a5cb8d0$***@phx.gbl...
Bonjour,

J'ai empacketé mon appli access avec le runtime.
L'installation sur un poste ne possedant pas access ne
pose pas de problème. Le message d'erreur "Cette
application a été arrêtée à cause d'une erreur
d'exécution. Elle ne peut pas continuer et va être
arrêtée" apparait lorsque je me trouve dans l'appli
installée.
Après plusieurs tests voila les faits :
- l'installation passe correctement
- lors de l'empacketage certaines DLL se placaient dans
le répertoire de l'appli et non pas dans le répertoire
system32
- les pages ne contenant pas d'activeX onglet ou
treeview s'affichent sans déclencher l'erreur.

Connaissez vous ce problème?
Cela peut il venir de fichiers .ocx ou .dll manquant sur
le poste d'installation?
Comment déterminer quels sont les fichiers .ocx ou .dll
utilisée par des controles activeX?

Merci d'avance

[a***@discussions.microsoft.com]

Merci de ces précisions, cela est très utile.

Après une grande série de test d'empacketage avec des
morceaux de mon appli, j'ai pu préciser un peu plus les
origines du problème :
- si je supprime completement le code de mon formulaire
en laissant les objets en place, ca ne plante pas.
- dès que le code concerne le recordsource d'un
sous_formulaire ou le controlsource d'un objet, ca plante.
- dès que le code concerne mon treeview, ca plante.

J'ai pourtant join a mon package tous les .dll demandés
par mes activeX.

Pensez vous que cela puisse venir quand même d'un décalage
entre les bibliothèques de type?
Si c'est le cas, comment puis je intégrer les
bibliothèques de mon poste de développement dans le
package pour qu'elles soient intégrées dans le poste
client?

-----Message d'origine-----
Bonjour,
Tout d'abord il est important de retenir qu'Access 97 et

les versions

suivantes intègrent un contrôle "Onglet".
Il n'est donc pas nécessaire d'utiliser un contrôle

ActiveX pour gérer des

onglets dans une application Access.
Pour afficher la liste des contrôles ActiveX utilisés

dans votre application

MDB,
vous pouvez ouvrir un module VBA de l'application sur

votre poste de

développement
et choisir la commande "Références" dans le menu "Outils".
Quand un contrôle ActiveX est inséré dans un formulaire,

le fichier

correspondant est automatiquement ajouté à cette liste.
Cependant si vous supprimez ultérieurement le formulaire

concerné (ou le

contrôle ActiveX qu'il contient),
la référence vers ce contrôle est conservée.
La liste des références peut donc contenir les noms de

contrôles ActiveX

inutilisés.
Dans ce cas il est conseillé de décocher manuellement ces

références avant

de redistribuer l'application MDB.
Vous pouvez ouvrir le fichier d'extension DEP associé à

chaque fichier OCX

pour lire la liste des DLL à redistribuer avec le
par exemple COMCTL32.DEP est associé à COMCTL32.OCX.
http://support.microsoft.com/?id=194374
Benoit Compoint
Bonjour,
J'ai empacketé mon appli access avec le runtime.
L'installation sur un poste ne possedant pas access ne
pose pas de problème. Le message d'erreur "Cette
application a été arrêtée à cause d'une erreur
d'exécution. Elle ne peut pas continuer et va être
arrêtée" apparait lorsque je me trouve dans l'appli
installée.
- l'installation passe correctement
- lors de l'empacketage certaines DLL se placaient dans
le répertoire de l'appli et non pas dans le répertoire
system32
- les pages ne contenant pas d'activeX onglet ou
treeview s'affichent sans déclencher l'erreur.
Connaissez vous ce problème?
Cela peut il venir de fichiers .ocx ou .dll manquant sur
le poste d'installation?
Comment déterminer quels sont les fichiers .ocx ou .dll
utilisée par des controles activeX?
Merci d'avance
.

[r***@wanadoo.fr]

J'ai résolu mon problème.
L'erreur d'exécution ne venait aucunement de .dll manquant
ou de décalage entre bibliothèques.
Cela venait tout simplement de la localisation des tables
liées. Je fabriquais mon package dans mon répertoire de
développement et le chemin d'accès aux tables liées était
le même alors que lors de l'installation de l'application
elles étaient situées dans c:\program files\...

Merci de votre aide.

-----Message d'origine-----
Merci de ces précisions, cela est très utile.
Après une grande série de test d'empacketage avec des
morceaux de mon appli, j'ai pu préciser un peu plus les
- si je supprime completement le code de mon formulaire
en laissant les objets en place, ca ne plante pas.
- dès que le code concerne le recordsource d'un
sous_formulaire ou le controlsource d'un objet, ca plante.
- dès que le code concerne mon treeview, ca plante.
J'ai pourtant join a mon package tous les .dll demandés
par mes activeX.
Pensez vous que cela puisse venir quand même d'un

décalage

entre les bibliothèques de type?
Si c'est le cas, comment puis je intégrer les
bibliothèques de mon poste de développement dans le
package pour qu'elles soient intégrées dans le poste
client?

-----Message d'origine-----
Bonjour,
Tout d'abord il est important de retenir qu'Access 97 et

les versions

suivantes intègrent un contrôle "Onglet".
Il n'est donc pas nécessaire d'utiliser un contrôle

ActiveX pour gérer des

onglets dans une application Access.
Pour afficher la liste des contrôles ActiveX utilisés

dans votre application

MDB,
vous pouvez ouvrir un module VBA de l'application sur

votre poste de

développement
et choisir la commande "Références" dans le

menu "Outils".

Quand un contrôle ActiveX est inséré dans un formulaire,

le fichier

correspondant est automatiquement ajouté à cette liste.
Cependant si vous supprimez ultérieurement le formulaire

concerné (ou le

contrôle ActiveX qu'il contient),
la référence vers ce contrôle est conservée.
La liste des références peut donc contenir les noms de

contrôles ActiveX

inutilisés.
Dans ce cas il est conseillé de décocher manuellement

ces

références avant

de redistribuer l'application MDB.
Vous pouvez ouvrir le fichier d'extension DEP associé à

chaque fichier OCX

pour lire la liste des DLL à redistribuer avec le
par exemple COMCTL32.DEP est associé à COMCTL32.OCX.
http://support.microsoft.com/?id=194374
Benoit Compoint
Bonjour,
J'ai empacketé mon appli access avec le runtime.
L'installation sur un poste ne possedant pas access ne
pose pas de problème. Le message d'erreur "Cette
application a été arrêtée à cause d'une erreur
d'exécution. Elle ne peut pas continuer et va être
arrêtée" apparait lorsque je me trouve dans l'appli
installée.
- l'installation passe correctement
- lors de l'empacketage certaines DLL se placaient dans
le répertoire de l'appli et non pas dans le répertoire
system32
- les pages ne contenant pas d'activeX onglet ou
treeview s'affichent sans déclencher l'erreur.
Connaissez vous ce problème?
Cela peut il venir de fichiers .ocx ou .dll manquant sur
le poste d'installation?
Comment déterminer quels sont les fichiers .ocx ou .dll
utilisée par des controles activeX?
Merci d'avance
.

.