Unfortunately, the column definitions of the DataGrid don’t inherit the DataContext, because they’re not part of the visual tree, so you can’t bind directly to the ViewModel. You need to resort to a workaround such as the one described in this article: <DataGrid.Resources> <local:BindingProxy x:Key=”proxy” Data=”{Binding}” /> </DataGrid.Resources> … <DataGridTextColumn Header=”{Binding Data.MyTitle, Source={StaticResource proxy}}”/>
The declaration of your control and the instantiation are basically manipulating the same object, all the properties that are set in the declaration are also set on every instance. So if the properties were “visible” so to speak: <UserControl x:Class=”MyControlLib.ParentControl” xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation” xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml” xmlns:mc=”http://schemas.openxmlformats.org/markup-compatibility/2006″ xmlns:ctrl=”clr-namespace:MyControlLib”> <ctrl:ChildControl x:Name=”ChildName” DataContext=”{Binding RelativeSource={RelativeSource Self}}” PropertyOnChild=”{Binding PropertyInParentContext}”/> </UserControl> This is why … Read more
First, make sure you are disposing your DataContext when you’re done! He can be a heavy little bastard (edit not heavy to instantiate, but heavy to keep around if you keep using it without disposing); you don’t want old DataContexts hanging around in memory. Second, the DataContext is intended to represent a single logical transaction. … Read more
Maybe something like this can get you started in the right direction. I made a mock database with similar columns based on your column names and got some results. class Program { static AccountContextDataContext aContext = new AccountContextDataContext(@”Data Source=;Initial Catalog=;Integrated Security=True”); static LoanContextDataContext lContext = new LoanContextDataContext(@”Data Source=;Initial Catalog=;Integrated Security=True”); static void Main() { var … Read more
In a UserControl like this you should never exlicitly set the DataContext to this or anyting else, because the DataContext is usually set externally when you use the UserControl somewhere in your application. The externally applied DataContext is typically (part of) the application’s view model. You should instead change your internal bindings so that they … Read more
Unlike most types which implement IDisposable, DataContext doesn’t really need disposing – at least not in most cases. I asked Matt Warren about this design decision, and here was his response: There are a few reasons we implemented IDisposable: If application logic needs to hold onto an entity beyond when the DataContext is expected to … Read more
For first one, try : <UserControl DataContext=”{Binding RelativeSource={RelativeSource Self}}”> And for second question, I think using ElementName or AncestorBinding is best way to bind to UserControl‘s properties.
In addition to connecting with a read-only user, there are a few other things you can do to your DbContext. public class MyReadOnlyContext : DbContext { // Use ReadOnlyConnectionString from App/Web.config public MyContext() : base(“Name=ReadOnlyConnectionString”) { } // Don’t expose Add(), Remove(), etc. public DbQuery<Customer> Customers { get { // Don’t track changes to query … Read more
More that one thread operating on a single Entity Framework context is not thread safe. A separate instance of context for each thread is thread-safe. As long as each thread of execution has its own instance of EF context you will be fine. In your example, you may call that code from any number of … Read more
The ContextMenu is outside of the visual tree. Below is the xaml that should get you the datacontext: <ItemsControl ItemsSource=”{Binding Markers}” Tag=”{Binding ElementName=outerControl, Path=DataContext}”> … <ContextMenu DataContext=”{Binding Path=PlacementTarget.Tag, RelativeSource={RelativeSource Self}}”> <MenuItem Header=”Edit” Command=”{Binding EditCommand}” /> </ContextMenu> … </ItemsControl> This post explains how this works.