Discussion :

[Nono23]

Bonjour,

Notre application Delphi utilise l'OCX suivant : http://www.visagesoft.com/products/p.../downloads.php

Nous faisons un enregistrement de cet OCX auprès de Windows avec la fonction "regvr32 MonOCX.ocx" sur les PC clients utilisant notre application.

Nous rencontrons depuis peu un problème particulier sur une configuration "Terminal Server" sur "Windows Server 2008 R2 64 bits"

Pour certains utilisateurs windows (qui semblent complètement identiques à d'autres pour qui tout fonctionne très bien), l'enregistrement de l'OCX n'est pas détecté au démarrage de leur session TS.

Nous avons essayé les éléments suivants :
- Réenregistrement de l'OCX
- Réenregistrement de l'OCX en phase install (change user /install)
- Réenregistrement de l'OCX en administrateur system
- Réenregistrement de l'OCX en mode system (regsvr32 /System MonOCX.ocx)
- Réenregistrement en utilisant le regsvr32 de System32
- Réenregistrement en utilisant le regsvr32 de Sys64Wow
- Déplacement de l'OCX dans System32
- Déplacement de l'OCX dans Sys64Wow
- Déplacement de l'OCX dans C:\Windows
- Attribuer les droits d'administrateur local et réseau à l'utilisateur qui rencontre le problème
- Toutes ces étapes en exécutant le tout en tant qu'admin
- Invoquer le saint des OCX
- Prier

Rien n'y fait.

Chez l'un de nos client qui a environs 50 connexions TS, 3 utilisateurs ne fonctionnent pas du tout (L'ocx n'est jamais détecté).
Chez un autre client, un seul utilisateur rencontre un problème, il y a un délai à attendre (environ 20 secondes) entre l'ouverture de la session TS et le lancement de l'application pour que l'OCX ait "le temps" d'être détecté.

J'avoue que là je sèche complètement. Quelqu'un a-t-il déjà rencontré ce genre de problème? Avez-vous une idée de la cause de ce problème ou un moyen pour le résoudre?

Merci d'avance de vos réponses

Nono23

[BenjGe]

jamais rencontré ce type de problèmes, mais les ocx sont pleins de surprise. Premier point on va se mettre d'accord sur le 32bits et 64bits.
-Si mon appli est 64bits elle utilise les ocx 64bits et mon windows est 64 bits. Dans ce cas l'ocx 64bits doit être placé dans system32 et enregistré avec le regsvr32 qui est placé dans system32, pour s'en assurer lancer la commande cmd du dossier system32

-si mon appli est 32bits elle utilise les ocx 32bits et mon windows peut être 32 ou 64bits.
Dans ce cas:
-si mon windows est 32 bits: ocx 32bits dans system32, et regsvr32 de system32 (de toute façon il n'y a que ça)
-si mon windows est 64bits: ocx 32bits dans syswow64 et enregistré avec regsvr32 de syswow64 (pour s'en assurer lancer l'invite de commande cmd du dossier syswow64).

pour reprendre votre problème, tout marchait bien juqu'à il y a quelques temps c'est bien ça? Et aujourd'hui ça ne marche plus? Donc soit c'est une mise à jour qui est reponsable, soit un déploiement logiciels.
Comment l'OCX peut il être touché?
- soit c'est lui-même qui a été mis à jour, auquel cas il faut revenir sur cette maj
- soit cet ocx a des dépendances et ce sont les dépendances qui ont été mises à jour.

Pour explorer cette piste il faut utiliser le logiciel dependency walker qui va montrer les dépendances non satisfaites. Attention à la sortie de ce programme, toutes les dll qu'il liste ne sont pas pertinentes.

[Nono23]

Bonjour Berjile,

Merci beaucoup pour votre retour et vos explications. Je vais commencer par reprendre au départ et partir sur votre explication d'enregistrement pour un OCX (Donc notre application) en 32 bits sur un OS 64 bits.

Concernant la rencontre de cette erreur, je me suis mal exprimée en fait. Nous n'utilisons cet OCX que depuis peu et nous venons de nous rendre compte de ce problème sur TS 64 bits. mais je pense qu'il a toujours été présent depuis que nous utilisons ce système. Nous commençons seulement à mettre en place la version avec l'OCX chez nos clients. Je vais faire un tour du côté de dependency walker pour voir si je peux en tirer quelque chose. je vous tiendrai au courant.

Merci encore.

Noémie