Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
Why second Text coloumn value is missing?
FindAncestor is used to lookup for an item's ancestor item/s in the visual tree, it doesn't work for items at the same level (since technically there isn't any ancestry relationship between them, unlike the TextBlock and the Window in your sample code) and that's what the ElementName binding is for.
From MSDN:
{RelativeSource FindAncestor} is mainly used in control templates or predictable self-contained UI compositions, for cases where a control is always expected to be in a visual tree of a certain ancestor type. For example, items of an items control might use FindAncestor usages to bind to properties of their items control parent ancestor. Or, elements that are part of control composition in a template can use FindAncestor bindings to the parent elements in that same composition structure.
There is no ComboBox in TextBlock parent, only StackPanel, Grid and Windows are avaialble. Try use ElementName as your Third one.
<TextBlock Background="Yellow" Text="{Binding ElementName=cmbEmployee, Path=Height}" />
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
How can I achieve the overlay/docking effect of the find and replace control on the top right hand corner of the text editor using WPF?
Thanks
Place both the TextBox and the find and replace control inside the same Grid control and align the find and replace control to place it in the top right corner. Also make sure that you put the control in the XAML after the TextBox so that it will be rendered on top of it:
<Grid>
<TextBox AcceptsReturn="True" />
<local:FindControl HorizontalAlignment="Right"
VerticalAlignment="Top"
Width="230" Height="20" />
</Grid>
In my example FindControl is a custom control containg the find and replace functionality.
I'm binding a list of object to an ItemsControl which contain a TextBox control.
I want to be able to change the textbox background color based on the background color property of the bind object.
It works perfectly with the INotifyPropertyChanged interface but when I need to update let say 1000 objects it takes a huge amount of time I guess because it needs to update the controls one by one.
Does someone has a tip for me to lets say, update all my objects background color and than update the binding in one shot instead of object by object?
Thanks,
Mat
If you use virtualization, it'll only need to update the items that are visible - normally items controls will only track property changes on the items that are currently visible. However, if you're using the base ItemsControl, virtualization will be off by default. To turn it on, you need to provide a custom template that includes a ScrollViewer with CanContentScroll set to True, and you also need to use a VirtualizingStackPanel, either in the control template, or via the ItemsPanel - this shows the former approach:
<ItemsControl ItemsSource="...whatever...">
<ItemsControl.Template>
<ControlTemplate TargetType="ItemsControl">
<ScrollViewer CanContentScroll="True">
<VirtualizingStackPanel IsItemsHost="True" />
</ScrollViewer>
</ControlTemplate>
</ItemsControl.Template>
</ItemsControl>
Virtualization improves performance with large numbers of list items in various ways. It should help your scenario, but it may also improve other aspects of the performance. It's not without its problems, but I'd definitely try it here first before attempting other solutions.
I finally found why it was taking me so long to update my UI. Byt the way, What I'm trying to achieve is a kind of spreadsheet grid. My cell container was a border with the borders visible. I was updating the Border control Background color based on cell selection. Disabling the borders of the Border control resolved my issue right away. The UI update time went from 4-5 seconds to instantaneous.
Thank you guys for your answer, I will still try to implement your suggestion to improve even more my project.
Thanks
Mat
I currently have a view that contains a ListBox bound to a a collection of view models and a user control that I would like to bind to the current item that the mouse is over. How can I get the current highlighted item in the list and bind it to the user control using only XAML and code in the View Model?
Edit: The following image might be more descriptive of the intended action.
alt text http://img134.imageshack.us/img134/6263/34548010.png
As eduardo said, sometimes to make a solution in pure MVVM is too complicated.
if you reformulate your question and provide some code, you can get more answers.
Is there a way to edit a silverlight 3 DataGrid by row and not by cell?
I would like a way to turn off the cell editing functionality and set the whole row in edit state (that should also display the CellEditingTemplate templates).
You can make use of RowDetailsTemplate for this.
You can have your customized UI for row editing in this RowDetailsTemplate.
Answering my own question i can say that this functionality is not supported for silverlight 3.
Not sure if this is implemented for later versions though.
This question already has answers here:
Difference between Label and TextBlock
(5 answers)
Closed 8 years ago.
Visually both of the following snippets produce the same UI. So why are there 2 controls..
Snippet1
<TextBlock>Name:</TextBlock>
<TextBox Name="nameTextBox" />
Snippet2
<Label>Name:</Label>
<TextBox Name="nameTextBox" />
(Well I am gonna answer this myself... thought this is a useful tidbit I learnt today from Programming WPF)
The WPF Textblock inherits from FrameworkElement instead of deriving from System.Windows.Control like the Label Control. This means that the Textblock is much more lightweight. The downside of using a textblock is no support for Access/Accerelator Keys and there is no link to other controls as target.
When you want to display text by itself use the TextBlock. The benefit is a light, performant way to display text.
When you want to associate text with another control like a TextBox use the Label control. The benefits are access keys and references to target control.
Label has an important focus handling responsibility.Its purpose is to allow you to place a caption with an access key. It has a Target property, which indicates the target of the access key. Like this...
<Label Target="{Binding ElementName=nameTextBox}">_Name:</Label>
<TextBox x:Name="nameTextBox" />
In the absence of the Target property, the Label control does nothing useful. You'll just hear a beep if you press the access key indicating 'unable to process request'
The two biggest reasons for the confusion regarding TextBlocks and Labels are Windows Forms and common sense.
When you wanted to slap a small bit of text on your form in Windows Forms, you used a Label, so it follows (incorrectly) that you would do the same thing with a WPF Label.
Common sense would lead you to believe that a Label is lightweight and a TextBlock isn't, when the opposite is true.
Note that you can put a TextBlock inside a Label.
With TextBlock we can easily have multi-line support I guess - using TextWrapping.
Using Label in such cases, e.g. displaying validation message, need to use <AccessKey> tags, which is less straight-forward than TextBlock.
On the other hand, using TextBlock not allow us to set the BorderBrush property.
So, to me, the two controls should be combined into a text-full-feature control.
Label takes all kinds of data inputs like String, Number etc...
TextBlock, as the name suggests, only accepts a Text string.
Label can be used as an alternative to TextBlock for situations where minimal text support is required such as the label for a control. Using Label can be advantageous because it requires even less resources (lighter weight) then a TextBlock.