[RESOLVED] WPF vs Winform

[schoemr]

I am starting to learn wpf (moving away from winforms) because supposedly it is better than winforms (though I haven't really seen why) I know there will be growing pains.... I would like to ask this questions:

1) In winform I could drag and drop a table from the dataset and automatically the designer created a binding navigator. It has buttons with icons to add, delete, move first, last, etc. So in wpf there is no such BindingNavigator? If not what will be a good approach to create one? Surely there must already be an add-on or download or something like this?

2) In winfrom after drag and drop I could see at the bottom of the form a "component tray" with the dataset, tableadapter, bindingsource, table adapter manager, etc. Is there no such component tray in wpf?

3) This one is really irritating me about wpf. In Winform I could from the dataset change the dropdown next to the table to "DataGridView" then I drag and drop a datagridview or change to "Details" then drag and drop Labels and textboxes. I could then move these labels and textboxes whichever way I want on the form and align each one just the way I want. I could for example place one bound textbox in the top left corner of the form and the next bound textbox I could place it in the bottom right corner (the point I am making is that I could position those bound textboxes whichever way I want) with wpf, no matter what I do, If I drag and drop "details" it is inside a "grid" on the form. Even if I just drag and drop "a single" textbox from the table then it is inside a "grid" on the form. Why is that?? Is there no way to drag and drop as with a winform project? To me this is really a big minus for wpf.

4) Why exactly is wpf better than winform? So far it looks like wpf is just a cumbersome way to do things that winform can easily do.

[szlamany]

It's all about the XAML - and putting actions into those files, imo. Otherwise, it's cumbersome and painful to work with. I only did one app in WPF, and that along with a lot of other .Net pains, drove me to now only creating web apps (RIA's) with jQuery and AJAX...

        <Style x:Key="ButtonStyle">
            <Setter Property="Control.Template">
                <Setter.Value>
                    <ControlTemplate TargetType="Button">
                        <Border Name="shortcutbutton"  
                    BorderThickness="0 0 0 0"
                    BorderBrush="#D0D1D7"
                    Background="#FFFFFF">
                            <ContentPresenter Margin="2" 
                                  HorizontalAlignment="Center"
                                  VerticalAlignment="Center" 
                                  RecognizesAccessKey="True"/>
                        </Border>
                        <ControlTemplate.Triggers>
                            <Trigger Property="IsMouseOver" Value="true">
                                <Setter TargetName="shortcutbutton" Property="Background" Value="#FFFFFF" />
                                <Setter TargetName="shortcutbutton" Property="BorderBrush" Value="#D0D1D7" />
                                <Setter TargetName="shortcutbutton" Property="Opacity" Value="1" />
                                <Setter TargetName="shortcutbutton" Property="BorderThickness" Value="1 1 0 0" />
                                <Setter TargetName="shortcutbutton" Property="Cursor" Value="Hand" />
                                <!--<Setter TargetName="Border" Property="Foreground" Value="#45619D\#2F477A" />-->
                            </Trigger>
                            <Trigger Property="IsPressed" Value="true">
                                <Setter TargetName="shortcutbutton" Property="Background" Value="#FFFFFF" />
                                <Setter TargetName="shortcutbutton" Property="BorderBrush" Value="#D0D1D7" />
                                <Setter TargetName="shortcutbutton" Property="BorderThickness" Value="1 1 0 0" />
                                <Setter TargetName="shortcutbutton" Property="Cursor" Value="Hand" />
                                <!--<Setter TargetName="Border" Property="Foreground" Value="Red" />-->
                            </Trigger>
                            <Trigger Property="IsEnabled" Value="false">
                                <Setter TargetName="shortcutbutton" Property="Background" Value="#F4F4F4" />
                                <Setter TargetName="shortcutbutton" Property="BorderBrush" Value="#D0D1D7" />
                                <Setter TargetName="shortcutbutton" Property="BorderThickness" Value="0 0 0 0" />
                                <Setter TargetName="shortcutbutton" Property="Cursor" Value="Wait" />
                            </Trigger>
                        </ControlTemplate.Triggers>
                    </ControlTemplate>
                </Setter.Value>
            </Setter>
            <Setter Property="Control.Margin" Value="2"></Setter>
            <Setter Property="Control.Foreground" Value="#2F477A"></Setter>
            <Setter Property="Control.BorderBrush" Value="{x:Null}"></Setter>
            <EventSetter Event="Button.Click" Handler="Button_Click" />
        </Style>

[dday9]

From what I hear, WPF is being deprecated in favor of WinUI which is currently WinUI3. But it too uses XAML (why Microsoft, why???)

If you're moving from WinForms for the sake of keeping up-to-date then I'd suggest using it.

[Shaggy Hiker]

It's certainly more cumbersome than WinForms if all you are trying to do is create WinForms in XAML. If all you want is covered by WinForms, then stick with WinForms, as it will be easier. What WPF allows is that you can create darn near any visual effect (which is also rendered by the GPU, so it can be faster if the rendering is extensive).

For example, in WinForms, a Listbox allows you to show a list of strings and not much else. Usually, that's what we use Listboxes for, so that limitation is not all that important. In WPF, that Listbox can be a list of pretty much anything. You can bind it to a list of objects that show graphics, text, animations, and any combination of those. You can probably bind it to a list of datatables...though why you'd want to do that is hard to say.

If you want a circular button in WinForms, you can do it, though it isn't so easy. In WPF, you can wrap a button around a shape, then wrap text around that button. If you are artistically inclined, you have very few limits in WPF, and it will help you do weird things like that. WinForms likes rectangles. Getting away from rectangles can be done, but not without a bit of difficulty.

I don't go for oddly shaped buttons, but my buttons in WPF often contain text, images, and other things. You can greatly control how the text is located relative to the image, it's appearance, whether text is above and below the image, vertical or horizontal, and so forth. Is this a good thing? Well, it would be better in the hands of somebody more artistic, certainly. In my case, my goal was a program centered around an interactive map showing custom pushpins that consist of variable images and text. That isn't really possible in WinForms directly. To do that in WinForms, I had to host the map in a WPF form within the WinForms application, which is a bit painful, so I just went full WPF.


One of the ramifications of that excessive control of what things look like is that some of the more complicated pieces in WinForms don't belong. You mentioned the binding navigator. That's really a bunch of controls stuffed into one. I haven't used those, but the idea wouldn't fit well in WPF. To remain in keeping with WPF, each of those sub-controls that makes up the binding navigator would have to be capable of having its own styling, triggers, appearances, and even sub-sub-controls. In WinForms, it's quick, easy, and not very flexible. It does one task, has essentially one appearance, and you have to live with that. Since nothing in WPF has one appearance, they probably decided not to bother with it. MS was probably thinking that if people wanted something with that functionality, they'd write it to suit them. I rarely use JUST a button in WPF, as my buttons include two other controls. MS was probably thinking people would do that for a navigator, as well.

[Niya]

From what I hear, WPF is being deprecated in favor of WinUI which is currently WinUI3. But it too uses XAML (why Microsoft, why???)

If you're moving from WinForms for the sake of keeping up-to-date then I'd suggest using it.

WPF is still perfectly viable and based on what I've read, is still the most robust of all XAML-based technologies by Microsoft. I've read about WinUI not having features that WPF has and whatnot. To be honest, I'm not sold on WinUI. I'd stick to WPF but that's just me.

Also, if I had to recommend a path forward from WPF, I think Avalonia is a safe bet. I hear nothing but good things about it and if these things are true, I'd consider it the best successor to WPF. I haven't tried it yet but I want to soon to see if the hype is real.

[Niya]

4) Why exactly is wpf better than winform? So far it looks like wpf is just a cumbersome way to do things that winform can easily do.

