I have made a textbox in XAML, which goes like this:
<TextBox x:Name="search"
TextWrapping="Wrap"
VerticalAlignment="Top"
Margin="-12,-13,45,0"
Background="#FFB2B2B8"
BorderBrush="Transparent"
Foreground="White"
inputScope="Search"
SelectionForeground="#FF72BCE6" />
and whenever I tap on the textbox to write something, its background changes. How can I set the background so that it is always on the same color?
Make use of the focus event handler.
Edit: Explaining further,
attach an onfocus event handler to the textbox
in the method, set the background colour of the textbox to the colour you desire.
Expanded even further, in case you want to find out more on what i mean, check this out
http://www.limguohong.com/2012/09/windows-phone-7-textbox-on-focus-color/
You may try creating a new template and making the background color stay constant when focused.
Related
I have a combobox that is editable and a textbox.
<TextBox x:Name="textBox" HorizontalAlignment="Left" Height="23" Margin="86,149,0,0" TextWrapping="Wrap" Text="TextBox" VerticalAlignment="Top" Width="120"/>
<ComboBox x:Name="comboBox" HorizontalAlignment="Left" VerticalAlignment="Top" Width="120" Margin="282,150,0,0" IsEditable="True" PreviewMouseDown="ComboBox_PreviewMouseDown"/>
I don't understand why ComboBox_PreviewMouseDown does not trigger, when the focus is on the textbox and I click on the combobox. It just highlights the text in the combobox and sets the focus. Clicking in the combobox when it already has the focus, PreviewMouseDown fires.
Is that what's happening here? Why is a PreviewMouseDown in an unfocused combobox not working?
When ComboBox.IsEditable is set to True, the ComboBox internally sets the focus (and keyboard focus) to the edit TextBox to make it instantly available for text input. This makes total sense as the intention when clicking the edit TextBox is always to enter or edit some text. Otherwise, the user would have to click the TextBox twice to make it receive focus for text input (keyboard focus).
So, to prevent focus stealing, the author marked the MouseDown event as handled i.e. RoutedEventArgs.Handled is set to true. (This is the reason why most non-preview events are marked handled by most controls).
Also, the author wanted to prevent the moving of the caret when clicked into the edit TextBox for the first time (to give it focus): the PreviewMouseDown event's RoutedEventArgs.Handled will only be set to true, if the edit TextBox has no keyboard focus and the drop-down panel is closed. (That's why the second click into the TextBox will pass through to be handled by an added event handler).
To achieve the behavior you expect, you have to handle the UIElement.PreviewGotKeyboardFocus event or the attached Keyboard.PreviewGotKeyboardFocusevent on the ComboBox.
Alternatively register the event handler using the UIElement.AddHandler method and set the handledEventsToo parameter to true:
this.MyComboBox.AddHandler(
UIElement.PreviewMouseDownEvent,
new RoutedEventHandler(MyComboBox_PreviewMouseDown),
true);
I ran into this same issue myself. A simple and effective workaround is to wrap your ComboBox in a lightweight ContentPresenter, then attach your PreviewMouseDown handler to that, like so:
<ContentPresenter x:Name="MyComboBoxWrapper"
PreviewMouseDown="MyComboBoxWrapper_PreviewMouseDown">
<ContentPresenter.Content>
<ComboBox x:Name="MyComboBox" />
</ContentPresenter.Content>
</ContentPresenter>
Additionally, since this control gets the PreviewMouseDown event before the ComboBox does, you not only can use it to pre-process events before the ComboBox even sees them, but you can cut off the ComboBox entirely by setting the event arg's handled property to 'true.'
Works like a charm! No subclassing or other tricks needed and it only requires a lightweight control in the tree!
Notes
As some may have considered, technically you could attach the PreviewMouseDown event to any ancestor of your ComboBox, but you then may have to include logic in that handler to determine if you're actually clicking on the ComboBox vs something else.
By using an explicit ContentPresenter (an incredibly lightweight element that itself doesn't have any rendering logic. It simply hosts other elements), you now have a dedicated PreviewMouseDown handler just for this control. Plus, it makes it more portable should you need to move it around since the two items can travel together.
I'm having a weird UI issue in my app, where a ScrollViewer jumps to the top as soon as a TextBox child loses focus. I've already tried to set BringIntoViewOnFocusChange="False" in the parent ScrollViewer, but that doesn't solve the issue unfortunately.
Here's a quick video that shows the problem I have:
As you can see, every time the top TextBox is focused, the ScrollViewer jumps back to the top as soon as it loses focus (ie. whenever I tap on an item in the ListViews below. This also happen if I click on one of those ComboBox controls: the ScrollViewer still jumps back immediately.
This is the general structure of the contents of the Popup your're seeing:
<UserControl>
<RelativePanel HorizontalAlignment="Stretch">
<!--Item name-->
<TextBlock Text="Name"/>
<customControls:TextBoxActionButton/>
<customControls:TextValidatorControl/>
<!--Section selector-->
<TextBlock Text="Section"/>
<customControls:ComboBoxWithResetButton/>
<!--Item GroupName-->
<TextBlock Text="Group"/>
<customControls:ComboBoxWithResetButton/>
<!--Template based on-->
<TextBlock Text="Based on"/>
<customControls:ComboBoxWithResetButton/>
<!--Icons list and description-->
<TextBlock Text="Icon"/>
<ListView ScrollViewer.VerticalScrollMode="Disabled"/>
<!--Select color text-->
<TextBlock Text="Select color"/>
<ListView ScrollViewer.VerticalScrollMode="Disabled"/>
</RelativePanel>
</UserControl>
I don't have any code that interacts with the parent ScrollViewer, which is in a completely different UserControl, along with the rest of the Popup UI (header, buttons at the bottom etc..).
I've also tried to subscribe to the LosingFocus event of the first TextBox, and to set e.Handled = true; from there, but that didn't work too.
Do you have any idea on why this is happening? And also, why doesn't the BringIntoViewOnFocusChange="False" property work in this situation?
Thanks!
I think the problem is the TextValidatorControl which causes the TextBox to regain focus, because this does not seem to happen when the control is not there.
Please verify what happens if you actually enter a valid name. If the behavior stops, I would suggest you to invetigate or post the source code of TextValidatorControl, because it looks like the source of the problems.
I have a TextBox.
I want it to be in the Disabled state, so that I can drag it. Once I double click it I want it back to be Enabled.
I can use ReadOnly property for this purpose. But If I use ReadOnly, then I am unable to Drag the TextBox, instead I get selection.
My actual reason for doing this is I want to use TextBox as TreeViewItem and I would like to allow features like Rename and Rearrange using drag-drop.
If anybody can suggest something like custom control that I can create and override some method?
I suggest to wrap the TextBox inside Grid. And set IsHitTestVisible to false for textBox. This will avoid all mouse events for TextBox. Now hook all your drag events to grid and it will work.
<Grid Background="Transparent" VerticalAlignment="Center">
<TextBox IsHitTestVisible="False" Margin="5" Text="Some text"/>
</Grid>
I'm creating this test Metro application using Windows 8, VS2012, C# and XAML. There are different TextBox in the application page arranged in a StackPanel. When the application is launched the focus is on the first TextBox.
I was wondering how to "deactivate" this.
Here's a pic, as you can see the first field is focused (color changed and ToolTip displayed).
When your UI is loaded you can remove focus from the TextBox by applying a Programmatic focus state to any other control.
Imagine that you have a Button named myButton. You can:
myButton.Focus(FocusState.Programmatic);
You cannot however use FocusState.Unfocused state to remove focus from the TextBlock because it is not allowed and will throw an exception.
One simple fix for this is place something to catch it first with IsTabStop="True" with a 0 Opacity which is a bit hacky but the only way I know. So something like;
<TextBox IsTabStop="True" Opacity="0" Height="1" Width="1"/>
<!-- Then the rest of your content like your other TextBox stuff -->
Currently porting an application to Windows Phone 7 I've encountered a problem that should be trivial
All I want is change the background colour of a TextBlock.
Using the WYSIWYG I can easily create a TextBlock, change the foreground and background colour.
So for a TextBlock using white text on black background I would use:
<TextBox Height="148" HorizontalAlignment="Left" Margin="106,0,0,0" Name="textBox1" Text="TextBox" VerticalAlignment="Top" Width="460" Background="Black" BorderBrush="Black" Foreground="White" />
But I need to do it in code (C#) and the Background doesn't appear to be a property of TextBlock.
How come it's something you can do using the resource editor, but not in code?
I've found various similar questions, but no definitive answer.
In Microsoft documentation (.Net), TextBlock does appear to have a Background property
Is there a way to do this in code without having to put the TextBlock inside a container (like Grid) which does have the Background property?
Thanks
JY
TextBlock is not inherited from Control, it doesn't have a Background property. The code you are showing is a TextBox not a TextBlock. TextBox inherites from Control and has a Background property. The simplest way is to wrap it with a Panel, or you can create a custom control for it.
Also, in silverilght sdk, you have a control called Label and it is inherited from Control. You can probably get the source code from there and implement it in your project.