Discussion :

[cpf2006]

Bonjour,

J'ai un exécutable codé en VB6.
Celui-ci doit s'exécuter aussi bien dans Windows 7 que Windows 10.
Je dois ouvrir des documents Word.
Cependant, VB6 est installé dans Windows 7.
Les librairies référencées sont :

MS Word 14 (pour Windows 7)
MS Office 15 (pour Windows 10)

Voici le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
        Dim objWord As Word.Application
        Dim DocWord As Word.Document
        Dim fichier As String
        fichier = param1        
 
        If FileExiste(fichier) Then
 
            Set objWord = CreateObject("Word.Application")   '-- ouvrir le processus Word 
            Sleep 200
            Set DocWord = objWord.Documents.Open(fichier)    '-- ouvrir le document Word
            Sleep 200
            objWord.Visible = True    '-- masquer ou non l'application Word
            Sleep 100
                Set objWord = Nothing
            Set DocWord = Nothing
 
            End If

Le problème est que lorsque l'exe tourne dans Win10, les documents word mettent 10'' (min) à s'ouvrir tandis que dans Win7, le document Word s'ouvre en 3 ou 4" !
Je pense que cela est dû au fait que le script doit chercher après la bonne librairies.
D'où ma demande :
Est-ce possible d'ajouter les références dans le code de manière dynamique en fonction de l'OS ?

merci pour votre aide

Carmelo

[ProgElecT]

Salut

Un peu plus de précision.
Avant tout, Sleep 200 n'est pas du VB6 (à moins que tu ais codé une une fonction maison), cela serait plutôt du code VbScript, mais dans ce cas je ne comprends pas que tu ais typé tes variables.
De ta réponse différera les nôtres.

[cpf2006]

Bonjour ProgElect

Le problème ne concerne pas Sleep mais les librairies à ajouter.

mais si cela peut te faire plaisir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)

Concernant les librairies, je voudrais savoir si on peut choisir les librairies non pas par la méthode manuelle comme par exemple (trouvé dans le forum) :
"Pour activer une bibliothèque (référence), déplacez vous dans l'éditeur de macros (ALT+F11):
Menu Outils
Références
Cochez la ligne qui correspond à l'application que vous souhaitez piloter.
Cliquez sur le bouton OK pour Valider.
Vous avez désormais accès aux méthodes et propriétés VBA de l'application spécifiée."

!!! Je précise que je travaille avec VB6 et non VBA !!! donc ce qui précède est n'est pas tout à fait adapté à VB6

Mais plutôt de manière dynamique, comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
 Shell + regsvr32 /s lefichier.OLB

Ce qui me permettrait en fonction de l'OS, de choisir le bon fichier (word15 ou word14)
Bien que je ne pense pas que je pourrais compiler sans avoir coché les références.

Ici un article qui parle de ce dont je voudrais faire mais dans VB6 et non VBA (liaison tardive) en déclarant toutes les variables "Word.Application" en Object

Merci d'avance

Carmelo

[ProgElecT]

Re

mais si cela peut te faire plaisir

Le problème ne concerne pas Sleep mais les librairies à ajouter.

Là n'est pas mon propos dans ma première intervention, mais certains poste une question dans un forum alors qu'ils ne sont pas au bon endroit (fin de la parenthèse ).

Je dirai simplement, dans ton package d’installation, tu référence la librairie la plus performante, cela ne devrait pas poser de problème d'installation, quelque soit l'OS (7 ou 10).

Ou je n'ai rien compris à ta question, ce qui est possible.

[clementmarcotte]

Bonjour,

Si tu passes par CreateObject, tu peux te passer des références aux bibliothèques. (Mais pas avec GetObject). Je ne me souviens pas pour VB6, mais en VBA, ajouter la référence donne aussi accès à l'IntelliSense entre Word et Excel, du moins.

[cpf2006]

Bonjour clementmarcotte

Merci pour la réponse.
En effet, en VBA j'ai trouvé une solution.
A l'ouverture du fichier excel, je détecte l'os et j'ajoute les librairies.
A la fermeture du fichier, je supprime les librairies de manière à pouvoir les ouvrir dans un autre OS.

