Codurile sursă se găsesc la sfârșitul articolului.
La momentul acestei scrieri, cea mai recentă versiune de GeckoFx pentru C # este 22. Nu au existat actualizări pentru o lungă perioadă de timp și poate proiectul a murit, dar chiar versiunea 22 este mai bună decât IE. Deci, să începem 🙂
Să scriem o aplicație care va merge la pagina principală Google. introduceți o solicitare și mergeți la un site aleatoriu în emitere.
Creați un nou proiect (aplicația Windows Forms), denumiți-o "GeckoExample", redenumiți formularul principal la "FrmMain", dimensiunea principală a formularului = 514; 399.
Pentru muncă avem nevoie de:
Acum, în proiectul creat adăugăm linkuri către Geckofx-Core.dll și Geckofx-Winforms.dll.
În proprietățile proiectului, comutați platforma finală la x86.
În utilizarea clasei principale de formule, conectăm:
Acesta este un exemplu, așa că așteaptă de la el un fel de flexibilitate (pentru a copia imediat și a lucra așa cum ar trebui) nu merită să fie 😉
În detrimentul dimensiunii, atunci cred că nu este greu să punem un punct după acest.webBrowser și să vedem ce are acest obiect și câmpuri.
Printre acestea există câmpuri precum Înălțime (înălțime) și Lățime (lățime), cu care puteți regla dimensiunea controlerului. De asemenea, trebuie să setați proprietatea Anchor în AnchorStyles.Left | AnchorStyles.Top. deoarece în exemplul cu ajutorul unor ancore (AnchorStyles.Left | AnchorStyles.Right | AnchorStyles.Top | AnchorStyles.Bottom) Controllers „atarna“ la toate marginile formei.
Exact. Mulțumesc!
Documentația, așa cum o înțeleg, nu este în ea, chiar și în limba engleză?
Nu există nicio documentație. Odată am găsit exemple (pentru versiunea 16, ca) în limba engleză.
Deci, metoda de legare științifică taxi 🙂
Văd că te descurci foarte bine cu Geckofx. Spune-mi dacă știi. Prin proprietatea geckoWebBrowser1.Document obținem acces la document, care a fost deja analizat de către motor. Dar există momente când sursa originală a paginii web de pe server nu corespunde cu OuterHtml. Deși motorul afișează corect pagina, proprietatea geckoWebBrowser1.Document a pierdut deja date și nu poate fi accesată. dacă faceți geckoWebBrowser1.Navigate ("view-source:" + url); codul fără pierderi, dar în primul rând apare pe pagina care nu este întotdeauna necesară, iar în al doilea rând se solicită de la server din nou, iar în altele doar arată bine, și acces la documentul html cum? OuterHtml nu va mai fi original, va fi adăugat marcaj pentru ieșirea codului. Sper că înțelegi ce vreau să știu. Vă mulțumim anticipat.
Nu știu cum să obțin codul original pe care îl oferă serverul, folosind GeckoFx. pentru că care este punctul de a trage de-a lungul unui astfel de dviglo dacă trebuie doar să obțineți codul (fără redare, etc.) pe care le oferă serverul? În acest scop, există WebClient 🙂
Vă mulțumim pentru răspuns. Draggingul unui dviglo are sens în anumite situații. Scopul utilizării sale într-o anumită problemă nu a fost obținerea codului sursă, motorul fiind utilizat în scopul propus. Pur și simplu paralel și a apărut o astfel de problemă, pentru a procesa programatic datele de pe pagină. Din păcate, datorită documentației slabe, nu am găsit răspunsul. Sunt de acord că, odată ce motorul este încă folosit, este greșit să cârjeze cârjele și accesul prin WebClient, când această pagină particulară a fost deja recepționată și motorul a fost afișat. Bine, hai să arătăm, poate că nu este pierdut totul.
Pentru a construi cârje în programare este aproape întotdeauna necesară. nu toate au funcționalitatea / munca necesare așa cum ar trebui.
Ei bine, fie port (dopilivat) acest motor în sine, cu preferință și poeteze. Dar acest lucru va dura mult mai mult timp decât construirea unei cârje.
De asemenea, puteți încerca să adresați întrebarea celor care au pornit dviglo-ul aici.
PS În vizualizarea sursă a contului. Puteți să trișezi și să obțineți acces la codul de genul:
_webBrowser.Navigați ("vedere-sursă: someurl");
șir html = _webBrowser.Document.GetElementsByTagName ("html") [0] .TextContent;
În teorie, ar trebui să funcționeze 🙂
Se întâmplă doar să nu deschideți fereastra, ci să trimiteți și o solicitare post-cerere, prin urmare, raportează o eroare.
Aici aveți nevoie să stați și să săturați (și google :)), nu am timp pentru asta acum, sunt ocupat cu un alt proiect.
Am o întrebare atât de ciudată. Nu înțeleg cum funcționează sincronizarea dvs.? De unde știți că pagina este descărcată complet și poate continua să funcționeze?
Cu componenta obișnuită de webBrowser, am verificat pe ReadyState, dacă este finalizată, apoi mergeți mai departe.
Dar cum să nu-mi dau seama, spune-mi, nu?)
Tocmai nu am găsit dependența timer-ului și a cizmei. el doar modifică variabila și spune că pagina a fost încărcată în 2 secunde? și dacă nu avea timp să se încarce în acel moment?
sau mi-a fost dor de ceva?
În acest exemplu, cronometrul decide dacă pagina este încărcată sau nu 🙂 Acesta este un exemplu, lenea a fost ceva "mega-cool" pentru un exemplu simplu de făcut.
Și dacă nu avea timp să se încarce, atunci lucrarea continuă cu pagina neîncărcată.
Da, înțeleg. Mulțumesc.
și pot să-mi spună ce alte componente ale terților, în care se rezolvă mai simplu, cu ajutorul metodelor și proprietăților?
problema unui browser web standard este că, din anumite motive, nu supraîncărcă conținutul documentului, deloc. (așa cum este descărcat după prima navigare, deci toate)
Am înțeles în Gecko cu toate astea, e necesar doar să se sincronizeze cu sincronizarea?
Eu descriu mai jos, că nici unul dintre componenta (cu care l-am întâlnit 🙂) nu poate fi o singură metodă / eveniment pentru a determina sarcina completă paginii (chiar și în Delphi 7 și mai sus, cu acest gunoi peste și au încercat mai mult de o grămadă de componente). Chiar și un browser obișnuit (Chrome, Fox) nu poate face acest lucru 🙂
O cârpă încărcată cu un simplu simplu: utilizați un cronometru și verificați proprietatea IsBusy. Timerul "pornește", de exemplu, 10 secunde, când timerul modifică valoarea variabilei _loading la false.
Și în metoda de deschidere a link-ului, unde este așteptată încărcarea paginii, facem o singură bucla:
în timp ce (_wb.IsBusy # 038; _loading)
// așteptați
>
_loadingTimer.Stop ();
// lucram cu pagina
În orice caz, utilizați temporizatorul, deoarece poate unele script-ul unui contor inutile nafig, care este încărcată sincron, „poveshat“, pagina (care va fi întotdeauna încărcate, sau un timp foarte lung) și, ca urmare programul va aștepta ca Hachiko 🙂
Bună ziua, iată un exemplu de lucru:
var eveniment = document.createEvent ('MouseEvents');
event.initMouseEvent ('clic', adevărat, adevărat, fereastră, 1, 10, 10, 10, 10, fals, fals, fals, 0, null);
document.getElementById ('idid'). expatchEvent (eveniment);
>
Cred că încerc să coas cu gesko. Am încercat să trimit SendMessage totul sa dovedit, deși când am opri aplicația, nu face clic pe toate site-urile. Motivul nu este cunoscut încă, dar realizat prin transparența zero a formei, astfel încât totul funcționează bine, clicuri fără un mouse real. Este adevărat că ascunderea formularului nu este foarte corectă. Vreau să-mi dau seama ce se întâmplă. Dacă există timp, conectați-vă la o soluție la această problemă.
Trimiteți-le prietenilor: