2010-04-09 2 views
5

Una domanda simile è già stato chiesto, quindi non ho intenzione di perdere tempo a ri-spiegarlo, una discussione esistente può essere trovato qui: ToAscii/ToUnicode in a keyboard hook destroys dead keysCome posso utilizzare ToUnicode senza interrompere il supporto della chiave morta?

Il motivo sto postando una nuova domanda, tuttavia, è che Mi sembra di aver trovato una "soluzione", ma non sono abbastanza sicuro su come implementarla.

questo post del blog sembra proporre una soluzione al problema della ToUnicode uccidere sostegno dead-chiave: http://www.siao2.com/2005/01/19/355870.aspx

Tuttavia non sono sicuro di come implementare la soluzione suggerita. Una spinta nella giusta direzione sarebbe molto apprezzata.

Per essere chiari, la parte a cui mi riferisco è questo:

Ci sono due modi per risolvere questo:

1) È possibile continuare a chiamare ToUnicode con le stesse informazioni fino a quando non viene cancellato e poi richiamato un'altra volta per riportare lo stato dove era se non avevi mai digitato nulla, oppure

2) Puoi caricare tutte le informazioni della tastiera prima del tempo e poi quando digitano le informazioni puoi cercare nella tua cache di informazioni cosa significano le sequenze di tasti, senza dover chiamare le API in ritardo r.

Non sono abbastanza sicuro di come fare nessuna di quelle cose (le tastiere e l'internazionalizzazione sono lontane dal mio punto di forza), quindi qualsiasi aiuto sarebbe molto apprezzato.

Grazie

risposta

4

La prima parte della risposta è interamente informazioni-libera. Tuttavia, la seconda parte ha senso. ToUnicode()dovrebbe essere è stata una funzione pura, che agisce semplicemente come una ricerca. Tuttavia, non lo è. Ma puoi chiamarlo ripetutamente per tutti gli input previsti, archiviarli nella tua tabella di ricerca e accedervi.

Si consiglia di aggiungere un flag lookDontTouch al parametro wFlags; questa sarebbe una banale soluzione API non distruttiva.

+5

ma fissare l'API Win32 sarebbe un pericoloso precedente da impostare. Pensa alla quantità di lavoro che avrebbero davanti a loro se iniziano il percorso * that *. – jalf

+0

@jalf: non sono sicuro che sia sarcastico. i18n/l10n di Windows è in sviluppo attivo. Per questo particolare bit probabilmente non vogliono il codice .Net (la gestione della tastiera è piuttosto di basso livello), quindi la risoluzione dell'API Win32 è una proposta ragionevole, probabilmente l'unica. – MSalters

+0

Qualche possibilità di un esempio di codice per spingermi nella giusta direzione? Sono imbarazzato nel dire che sono ancora un po 'perso. Uh, odio così tanto questa roba da tastiera. Grazie. – RaptorFactor

0

Se si amplia la ricerca per includere key logging, è possibile ottenere alcune risposte. Il metodo presentato nel collegamento è estremamente macchinoso rispetto a ToUnicode, ma funziona. Si evolve intorno alla ricerca dell'attuale layout di tastiera attivo dal registro e quindi carica e analizza manualmente la DLL corretta.

Come nota di avviso, ho visto la parte di caricamento fallire miseramente su Windows 64-bit.

+0

Ho eseguito alcuni test rapidi e sembra che il codice abbia effettivamente esito negativo nelle versioni x64 di Windows a meno che il codice non sia compilato in modo nativo per x64. Ugh, questo è tutto così doloroso. Grazie però, questa sembra essere un'opzione interessante. – RaptorFactor