4

I have been tasked to design a contact management program for my company. We have VS 2012 and since I have never used WPF before I thought I would use it to develop this application.

I am having huge problem getting started on the binding when utilizing the entity framework for the database which btw is database first.

I have followed the instructions within this link to the letter. http://msdn.microsoft.com/en-us/data/jj574514.aspx

The objects show up in the data sources window just fine. But when I drag and drop to my window, nothing happens. No idea what I am doing wrong and cannot find anyone else with this problem.

Can anyone help me out here? I have looked everywhere. Any help is appreciated

Paul
  • 53
  • 2
  • 7
  • 4
    Don't use the Visual studio designer in WPF. type your XAML by hand as we all do. – Federico Berasategui Sep 18 '13 at 18:19
  • There is no code. I just followed the example to add the database objects to the project as per the link http://msdn.microsoft.com/en-us/data/jj574514.aspx. When I get to part where I drag and drop one of the objects onto the form nothing is dropped onto the form. The database objects are in the data source window and when I drag and drop onto the designer it doesn't drop. Nothing happens. The only code I have is for the navigation buttons. – Paul Sep 19 '13 at 14:58
  • all righty will type by hand as we all do. Thought the drag and drop feature would speed things up...sure looked good – Paul Sep 19 '13 at 15:00
  • Ok I am admittedly new to WPF, but this is ridiculous. Does anyone actually use this stuff to develop or do you utilize telerik WPF controls with your WPF apps for ease of development? Designing all of the grids alone seems very cumbersome at best and @HichCore up there seems to think that drag and drop is the easy way out. Well duh! Why not? I have been looking around and found Telerik. I used kendo with MVC 3 and 4 and developed quickly. What is the consensus out there for utilizing after market tools using WPF? – Paul Sep 19 '13 at 19:13

4 Answers4

6

Ok. I actually went thru that article, just to show good faith and let you know that I actually want to help you.

I came to the following conclusions:

  • That article show a very basic scenario of getting data from an Entity Framework context and showing it in a WPF DataGrid.
  • It doesn't have any kind of validation nor business rules.
  • It doesn't have any UI behavior such as conditionally enabling/disabling or showing/hiding any UI elements.
  • That kind of scenario is where the Designer is useful, when you don't actually need anything except getting / saving data from / to a DB.
  • Unfortunately (or fortunately for all of us developers who make a living of it), most applications will require some level of validation and business rules and some level of UI logic.
  • The designer is really useless when it comes to developing complex logic.

You can use the designer for such situations where you don't require complex logic, however I must warn you the following cons:

  • The Visual Studio WPF designer produces fixed-size, fixed-position UIs. these type of UIs don't work well when executed in computers with different screen resolutions and DPI settings. Just like winforms.
  • It also produces XAML that has many unnecessary things (such as x:Name="categoryIdColumn" and things like Margin="13,13,43,191" which are really bad from a maintainabilty / scalability point of view)
  • From what I've seen, the designer-generated XAML also contains a CollectionViewSource, this is both a good thing and a bad thing. It's a good thing because it enables Design-Time Data in the DataGrid, but it is also bad because it bloats your XAML with lots of unneeded things and introduces unnecessary <Window.Resources> that complicate things up.

Now, this is the very minimal XAML needed for that DataGrid, without Design-time data support:

<Window x:Class="MiscSamples.DesignTimeDataGrid"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="DesignTimeDataGrid">
    <DataGrid ItemsSource="{Binding}" AutoGenerateColumns="False">
        <DataGridTextColumn Header="Category Id" Binding="{Binding CategoryId}"/>
        <DataGridTextColumn Header="Name" Binding="{Binding Name}"/>
    </DataGrid>
</Window>

You see? It's actually faster to type that (much more so with the help of Intellisense) than what it takes for you to browse the property window and set these properties manually.

My suggestion is that you get familiar with XAML instead of insisting in the hard way to do things


Another very important aspect to keep in mind is that generally speaking, you don't put anything in code-behind in WPF because it's not needed, therefore that tutorial is actually going against the WPF Way of doing things, but that's Ok because it's actually an Entity Framework tutorial, not a WPF tutorial.


ease of development

You really need to reconsider what you call "ease of development". When it comes to UI development, I call "ease of development" to actually being able to do what I want with the UI without having to resort to shitty procedural code practices involving P/Invoke (whatever that means) and "owner draw" type of things for evertyhing.

