2010-07-18 16 views
5

Se metto un controllo WebBrowser su qualsiasi pagina, la pagina non risponde più agli eventi di manipolazione sotto il browser web. Altre aree della pagina funzionano bene.Windows Phone 7 Controllo WebBrowser ingoia gli eventi di manipolazione?

È facilmente confermato ignorando OnManipulationCompleted in una pagina, quindi posizionando un controllo WebBrowser sulla pagina. Prova a passare il cursore sul WebBrowser e non viene mai chiamato OnManipulationCompleted.

Non riesco a impostare il WebBrowser su IsHitTestVisible=false perché è necessario poter fare clic sui collegamenti. Ma voglio che la pagina risponda agli swipe sinistro/destro.

Qualcuno ha idee brillanti? O sapere se questo è un bug nella versione corrente?

+0

Gulp, ha confermato. Ho lasciato cadere e compilato una listbox dietro un browser web. Nessuna gioia ricevere gli eventi di scorrimento nella casella di riepilogo con qualsiasi mezzo ovvio. –

risposta

2

Questa è una conseguenza del modo in cui abbiamo implementato WebBrowser. Gli eventi touch vengono inviati direttamente al motore del browser. Una volta fatto ciò, Silverlight è praticamente fuori dal campo visivo. Purtroppo non riesco a pensare a soluzioni alternative che potrebbero darti quello che vuoi. -Skeets, MS dev

+0

Ho creato una tela trasparente sulla parte superiore del browser. Questo impedisce comunque agli eventi di raggiungere il browser. – Esa

1

Se davvero vuoi:

<Grid> 
    <phone:WebBrowser Source="http://www.microsoft.com" /> 
    <Rectangle Fill="Transparent" ManipulationCompleted="HandleManipulationCompleted"/> 
</Grid> 

Ma naturalmente non si blocca completamente in basso interazione con controllo del browser web e non c'è proprio nessun modo per riprendere gli eventi di manipolazione al browser ...

4

Vorrei estendere ciò che Skeet ha già scritto.

Il punto è che il team di sviluppo di MS WP7 ha pubblicato "linee guida", in cui scoraggiano fortemente l'inserimento (sulla stessa pagina) di più controlli di layout che accettano e reagiscono allo stesso insieme di gesti. Ad esempio, non dovresti provare ad incorporare un pivot all'interno di un Pano, perché lo swipe orizzontale si scontrerà e sarà difficile distinguere quali di essi dovrebbero eseguire le sue azioni. Lo stesso caso è con il browser: risponde a tutti gli swip e le padelle .. quindi non dovrebbe essere inserito in quasi tutti i controlli a scorrimento !!

Ora, detto questo, voglio dirvi che è possibile superarlo - anche se potrebbe non essere facile, a seconda del caso.

La cosa più banale da fare, se si desidera ricevere ancora una notifica sui gesti è utilizzare GestureService/GestureListener dalla libreria di Silverlight Toolkit. Anche quando il WebBrowser estingue gli eventi di manipolazione non elaborati, GestureListener sarà ancora in grado di notificarti - poiché apparentemente ascolta su un "altro livello", non voglio proprio entrarci subito. Basta prendere la biblioteca, aggiuntivo riferimento a esso, fare qualcosa di simile:

GestureService.GetListener(targetcontrol).Flick(myBrowserFlickHandler); 

ed è fatta - si ottiene la notifica ogni volta che qualcuno colpi di frusta sul controllo, con tutto senza alcun riguardo degli eventi di manipolazione in fase di e.Handled = true o no. Piccolo disclaimer qui: non ricordo se su 7.0 funziona, perché il WebBrowser è un po 'diverso. Su 7.1 e 7.5 dovrebbe funzionare.

Tuttavia, se lo si applica su un WebBrowser, si otterrà la notifica, ma anche il browser lo otterrà. Ciò significa che i 2 controlli reagiranno e che verrà respinto visivamente se inizierai alcuni storyboard dall'interno del gestore.

Su 7.1 e quasi 7.5, è possibile giocare duro con il WebBrowser e per controllare completamente quale evento di manipolazione vedrà.Quindi, filtrando gli eventi mani per il WB e usando GestureListener per vedere gli eventi da soli, puoi sia bloccare il WB dal fare qualsiasi cosa, sia, allo stesso tempo, puoi rispondere con la tua stessa azione. Ne ho già parlato ampiamente in risposta a problemi simili, vedi WP7 Pivot control and a WebBrowser control per i dettagli. Non è una cosa facile/facile/divertente da fare però.

EDIT: e MOST importante, non è garantito il funzionamento in futuro. Attraverso le versioni 7.1 e 7.5 dell'SDK/OS/API, all'interno del controllo WebBrowser sono visibili alcune importanti modifiche interne in fase di esecuzione, e non sarei sorpreso se cambi drammaticamente nelle prossime versioni. Non giocare con le cose che ho scritto lì se non vuoi tornare a rivedere l'argomento nei prossimi 1-2 anni.

-3

Penso che tu abbia un modo migliore catturare gli eventi di manipolazione, se si trova in WP7.5 Mango in quanto i controlli del browser sono completamente diversi, che ho letto da questo link

+0

-1 @Prakash Questa è una copia diretta di un post sul blog che ho scritto qui: http://www.scottlogic.co.uk/blog/colin/2011/11/suppressing-zoom-and-scroll-interactions- in-the-windows-phone-7-browser-control/ – ColinE

+0

@ColinE Sì, ho scritto lì che l'ho preso dal link. Non dovrebbe essere fatto in questo modo. – Prakash

+0

@ColinE Se non sei soddisfatto, ti fornirò un link al tuo blog e non alcun contenuto. – Prakash