Avvio di un'applicazione di aiuto mime registrata

Question

Prima ero in grado di avviare un'applicazione di supporto installata localmente registrando un dato tipo mime nel registro di Windows. Ciò mi ha permesso di consentire agli utenti di fare clic una volta su un collegamento all'installazione corrente della nostra applicazione browser interna. Funzionava bene in Internet Explorer 5 (la maggior parte delle volte) e Firefox, ma ora non funziona in Internet Explorer 7.

Il nome del file passato al mio comando shell / open / non è il percorso fisico completo del pacchetto di installazione scaricato. Il parametro del percorso che mi viene assegnato da IE è

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

Purtroppo questo non si risolve nel file fisico quando si chiama FileExists () o quando si tenta di creare un oggetto TFileStream .

Nel percorso fisico manca la sottodirectory della cache nascosta di Internet Explorer per i file temporanei Internet di " Content.IE5 \ ALBKHO3Q " il cui percorso assoluto verrebbe espresso come

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

Sì, le sottodirectory sono generate casualmente da IE e questo non dovrebbe essere un problema fintanto che IE passa l'intero percorso alla mia applicazione di supporto, cosa che purtroppo non sta facendo.

L'installazione dell'applicazione helper mime non è un problema. È installato / aggiornato da uno script di accesso globale per tutti gli oltre 10.000 utenti in tutto il mondo. L'helper mime viene invocato solo quando l'utente fa clic su una pagina Web interna con un collegamento a un'installazione della nostra applicazione browser desktop. Tale installazione viene restituita con un tipo mime di " application / x-expeditors " . La registrazione del " .expd " / " application / x-expeditors " mime-type è simile a questo.

[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"

Avevo preso in considerazione l'enumerazione di tutte le voci della cache IE di un utente, ma mi sarei preoccupato di quanto tempo ci sarebbe voluto per esaminarle tutte o che potrei finire per trovare una voce di cache più vecchia prima della voce corrente che sto cercando. Tuttavia, il suffisso del nome file tra parentesi " [n] " potrebbe essere la chiave univoca.

Ho provato il metodo Wininet GetUrlCacheEntryInfo ma questo richiede l'URL, non il percorso virtuale consegnato da IE.

La mia speranza è che esista una funzione Shell che, dato un percorso virtuale, restituisca il percorso fisico.

Answer 1

Alcuni follow-up per chiudere questa domanda.

Si è scoperto che il vero problema era come stavo creando l'handle di file usando TFileStream. Ho cambiato per aprire con fmOpenRead o fmShareDenyWrite che ha risolto quello che si è rivelato essere un problema di blocco dei file.

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

Answer 2

Credo che le sottodirectory create da IE vengano generate casualmente, quindi non sarai in grado di garantire che verrà nominato lo stesso ogni volta, e il problema che vedo con il metodo del registro è che funziona solo quando il il file è ancora nella cache ... svuotando la cache si eliminerebbe il file che richiede ancora un'altra installazione.

Non sarebbe meglio installare questo helper nei dati dell'applicazione?

Answer 3

Non ne sono sicuro, ma forse questo potrebbe portarti nella giusta direzione: prova a utilizzare le funzioni di cache URL dalla DLL wininet: FindFirstUrlCacheEntry , FindNextUrlCacheEntry , FindCloseUrlCache per l'enumerazione e quando si individua una voce il cui nome file locale corrisponde al percorso specificato, è possibile utilizzare RetrieveUrlCacheEntryFile per recuperare il file.

Answer 4

Sto usando un sistema simile con il browser X-Appl per visualizzare le applicazioni web WAML e funziona perfettamente. Forse dovresti dare un'occhiata a come sono riusciti a farlo.

Answer 5

Sembra che iexplore stia passando lo spazio dei nomi della shell " name " del file anziché il nome del filesystem.

Non penso che ci sia un modo documentato per passare un ID elemento shell sulla riga di comando - Explorer lo fa da solo, ma ci sono considerazioni di marshalling poiché gli ID oggetto shell sono (puntatori a) strutture di dati binari che sono valide solo in un unico processo.

Quello che potrei provare a fare è: 1. Chiamare SHGetDesktopFolder che restituirà l'oggetto IShellFolder radice dello spazio dei nomi della shell. 2. Chiamare IShellFolder :: ParseDisplayName per trasformare il nome che viene restituito in un elenco ID elemento shell. 3. Prova IShellFolder :: GetDisplayNameOF con il flag SHGDN_FORPARSING - che, francamente, sembra che siamo appena entrati in un cerchio completo e siamo tornati da dove siamo partiti. Perché ritengo che questa API sia in definitiva responsabile della restituzione del messaggio "errato" percorso relativo del filesystem.