Mais ça, c'est en VBA avec un fichier à ouvrir avec des macros à exécuter.
Tandis qu'en VB6, c'est exécutable. La tâche est donc plus hardue.

Merci pour ton aide

Carmelo

[cpf2006]

A ProgElec,

Merci pour ta réponse.

Le fait est qu'à partir du même exécutable, en Win7 il me faut 3 à 4 secondes pour ouvrir le document Word.
Tandis qu'en Win10, il faut le double minimum ... !!!

Je précise que mon Win10 est celui de développement, qu'il a 32 gigas de mémoire RAM et tourne en 64bits
que le Win7 a 4gigas et tourne en 32bits

Quelles pourraient être les raisons ?

Merci

Carmelo

[clementmarcotte]

Bonjour clementmarcotte


A l'ouverture du fichier excel, je détecte l'os et j'ajoute les librairies.


Carmelo

Relis bien ce que je t'ai dit. Avec CreateObject, tu n'as bas besoin de cocher les références aux applications Office. Avec CreateObject et GetObject, tu travailles en liaison tardive (Late binding) et Windows ouvre l'application Office sur la machine. Cocher les références c'est pour travailler en liaison précoce, (early binding). Utiliser les deux en même temps, ne fait qu'améliorer l'IntelliSense quand on utilise CreateObject.

Ajouté:

Et puis, je suis toujours d'accord avec moi-même, et j'ai subitement envie de continuer de prêcher dans le désert. Pour travailler avec des parc hétéroclites d'Office, c'est mieux d'utiliser VB.net et les Primary Interop Assemblies d'Office(ou tout langage compatible avec la plate-forme .net) que d'utiliser VB6 ou VBA. Tout simplement parce que les PIAs ont le même GUID depuis Office 2003. Pour autant que les PIAs soient installés (ils sont disponibles sur le site de Microsoft) et que l'on essaie pas une nouveauté d'une version sur une version plus ancienne, cela se passe généralement sans problème et sans avoir à tripoter les références.

[l_autodidacte]

Mais ça, c'est en VBA avec un fichier à ouvrir avec des macros à exécuter.
Tandis qu'en VB6, c'est exécutable. La tâche est donc plus hardue ardue.

Quel que soit l'EDI, CreateObject avec le bon ProgId recherche la bonne bibliothèque avec la bonne version(installée sur le système) et l'exploite. La différence de durée d'affichage est due, comme déjà mentionné, à la liaison tardive et peut-être aussi au nombre d'applications et processus ouverts pendant l'exécution du programme en question. Un antivirus configuré de façon à ne rien laisser passer sans vérification, peut très bien ralentir l'affichage et ce selon l'antivirus installé.
Mais si MS office n'est pas installé sur la machine cible, c'est là qu'il faut ajouter les références.

Est-ce possible d'ajouter les références dans le code de manière dynamique en fonction de l'OS ?

Dans ton programme d'installation, tu devrais peut-être ajouter toutes les références pour les OS susceptibles de recevoir ton programme et mettre une condition sur MS Office et/ou l'OS installé et suivant l'existence de l'une ou l'autre version de MS Office, tu copies les fichiers dont tu as besoin dans un dossier de ton choix et selon la version voulue(de préférence un sous-dossier du dossier principal du programme). De cette façon, on évite le conflit de versions et le remplacement de fichiers nécessaires à d'autres applications.

[cpf2006]

Bonjour clementmarcotte

Merci pour tes remarques.

