5
votes

I need to set focus on the textbox. The problem is when a WebBrowser control is present on the page, the SIP is displayed as if textbox is selected, but cursor is not visible in textbox and the input does not go to the textbox.

If I comment the WebBrowser control out, then the behavior is as expected - cursor is blinking in the TextBox when page is loaded.

Here is the XAML:

<phone:PhoneApplicationPage 
x:Class="WP7Sample.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d" d:DesignWidth="480" d:DesignHeight="768"
Loaded="MainPageLoaded">

<StackPanel x:Name="LayoutRoot">
    <TextBox x:Name="txt"/>
    <phone:WebBrowser/>
</StackPanel>

</phone:PhoneApplicationPage>

And the codebehind:

void MainPageLoaded(object sender, RoutedEventArgs e)
{
    txt.Focus();
}

I have tried the different workarounds, but no luck. Namely I have tried to call SetFocus from the Load, NavigatedTo etc events. I have also tried to set focus to some other control and then back to the textbox, no luck either.

Could someone provide a workaround for this problem?

BTW, the problem is reproduced on the emulator, on HTC Mozart and Trophy devices all with NoDo update installed.

5
No answer I'm afraid - to me it looks like the native web browser control isn't playing nicely with the Silverlight framework. Interestingly, the FocusManager thinks that the textbox has focus. Even if you delay setting the focus by a couple of seconds using a DispatcherTimer, it still doesn't work... I'd file a bug report with Microsoft. - Damian
Yes, looks like that, WebBrowser is stealing the focus. I was able to find the similar post at apphub foru: forums.create.msdn.com/forums/p/70736/460811.aspx#460811. No answer too. - kza
If I choose to add WebBrowser control later manually, then until it is added, the texbox has focus. As soon as WebBrowser is added, the TextBox looses focus and is not able to receive it back until the user clicks any control on the screen. The same applies if I add TextBox manually - it cannot have focus until user clicks it. - kza
I had the same problem as this, although bizarrely the WebBrowser control was on a different page to the TextBox I was trying to set focus on. Ended up having to add/remove the WebBrowser control from the visual tree when navigating to/from the containing page. - dwynne

5 Answers

2
votes

step 1 : Bind loaded event with respective textbox where u want to set focus

<StackPanel x:Name="ContentPanel" Margin="2,0,2,0">
  <TextBox x:Name="SearchTextBox" Height="90" VerticalAlignment="Top" 
           Loaded="SearchTextBox_Loaded"
           KeyDown="SearchTextBox_KeyDown"/>
</StackPanel>

step- 2: Now set Focus in when this event occurs

private void SearchTextBox_Loaded(object sender, RoutedEventArgs e)  
{  
    (sender as TextBox).Focus();  
}
1
votes

Try using the txt.Focus() call twice. I found this looking for a solution on how to set focus on a ListBox. I ended up trying to call the Control.Focus() function twice to set the focus (firing 3 GotFocus events) and it seemed to work.

0
votes

This is a dirty workaround, but you could do this. On startup have the WebBrowser component absent from the page. Then, have the TextBox control wired to a LostFocus event. Something like this:

txt.LostFocus += new RoutedEventHandler(txt_LostFocus);

When it loses focus, you can safely add a WebBrowser control to the page:

void txt_LostFocus(object sender, RoutedEventArgs e)
{
    LayoutRoot.Children.Add(new WebBrowser());
}

This won't let you re-focus programmaticlly later, as the WebBrowser will be inhibiting it, but it is a way to do it at startup.

0
votes

Try handling something in the GotFocus event. Maybe txt.SelectionStart = txt.Text.Length; It works for me.

0
votes

As we have provided a hack for the case for pre-Mango versions of WP7, I had not checked the scenario beforehand. The good news, guys!

In WP7 Mango the problem does not exist!