I'm not going to lie, moving to WPF from WinForms is not easy. It took me like 3 tries before I was able to grasp WPF and become comfortable with it. I'm not expert in it but I feel at home with it and generally prefer it to WinForms.

Shaggy pretty much covers the benefits of WPF over WinForms. What I want to add is that if you're going to explore WPF, you need to enter it as a blank slate. Forget everything you know about WinForms and treat it was something different because that is what it is. If you go into WPF expecting it to be like WinForms, it's going to massively disappoint you.

Also, you mentioned data-binding so I'll add this too: WPF's data-binding capabilities far exceeds that of WinForms. You can bind things in a way you could only dream of in WinForms. Just don't expect it to look anything like it did in WinForms with BindingNavigators etc. Trust me, if you get comfortable with WPF's data-binding, you will never want to see a BindingNavigator again

[Shaggy Hiker]

I was under the impression that there were three, very similar, yet different, versions of XAML: Xamarin, WPF, and WinUI. I haven't dabbled in Xamarin for a fairly long time, and probably won't for complex reasons, but it wasn't as useful as WPF XAML, though that might be because the first version of MS Xamarin was so horribly buggy and thinly documented that some behaviors were nothing but a guess.

[Shaggy Hiker]

Trust me, if you get comfortable with WPF's data-binding, you will never want to see a BindingNavigator again

I'd say that even without WPF data-binding.

I just remembered one of the other 'compound' controls that WinForms had which doesn't exist in WPF: The NumericUpDown control. Those spinner boxes could be mighty annoying in WinForms. For one thing, I didn't always want them. They didn't always make sense for things I was doing (if the NUD had a range of thousands or tens of thousands, those little buttons were a waste of time). I assume that the NUD was left out of WPF for the same reason that the binding navigator was.

On the other hand, I often DO have a use for a NUD, and I've found that DevEx has included one such in their excellent suite of WPF controls, so I use that when I need a NUD.

[Niya]

I was under the impression that there were three, very similar, yet different, versions of XAML: Xamarin, WPF, and WinUI. I haven't dabbled in Xamarin for a fairly long time, and probably won't for complex reasons, but it wasn't as useful as WPF XAML, though that might be because the first version of MS Xamarin was so horribly buggy and thinly documented that some behaviors were nothing but a guess.

