OUVERTURE D'UN FICHIER PAR UN LOGICIEL EXTERNE

cs_Jack

Messages postés: 14007
Date d'inscription: samedi 29 décembre 2001
Statut: Modérateur
Dernière intervention: 28 août 2015

- 27 sept. 2006 à 19:49
cs_PaTaTe

Messages postés: 2107
Date d'inscription: mercredi 21 août 2002
Statut: Contributeur
Dernière intervention: 19 février 2021

- 14 oct. 2008 à 23:23

Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/39715-ouverture-d-un-fichier-par-un-logiciel-externe

cs_PaTaTe

Messages postés: 2107
Date d'inscription: mercredi 21 août 2002
Statut: Contributeur
Dernière intervention: 19 février 2021

2
14 oct. 2008 à 23:23

Je pensais ça aussi mais que dire alors des autres machines où j'ai tester la chose ? :)

cs_casy

Messages postés: 7741
Date d'inscription: mercredi 1 septembre 2004
Statut: Membre
Dernière intervention: 24 septembre 2014

41
14 oct. 2008 à 21:14

Ben ya pas de raison que ça marche pas alors puisque c'est que qui est utiliser par le système, l'explorateur entre-autre.

Ou alors ton Windows est vérolé, sinon je vois pas

cs_PaTaTe

Messages postés: 2107
Date d'inscription: mercredi 21 août 2002
Statut: Contributeur
Dernière intervention: 19 février 2021

2
14 oct. 2008 à 00:14

Un PC tout ce qui a de plus normal sous Windows XP SP3.

cs_casy

Messages postés: 7741
Date d'inscription: mercredi 1 septembre 2004
Statut: Membre
Dernière intervention: 24 septembre 2014

41
13 oct. 2008 à 17:22

Tu as quelle configuration, machine, système d'exploitation, ... ?

cs_PaTaTe

Messages postés: 2107
Date d'inscription: mercredi 21 août 2002
Statut: Contributeur
Dernière intervention: 19 février 2021

2
13 oct. 2008 à 15:03

Je sais c'est étrange ça a toujours fonctionné et il ne devrait pas en être autrement mais même ton code me sort "Pas d'association trouvée". Et pourtant l'association existe belle et bien.

cs_casy

Messages postés: 7741
Date d'inscription: mercredi 1 septembre 2004
Statut: Membre
Dernière intervention: 24 septembre 2014

41
28 sept. 2006 à 10:12

Bien vu pour les options, Renfield, vbCritical Or vbOKOnly évidement.

Pour FindExecutable aussi d'ailleur.

J'ai développer ce code au départ, car le client me demandait une option pour ouvrir le manuel d'utilisation (au format pdf) depuis la page de garde du logiciel. J'ai d'abords mis le chemin de acrobat reader en dur, mais en essayant sur plusieurs pc (version différentes de AR) je me suis appercu que suivant les version de AR, les chemins d'installation étaient différents, pas possibile de coder en dur. Puis ce n'était pas forcément AR qui était installé. De plus l'exigeance était de désactiver le bouton si AR n'était pas installé sur la machine (chose qui ne devait normalement pas arrivé, puisque les machines étaient préparées en usine avant livraison).
Dans ces logiciels là, le code est divisé en 2, la partie recherche au lancement de l'appli (sub main) et la partie "shell" sur le bouton de la doc.

BruNews, je suis d'accord avec toi, une api windows sera toujours plus rapide que l'équivalent en code vb. A voir ensuite pour chaque cas, si le gain de temps, n'est pas perdu dans les appels à l'api ou dans la souplesse du code ou autres subtilités.

BruNews

Messages postés: 21041
Date d'inscription: jeudi 23 janvier 2003
Statut: Modérateur
Dernière intervention: 21 août 2019

27
28 sept. 2006 à 00:52

CASY, que ce soit clair, je ne mets pas en cause ton code qui est tout à fait correct.

ROMIT, je tiens par contre à rectifier ce que tu dis, important si qlq débutant passe par ici.

La programmation en vue de création, il y a des langages pour cela, VB comme tout interprété est fait pour utiliser des composants, pas grand chose d'autre. Quand tu veux faire en VB ce qui est déjà fourni, même en s'appliquant ce sera toujours plus mal et donc plus lent. Personne n'y peut rien, c'est inhérent aux interprétés.
Voyons cela par l'exemple:
- On Error GoTo OuvrirFichier_Error
chargement d'enorme structure et registres sur la pile qu'il faudra enlever en sortie, très couteux en cycles et totalement inutile si fait par API qui ne déclenche jamais d'erreur mais renvoie juste une valeur pour indiquer réussite ou échec.
- temp = Dir$(fichier)
GetFileAttributes aurait dit idem si fichier existe mais sans provoquer un SysAllocString ni le SysFreeString que vb appellera en sortie de func.
- pid = Shell(fichAOuvrir, vbMaximizedFocus)
Voila où je voulais arriver, ceci nous ramène à la CASE DEPART, Shell vb est un appel à ShellExecuteEx et tout ce qui a été fait avant a été pure perte de temps car l'API fait le check complet des arguments. Elle aurait idem en interne l'appel FindExecutable mais sans les allocs désallocs mémoire comme ceux vus plus haut ou ceux ci:
i = InStr(1, fileappli, Chr(0), vbBinaryCompare) - 1
fichAOuvrir = """" & Left$(fileappli, i) & """ " & fichier

Pour résumer, ne jamais faire par VB ce qui peut être appelé en API ou autre code natif, l'utilisateur final vous en sera reconnaissant (surtout son système).

Afficher les 34 commentaires