I've never used it but it looks like it is referring not to the Text property of the TextBox, but to the source that is data bound to the Text property.
From looking at the code it appears it has to do with an edge case where the TextBox is pushing a change back to the binding source but may not notice if the binding source has modified that string.
// when Text is data-bound, _newTextValue is converted from a// deferred reference to a string. The binding writes the string// back to the source, then computes a new value for Text (which// may be different, either because the source normalizes the value// or because of conversion and formatting). Usually this raises// a change notification for Text, which brings the Text property and// the text container into [....]. But this doesn't happen in one// case: when the normalized value is the same as the original// value for Text. The property engine thinks that Text hasn't// changed, and doesn't raise the notification. It's true that// Text hasn't changed, but we still need to update the text container,// which now displays the wrong value.// We detect that case by checking whether _newTextValue (the// text container value) agrees with Text.
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed."
- G.K. Chesterton
I have tried a lot of things without luck. What I'm trying to do is create a XAML TabControl that keeps all of the first five visible TabItems on the first row when the last two hidden TabItems become visible. What I want is for the two last TabItems to wrap when they become visible but keep the first five on the first row. I have tried to use a TextBlock with a LineBreak but when the last two TabItems become visible the fifth TabItem wraps with the new visible last two TabItems. Any help would be great.
The answer to my problem had to do with setting the widths of the collapsed tabs once they were changed to visible. What I did was give the newly visible tabs the correct width and they pushed the other tabs to the first row.
The reason why it's not working is the MonthViewDayColumnHeader class doesn't support INotifyPropertyChanged. It's being initialized, then updated with Monday after. If you take the existing and default it to 'Sunday' you should be able to see the default value.
On that note, I know it's an example but you should probably start off with MVVM in your learning process. Have the underlying layers implement the INotifyPropertyChanged and set the context to an appropriate view model.
private static object CoerceDayNameCaption(DependencyObject d, object value)
MonthViewDayColumnHeader control = (MonthViewDayColumnHeader)d;
var dayNameCaption = control.DayNameCaption;value
return dayNameCaption ; //<=== NOW IT WORKS
I have been trying for several days to come up with a solution for the my application page. My page contains an upper section with a menu, page header, and two columns for a human head silhouette image and empty white section. That section works fine. What I have been trying to add to my page are two DataGrids side by side so it will create a single table of a total of four columns. Now on each DataGrid the first column is a Description and the second column is the Value it displayed for the Description. What I am trying to do is have a table on the page that appears to make up a single table with 17 rows of Description/values. I don't want either DataGrid to have a scroll bar and each not to be able to scroll. In some of the DataGrid cell a want a background color of blue. Now on the page this table is in a DockPanel with a height of 368 units. What I want is the DockPanel to have a scroll bar so both DataGrids can be scrolled up and down as a single table. First, I have found the it is almost impossible to change the background of a DataGrid Column's Cell. Next my DockPanel scroll bar does not appear and each of the DataGrids are still able to scroll. Below is both the XAML and the code behind. I am only showing 8 rows for testing. If anyone can help that would be great.
Change your datasource to a single collection and use a datagrid.
Create a model to meet your view requirements either in the VM or code behind. It should probably have 4 properties for display and 2 object properties to have the underlying data object if you need to do any additional processing when the user interacts with the selected value.
Bind the single collection to a datagrid and forget your scrollviewer.
See if the datagrid supports a CellStyleSelector (I use Telerik tools and they have this concept). I'm pretty sure there are some implementations for the standard tooling out there.
Never underestimate the power of human stupidity
Using a single object with all four properties is definitely the way to go and solves all of my problems except changing the background color of some of the DataGrid cells to blue. I read several articles yesterday and tried to implement the code for turning different DataGrid cells to blue but was unable to get any of the procedures working. This DataGrid is not like the Telerik and has no cell style to do the job. If anyone has something that they have implemented working please let me know.
With WPF and MVVM, properties of the ViewModel are bound to UI elements. When a property changes, its set accessor calls OnPropertyChanged which in turn raises the PropertyChanged event of the INotifyProptyChanged interface.
But it is possible to call OnPropertyChanged (with the property name as argument) from anywhere in the ViewModel (and then you can't use the CallerMemberName attribute).
Now I'd like to ask you: how do you handle such cases? Do you call OnPropertyChanged from other places than the property_set? Or do you change your code such that you call the property_set? Or other ideas?
You can call it from anywhere; it's purpose is to notify the "UI" that there is new info in the data source and the "display" needs updating.
The point is, you may have an updated data source but that does NOT imply that the UI has to also be updated at that point ... maybe the update should be deferred (for now).
For example, I have a real-time app that displays many "numbers" that are calculated; some fields on the display are based on other numbers being displayed. There is no point doing "UI updates" for each calculation ... I do all my calcs, then I call OnPropertyChanged at the end of my calc routine.
Last Visit: 4-Aug-20 22:49 Last Update: 4-Aug-20 22:49