Lancer une application d'assistance mime enregistrée

Question

J'avais l'habitude de pouvoir lancer une application d'assistance installée localement en enregistrant un type mime donné dans le registre Windows. Cela m'a permis de permettre aux utilisateurs de cliquer une fois sur un lien vers l'installation en cours de notre application de navigateur interne. Cela a bien fonctionné dans Internet Explorer 5 (la plupart du temps) et Firefox, mais ne fonctionne plus dans Internet Explorer 7.

Le nom de fichier transmis à mon shell / open / command n'est pas le chemin d'accès physique complet au package d'installation téléchargé. Le paramètre de chemin que je reçois par IE est

"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\
  EIPortal_DEV_2_0_5_4[1].expd"

Cela ne résout malheureusement pas le fichier physique lors de l'appel de FileExists () ou lors de la tentative de création d'un objet TFileStream .

Le chemin physique manque dans le sous-répertoire de mise en cache masqué d'Internet Explorer pour les fichiers Internet temporaires de "Content.IE5 \ ALBKHO3Q" dont le chemin absolu serait exprimé par

.

"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\ 
  Content.IE5\ALBKHO3Q\EIPortal_DEV_2_0_5_4[1].expd"

Oui, les sous-répertoires sont générés aléatoirement par IE et cela ne devrait pas poser de problème tant que IE passe le chemin complet vers mon application d'assistance, ce qu'elle ne fait malheureusement pas.

L'installation de l'application mime helper n'est pas un problème. Il est installé / mis à jour par un script de connexion global pour plus de 10 000 utilisateurs dans le monde. L'assistant mime n'est appelé que lorsque l'utilisateur clique sur une page Web interne avec un lien vers une installation de notre application de navigateur Desktop. Cette installation est rendue avec un type mime de "application / x-expeditors" . L'enregistrement du type mime ".expd" / "application / x-expeditors" ressemble à ceci.

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.expd] 
@="ExpeditorsInstaller"
"Content Type"="application/x-expeditors"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller]
"EditFlags"=hex:00,00,01,00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell\open]
@=""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell\open\command]
@="\"C:\\projects\\desktop2\\WebInstaller\\WebInstaller.exe\" \"%1\""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MIME\Database\Content Type\application/x-expeditors]
"Extension"=".expd"

J'avais envisagé d'énumérer toutes les entrées de cache IE d'un utilisateur, mais je voudrais savoir combien de temps il faudrait pour les examiner toutes ou que je pourrais finir par trouver une entrée de cache plus ancienne avant l'entrée actuelle que je recherche. Toutefois, le suffixe de nom de fichier entre crochets "[n]" et peut être la clé unique.

J'ai essayé la méthode wininet GetUrlCacheEntryInfo mais cela nécessite l'URL, pas le chemin virtuel fourni par IE.

J'espère qu'il existe une fonction Shell qui, à l'aide d'un chemin virtuel, rendra le chemin physique.

Answer 1

Un suivi pour clore cette question.

En réalité, le vrai problème était de savoir comment je créais le descripteur de fichier avec TFileStream. J'ai changé pour ouvrir avec fmOpenRead ou fmShareDenyWrite , ce qui a résolu le problème de verrouillage des fichiers.

srcFile := TFileStream.Create(physicalFilename, fmOpenRead or fmShareDenyWrite);

Answer 2

Je pense que les sous-répertoires créés par IE sont générés aléatoirement. Par conséquent, vous ne serez pas en mesure de garantir qu'il porte toujours le même nom, et le problème que je vois avec la méthode de registre est qu'il ne fonctionne que lorsque le fichier est toujours dans le cache ... vider le cache purgerait le fichier et nécessiterait une autre installation.

Ne serait-il pas préférable d'installer cette aide dans les données d'application?

Answer 3

Je ne suis pas sûr de cela, mais peut-être que cela vous mènera dans la bonne direction: essayez d'utiliser les fonctions de cache d'URL à partir de la DLL Wininet: FindFirstUrlCacheEntry , FindNextUrlCacheEntry , FindCloseUrlCache pour l'énumération et lorsque vous localisez une entrée dont le nom de fichier local correspond au chemin indiqué, vous pouvez peut-être utiliser RetrieveUrlCacheEntryFile pour récupérer le fichier.

Answer 4

J'utilise un système similaire avec le navigateur X-Appl pour afficher les applications Web WAML et cela fonctionne parfaitement. Peut-être devriez-vous regarder comment ils ont réussi à le faire.

Answer 5

Il semble que iexplore passe l'espace de noms du shell, "name". du fichier plutôt que le nom du système de fichiers.

Je ne pense pas qu'il existe un moyen documenté de transmettre un identifiant d'élément shell sur la ligne de commande - l'explorateur le fait lui-même, mais il existe des considérations de marshaling, car les identifiants d'éléments shell sont (pointeurs sur) des structures de données binaires uniquement valides. en un seul processus.

Ce que je pourrais essayer de faire est: 1. Appelez SHGetDesktopFolder qui retournera l'objet IShellFolder racine de l'espace de noms du shell. 2. Appelez IShellFolder :: ParseDisplayName pour transformer le nom qui vous est donné en liste d'identifiant d'élément de shell. 3. Essayez le IShellFolder :: GetDisplayNameOF avec le drapeau SHGDN_FORPARSING - qui, franchement, donne l’impression que nous venons de former un cercle complet et que nous sommes revenus à l’origine. Parce que je pense que c'est cette API qui est responsable en dernier ressort de renvoyer le "faux". chemin relatif du système de fichiers.