Cependant, je travaille pour une entreprise. Cet exécutable est (et il était avant que je n'arrive) en VB6.
Je suis en train de recoder cet "exe" en Java, mais en attendant c'est toujours le premier qui est utilisé.

Mes documents à ouvrir sont des documents "Word". L'exemple que j'ai pris pour Excel n'est que pour faire comprendre le sens de ma question.

Je reviens donc à mon dernier post concernant la vitesse d'ouverture.

J'ai retiré toute référence et travaille en liaison tardive.

Cependant, avec le même exécutable, en Win7 il me faut 3 à 4 secondes pour ouvrir le document Word.
Tandis qu'en Win10, il faut le double minimum ... !!!

Je précise que mon Win10 est celui de développement, qu'il a 32 gigas de mémoire RAM et tourne en 64bits
que le Win7 a 4gigas et tourne en 32bits

Quelles pourraient être les raisons ?

Merci d'avance pour les pistes ...

Cpf

[cpf2006]

Bonjour l'Autodicdate,

Je n'avais pas lu ta réponse et te remercie pour celle-ci.
J'ai donc enlevé les références et déclare les variables comme "Object"
mais le problème reste exactement le même à savoir que l'ouverture du Word chez les utilisateurs est plus lent dans Win10 que dans Win7.

La solution que tu décris ci-dessus :
"Dans ton programme d'installation, tu devrais peut-être ajouter toutes les références pour les OS susceptibles de recevoir ton programme et mettre une condition sur MS Office et/ou l'OS installé et suivant l'existence de l'une ou l'autre version de MS Office, tu copies les fichiers dont tu as besoin dans un dossier de ton choix et selon la version voulue(de préférence un sous-dossier du dossier principal du programme). De cette façon, on évite le conflit de versions et le remplacement de fichiers nécessaires à d'autres applications"

Je ne vois à quoi ça correspond, ni comment mettre ça en place.
Je suis en VB6 dans un exécutable ... c'est justement l'objet du post :
"comment ajouter des références dynamiquement dans le code lors de l'exécution et en VB6"

Merci d'avance

cpf

[clementmarcotte]

"comment ajouter des références dynamiquement dans le code lors de l'exécution et en VB6"

Merci d'avance

cpf

Que c'est donc dur à trouver et cela ne changera rien.
Word, Excel, PowerPoint etc., c'est la même chose.
Mais, puisqu'il faut chercher à ta place et que deux mots dans un moteur recherche c'est assez et que quelqu'un, à quelque part, me donne des points. .

Le premier de la page des résultats lien mène là. Et ils disent la même chose que moi. CreateObject, pas besoin de la référence.

Le troisième lien mène là

Tu vas devoir changer manuellement tous les Word qui doivent subir ton programme. Il faut cocher faire confiance au projet Visual Basic.

[cpf2006]

salut ClémentMarmotte,

Merci quand même pour ta contribution.
Néanmoins, je n'apprécie pas le ton sur lequel tu adresses tes remarques ni les des procès d'intention que tu me fais.
Il est inutile de t'attaquer à ma personne ! C'est désagréable sans compter l'atmosphère lourde que tes propos donnent sur les forums (mais tu n'est pas le seul).
T'autant plus que tu ne m'apportes aucune solution ... c'est p'têt d'ailleurs ça le but, compenser ton manque de réponse par la dévalorisation des questionneurs, toujours supposés plus idiots que toi (mais à d'autres aussi qui vous croyez avoir la science infuse ...)
Relis bien mes messages : je travaille en VB6 !!! en non en VBA !!!
Ton "CreateObject", je l'ai testé de mille manière ... avec et sans référence ... mais rien n'y fait : sur Win10, c'est toujours plus lent et pas que sur mon pc ... avec ou sans anti-virus ... ou d'autres programmes en même temps ...
Mais bon, c'est assez !
Je laisse tomber ce post, je n'ai plus besoin de tes réponses lol
Je trouverai bien la réponse sur d'autres forums ...

cpf

[clementmarcotte]

Aie.

Createobject est déjà dans ton code. Si tu veux t'en débarrasser, c'est un autre problème

Tant que tu vas garder CreateObject dans ton code, tu n'as pas besoin de référence. Si tu enlèves CreateObjet, tu as besoin des références.

Ajouter les références par programmation va peut-être accélérer le chargement du fichier, mais ce n'est pas sûr

Que tu utilises VB6, JAVA, COBOL, ADA, RPG, Pascal, Fortran ou VBA, ajouter des références par programmation, comporte d'importants problèmes de sécurité.

Je t'ai dit que la façon la plus simple de procéder dans un parc hétéroclite d'Office, c'est VB.net, ou out autre langage .net avec la référence aux Primary Interop Assemblies d'Office.

Et puis avec la plate-forme .net, pas en JAVA, mais en .net, tu peux faire de l'Excel, du Word, du PowerPoint sans même avoir l'application sur ta machine.