AxAcroPDF sluk sleutels, hoe om dit te kry om op te hou?

StackOverflow https://stackoverflow.com/questions/3074857

  •  28-09-2019
  •  | 
  •  

Vra

Die AxAcroPDF sluk al sleutel-verwante gebeure sodra dit fokus, insluitend kortpaaie, sleutel druk, ens Ek het ook 'n boodskap filter kry, en dit maak nie enige sleutel-verwante boodskappe óf kry. Dit is 'n COM komponent, kan dit relevant wees?

Is daar enige manier om hierdie te vang voor die beheer begin hulle sluk?

Was dit nuttig?

Oplossing

Hans korrek is, die Acrobat Reader toegevoeg twee kind AcroRd32 prosesse wat jy het geen direkte toegang tot binne jou beheer kode.

Ek het geëksperimenteer met hierdie en jy het drie lewensvatbare opsies:

  1. Jy kan 'n globale stelsel haak skep , en dan kyk vir en uit te filter / reageer op WM_SETFOCUS boodskappe gestuur om jou kind AcroRd32 vensters. Jy kan 'n paar van hierdie vanuit C # bereik deur die gebruik van 'n wrapper biblioteek, soos die een hier: http://www.codeproject.com/KB/system/WilsonSystemGlobalHooks.aspx

    Jy moet ook die korrekte prosesse te identifiseer as daar meer as een geval van jou aansoek, of ander gevalle van AcroRd32 kan wees. Dit is die mees deterministiese oplossing, maar omdat jou aansoek nou sal filter boodskappe gestuur om elke enkele venster in die bestaan, ek oor die algemeen nie hierdie benadering aanbeveel, want dan jou program kan 'n negatiewe invloed stabiliteit van die stelsel.

  2. Vind 'n alternatiewe PDF besigtiging beheer . Sien hierdie antwoord vir 'n paar kommersiële komponente: NET PDF Viewer beheer , of rol jou eie: http://www.codeproject.com/KB/applications/PDFViewerControl.aspx

  3. Vind 'n aanvaarbaar hack . Afhangende van hoe sterk jou aansoek moet wees, kode, soos die volgende geskik kan wees (dit was geskik vir my geval): 

    DateTime _lastRenav = DateTime.MinValue;

public Form1()
{
    InitializeComponent();

    listBox1.LostFocus += new EventHandler(listBox1_LostFocus);
}

private void listBox1_SelectedIndexChanged(object sender, EventArgs e)
{
    axAcroPDF1.src = "sample.pdf";  //this will cause adobe to take away the focus
    _lastRenav = DateTime.Now;
}

void listBox1_LostFocus(object sender, EventArgs e)
{
    //restores focus if it were the result of a listbox navigation
    if ((DateTime.Now - _lastRenav).TotalSeconds < 1)
        listBox1.Focus();
}

Ander wenke

Ek kan uiteindelik 'n belaglik eenvoudige antwoord. Tot dusver in die toets van hierdie werk.

Met gely het hierdie probleem vir 'n geruime tyd en 'n komplekse stelsel van elke persoonlike beheer opname wat van hulle verlede moes fokus en met behulp van 'n timer te flip fokus terug (toe acropdf gryp dit) Ek herbesoek hierdie probleem en lees 'n gebou het groot aantal antwoorde (op soek na onlangse oplossings). Die inligting verkry het my gehelp met die idee.

Die idee is om die (acropdf) beheer uit te skakel, terwyl dit laai as in die volgende voorbeeld (kode verminder vir duidelikheid)

AxAcroPDF_this.Enabled = Vals AxAcroPDF_this.src = m_src

Dan op 'n timer, nadat sê 1 sekonde.

AxAcroPDF_this.Enabled = Vals

In beginsel die idee is om te sê Windows nie te laat gebruikers gebruik die acropdf beheer totdat toegelaat, so vra Windows om te verhoed dat dit om fokus (omdat gebruikers nie toegelaat word in daar).

Tot dusver hierdie hou op, ek sal dit verander as daar iets verander. As dit nie heeltemal work for you dan miskien die idee punte in 'n bruikbare rigting.

Dit is 'n out-of-proses COM komponent, wat is die probleem. Heeltemal in stryd is met Windows SDK vereistes soos in SetParent uitgelê (). Sodra sy venster die fokus kry, die boodskap lus in die acroread.exe proses kry al die boodskappe, jou boodskap filter kan nie enige boodskappe meer te sien.

Tegnies is dit fixable deur gebruik te maak van SetWindowsHookEx () om 'n DLL in die proses en monitor boodskappe met WH_GETMESSAGE spuit. Maar jy kan nie so 'n DLL skryf in die C # taal.

Groot suig, ek weet. Dit blyk dat daar nooit enige gebrek daaraan met die program wees.

Vir antwoord een of ander rede Tim se direk aanskakel van die AxAcroPDF beheer, het nie gewerk nie in my geval. Die verlof gebeurtenis op die voorheen-gekies Textbox sou nooit vuur, óf.

Wat is besig is nes die AxAcroPDF beheer binnekant van 'n gestremde GroupBox. Sedert die gebruikers van my aansoek moet net sien die PDF, nie interaksie met dit, is die GroupBox se aangeskakel eiendom as Vals gestel in die ontwerper.

Gelisensieer onder: CC-BY-SA met toeskrywing
Nie verbonde aan StackOverflow
scroll top