Yea, they are all similar. There is quite a bit of overlap between the different flavors of XAML. WPF is only one I have any kind of respectable experience with though. I did dabble around in Xamarin one time and truth be told, it felt like a lesser clone of WPF. But I'm no Xamarin expert. Perhaps I didn't spend enough time with it. Regardless, I still think WPF is the most mature of all these technologies. The next XAML-based thing I want to try out is Avalonia as it's the only one that seems like it was made specifically for WPF programmers.

I just remembered one of the other 'compound' controls that WinForms had which doesn't exist in WPF: The NumericUpDown control. Those spinner boxes could be mighty annoying in WinForms. For one thing, I didn't always want them. They didn't always make sense for things I was doing (if the NUD had a range of thousands or tens of thousands, those little buttons were a waste of time). I assume that the NUD was left out of WPF for the same reason that the binding navigator was.

Yea that control doesn't make that much sense. Besides, it's probably not that hard to quickly create a NUD in WPF by combining Buttons with a TextBox on a UserControl surface.

[pourkascheff]

Long story short about Q#4, WPF provided a few laws you have to obey which we were used to do them in our projects as hobbies. For instance always using table layout panels are recommended by MS to achieve a sort of responsive and user-friendly UI. WPF already have it. Everything in XAML are being created and modified inside of <Grid> and </Grid>.

You can copy all the designing form after a daywork as a text to have a sort of backup and snippet to even create your next project visually faster and smarter than before.

There are bunch of qualified teachers on YouTube, I started with them. I still lack in so many things but what I've learned is you have to be expert in WinForms to survive WPF. Lots of controls you are familiar with are no longer available in toolbox. You should code everything. I mean EVERYTHING. Background workers, dialogs, performance counters, SerialPort, etc. Your efforts would be twice the normal but it worth it. Even few new controls would confuse you. i.e. FlowLayout is upgraded and turned into WrapPanel and StackPanel, 2 totally different controls in functionality. "Properties" are massively changed and expanded with cool features which you were dreamed to have in WinForms. UserControls are still there but also there are "Page" and "Window" you have to be friend with now on...

The winner of this discussion is WPF for sure but she is like a confident, independent girl who not all men can handle her.
WPF Forum here on VBForums is not as much active as WinForms unfortunately. But soon or late we have to changeover to this.

First thing you notice in your first WPF demo app is the fact that it is extremely fast to build, run and perform things.

As a personal perception to entering WPF world, only take this advice: Never drag and drop controls on MainWindow. Code them all.
Let it be a part of future's history cause WPF searches are increased in search engines these days...
Peace </Pourkascheff>

[Niya]

Never drag and drop controls on MainWindow. Code them all.

Yes! This cannot be overstated. The very first time I dipped my toes into WPF I made this mistake. Do not ever use drag and drop to build a UI in WPF. Always code it!

[Shaggy Hiker]

There's an exception to that rule, but it's in such an obscure area that it might not be worth mentioning...but what the heck.

The one time that I drag and drop controls is when I am adding a new control from a third party like DevEx. That will require a new namespace, and getting that onto the form is just easier by dragging and dropping a control, in which case the namespace gets added automatically. Once it's there, then everything else is done in XAML. The designer is there to see what you are doing.

[Niya]

Sounds like you're just using a trick/short-cut to get something done faster. To be more specific I'm advocating against actually building the UI using drag and drop.

[Shaggy Hiker]

Yeah, I am.

[wes4dbt]

All this WPF talk got me curious so I checked out a tutorial. I really liked this tutorial so I thought I'd share the link.

btw - It explains why you shouldn't drag and drop controls.

https://www.youtube.com/watch?v=gSfMNjWNoX0

I know it say C# but this video is all about XAML.

[pourkascheff]

used to do them as hobbies.

What I meant by this specific part is tangible in updatable softwares. Someday you will add "cut" next to your "copy" and "paste", you will add "left to right" in view section, all in buttons instead of menus. You can easily "add" a new row or column to a table layout panel, rearranging them all equally spaced agaian and vala, you are compatible with WHATEVER your employer asks. You need to displace an entire row to other? No problem. Change rowspan. (Still talking in WinForms)

I think the term "Foundation" in WPF abbreviation is representing this fact that "UI Consciousness" if it had a name, states everithing is engineerly assigned in hidden row/column cell.

Of course split containers are also no longer available in WPF but you can still mimic their behavior to collapse, show or hide a very crowded in-order, justified controls with exact previous operation.

[David Anton]

From what I hear, WPF is being deprecated in favor of WinUI which is currently WinUI3. But it too uses XAML (why Microsoft, why???)

If you're moving from WinForms for the sake of keeping up-to-date then I'd suggest using it.

The main problem with WinUI3 is that Microsoft is seriously dragging their feet at getting this ready. Is there even a working designer available yet? (Not last I checked).

[dday9]

Not really. I checked 3 months ago and there is still a workaround needed just to update the window title.

[schoemr]

Thank you everyone for the replies