WPF provides REAL ease of development as opposed to the fake ease of development exhibited by winforms

  • winforms lets you do everything with a designer (and this is just because the code the designer generates is actually so shitty that nobody would have ever used winforms if they didn't have the designer) but then when it comes to adding complex DataBinding or UI logic you're stuck with winforms' incapabilities forever.

  • WPF encourages manual XAML writing, not only because XAML is declarative (as opposed to the procedural winforms approach), but also because the levels of customizability and reusability are so high that a designer-centric approach does not make sense.


drag and drop is the easy way out

No it's not. It's actually the hard way. The easy way is to learn XAML and be able to do Things you can't even imagine to do with winforms.


If a designer-centric approach still makes sense to you, you may want to try Expression Blend

Community
  • 1
  • 1
Federico Berasategui
  • 43,562
  • 11
  • 100
  • 154
  • Thanks and learning XAML is exactly what I have been doing. Thank you for all of your feedback. Next time I will have an actual decent question REGARDING XMAL. I have been developing trainers for dod companies and Web site using MVC3 and entity framework with Kendo UI. Last time I did desktop app was in 06 and WPF was not used...so when it comes to desktop dev I guess I am a dinosaur – Paul Sep 24 '13 at 15:23
  • Typing manually in xaml is actually not practical if you have 20+ columns... – alvseek Jun 07 '22 at 15:52
  • @alvseek I'd argue that 20+ columns is terrible UX.. no one is going to read any of that. – Federico Berasategui Jun 08 '22 at 04:48
  • @FedericoBerasategui just saying. it is created for a purpose. a terrible UX is not a dealbreaker for some people. – alvseek Jun 08 '22 at 10:24
4

Automatically Create Data Grids from Your Models

Using a data source to drag and drop a template onto a WPF control is an excellent and fast way to get up and running!

(Can, and would the original author "JWP" please provide a link to the book or web page where this technique is (hopefully) inspired from? A source that provides a little more tutoring and background would provide a more gentle learning curve.)

Start by doing this: In your project create a folder named Models, then use either Entity Framework Database-First (DB) first or code by hand the models you want to show.

OR see discussion below on Object binding...

In that same folder create a dummy class that is a property for IEnumerable like this..

public IEnumerable<MyClassModel> MyCollection { get; set; }

From there go to the Main Visual Studio menu, to View/Other Windows/Data Source and click that link.

Data Source Wizard

Click on Object and find the MyCollection property just created above.

Now open a user control or window in WPF but keep the datasources toolbox opened.

It should default to a DataGrid, but you can right click on the datasource and change it to detail, datagrid or select individual properties of the class it represents.

Simply drag that datasource onto the XAML's grid area. The right click on the new stuff you see and click reset to set the content to be the size of the entire window.

After having done this you will have code injected into the code behind of the view as follows in the window loaded event of that window, usercontrol etc.

        // Do not load your data at design time.
         if (!System.ComponentModel.DesignerProperties.GetIsInDesignMode(this))
         {
            //Load your data here and assign the result to the CollectionViewSource.
            System.Windows.Data.CollectionViewSource myCollectionViewSource = (System.Windows.Data.CollectionViewSource)this.Resources["Resource Key for CollectionViewSource"];
            myCollectionViewSource.Source = your data
        // }

Go back to the XAML and look for the CollectionViewSource KEY property that was also inserted when you dragged the property to the XAML. It looks like this:

Collection View Source KEY

Use the Key name in the code behind, and then "Bind" the CVS to your data source which is an enumerable of type MyClassModel it can live in the View Model or in the code behind of the view as you choose.

If you only use the CollectionViewSource to as the datacontext of the grid you do not need to implement (the PropertyChanged event and OnPropertyChanged method of) the INotifyPropertyChanged interface (INPC) for any underlying collections! The CVS updates the view automatically everytime the source is updated! Once you get good at this you can create working View prototypes of data in 2 minutes! Forget hand-coding XAML that just takes too long.

Object Binding

Create a static class with a static method that returns something like this:

enter image description here

When using the datasource wizard choose the "Object" selection.

Click Ok and you should see something like this:

enter image description here

You have just mapped all of the properties into the data source definition.

JWP
  • 6,672
  • 3
  • 50
  • 74
1

For anyone finding this issue in VS 2022: as per this is written, VS 2022 has this known bug unable to drag and drop data source to XAML form.

More info: https://developercommunity.visualstudio.com/t/drag-a-a-table-from-datasource-and-drop-in-a-windo/1660788

UPDATE: It says that the fix has been released on 15th June. You can try updating your VS 2022 to the latest.

alvseek
  • 381
  • 3
  • 11
0

Since the dummy class only has a property for IEnumerable like:

public IEnumerable<MyClassModel> MyCollection { get; set; }

Then isn't it NOT a big leap to be able to define a more sophisticated backing collection that derives deeper down from IEnumerable<MyClassModel>?

Although the following links are about the Windows FORMS designer, according to Brian Noyes in his Pluralsight WPF Productivity course,

https://www.pluralsight.com/courses/wpf-productivity-playbook

WPF's designer is based on Windows Forms' designer. The information in these links, and the links further within them, show the way to set up Data Sources, as well the containers/UI layout controls, and icons that represent them (which are displayed to the side of the Data Sources) :

https://devblogs.microsoft.com/dotnet/state-of-the-windows-forms-designer-for-net-applications/

https://devblogs.microsoft.com/dotnet/databinding-with-the-oop-windows-forms-designer/