TOPIC:

Lately I had discussion on this forum in which I wrote that I (too) often miss functionality in .Net. I can add another example. I have chosen for WPF, also because for a ling time Microsoft have the impression (in 2014) that WPF was actually a successor for Winforms (although that has never materialized).

In a program we have a button to open a directory. Unfortunately. .Net doesn't provide a decent directory browser. Only Winforms has one, but this is basically an ancient Win32 control with a lot of shortcomings (e.g. you can't also type a directory with autocomplete) and it's class is sealer so you can't subclass it and improve. But the alternative I used, a variation on the FileOpen dialog to open maps (with buttons saying Open folder etc) confused users as it did not (and needn't!) display the files in that folder.

So my up to date WPF application now users the ancient folder browser for those who need a browser:

System.Windows.Forms.FolderBrowserDialog dialog

and a Textbox for those who prefer to type a directory. And there's my statement again that Microsoft is usually doing half the job. TextBox has Autocomplete properties which can show autocompletion of files/directories in a combobox style....but only in Winforms!

Why not implement that in WPF I wonder.....

For those of you interested: I ended up with implementing 1 Winforms Textbox (with autocomplete) in my WPF XAML code, as follows:

1 At the top of the xaml (tag <Window> I added:
xmlns:wf="clr-namespace:System.Windows.Forms;assembly=System.Windows.Forms"

2 My WPF textbox called ImagesDir has been replaced by:

<WindowsFormsHost HorizontalAlignment="Left" Height="23" Margin="30,0,0,0" VerticalAlignment="Top" Width="300">
<wf:TextBox x:Name="ImagesDir" AutoCompleteMode="SuggestAppend" Height="24" Margin="30,0,0,0" Width="300" />
</WindowsFormsHost>

3 A reference to WindowsFormsIntegration had to be added

4 Somehow the property AutoCompleteSource in the XAML code caused an exception on InitializeComponent. But this works, at the start of the code behind:
ImagesDir.AutoCompleteSource = System.Windows.Forms.AutoCompleteSource.FileSystem;

And now it works. I consider it poor that I had to do that. But the alternative was adding tons of extra code found in several published projects, to simulate the built in Winforms functionality, absent in WPF, which was in most cases not working as well.

Dick

Hi Dick,
this is a functionality that is missing in WPF (and I agree with you that this is an important piece that's missing), but is present in Windows Forms.
And I agree with you that someone should build this. AFAIK there are some 3rd party developers that have than in their (expensive) control collections.
Wolfgang

Hi Dick,
you can use the Ookii.Dialogs.Wpf (github.com/augustoproiete/ookii-dialogs-wpf -> www.nuget.org/packages/Ookii.Dialogs/)
Hansjörg

Hello Hansjörg,

HansjoergP wrote: you can use the Ookii.Dialogs.Wpf (github.com/augustoproiete/ookii-dialogs-wpf -> www.nuget.org/packages/Ookii.Dialogs/)

Thanks for your reply. I actually did come across this library but I already implemented the folder browser there like they do, but without 3rd party code (you can see how it looks like in github.com/augustoproiete/ookii-dialogs-wpf) .

This solution however confused the user; when you present a file-open-like window to select a directory, users expect to see the files in that directory, once chosen, even if the button clearly says "Select folder".

It remains a mystery why Microsoft adds heaps of irrelevant and niche users features to .Net and doesn't provide decent controls for common actions used/needed by millions of end users. WPF hasn't been updated since .Net 4.5 (30-3-2017) so it looks like something Microsoft is giving up as well, which is their main specialty. On the other side: WPF is not dropped for .Net 5.0.

Dick

Dick,
The reason why so little was done to WPF is that a LOT of users has told Microsoft that they want to keep working with Windows.Forms. So in this case they actually listened to their users.

Robert

Hello Robert,

Sure, it's good that they didn't force a different technology as they normally do. But I keep wondering why an organization with their resources always delivers half work. WPF has certainly advantages but they should have delivered it with at least the same set of options as comparable WinfForms controls in the first place. If you and Chris would have been in charge and would only have 10% of the resources Microsoft has no doubt assigned on WPF, this would have been there.

It's always the same with Microsoft. E.g. in Windows 10 20H2 they disabled the access to the "Classic control panel". I understand it can still be accessed however, with some trouble, but the point is: even 5 years after W10 started the W10 settings screen is still incomplete. Otherwise I would have loved to ditch the setting screen with many too small and non resizable windows for the available options.

Dick

Dick,

Don't be so negative about Microsoft and don't overestimate our abilities. I find keeping up with customers and issues in our small community complicated enough.
Imagine having the # of customers that Microsoft has and having to roll out an OS update.
There are millions of different hardware options and combinations possible. I think it is a surprise that we have seen so few issues recently.
They really have invested in QA heavily over the last years.

And on my 20H2 version when I open the start menu and type "Control Panel" I can see the control panel like before.

Robert

Hello Robert,

robert wrote:
Don't be so negative about Microsoft and don't overestimate our abilities. I find keeping up with customers and issues in our small community complicated enough.

I think somehow something is wrong when you can't organize a reasonable comparable speed of issuing new features. I do realize that say 10 x the amount programmers doesn't mean 10x faster delivery, there's probably much more quality control (although an average MS release does not have significantly less issues than an x# release) but still, without overestimating your team, I am nearly always disappointed by Microsoft.

robert wrote: Imagine having the # of customers that Microsoft has and having to roll out an OS update.
There are millions of different hardware options and combinations possible. I think it is a surprise that we have seen so few issues recently.
They really have invested in QA heavily over the last years.

It's not only the quality. It's how much is missing. If they have a team who designs WPF, and someone implements the Textbox, why is it is do difficult to just make a list of what properties a Winforms Textbox has and port the code of these properties to the WPF Textbox so it can do at least the same as the Winforms one?

And about Q&A, support: In the meantime I spent 2,5 hours trying to complete my tax settings in my Microsoft Business Account, which I was asked to do. After successfully having entered everything (3 greens) pressing the Next button brought me back in the start position (3 x red "Required"). Tried to reach support. Either the support button was missing or, in the best case, I got a screen as attached.

Finally I found a working support screen!!! Actually for Visual Studio but I tried that as it was the only working support page. And, a miracle, a very helpful guy from Portugal called back. He saw what happened and concluded that an earlier forced account migration, done by Microsoft, was only half finished (as everything done by Microsoft) and that this was causing the problem.

I now have to start with another support (he sent me a link) team and I am sure it will take another 2,5 hours for something that should take 3 minutes.

So forgive me that (despite the time and effort of the guy who called me) I am not convinced that their investment in support actually helped....

robert wrote: And on my 20H2 version when I open the start menu and type "Control Panel" I can see the control panel like before.

Ah, that's good to know. I read it was blocked completely but they have edited the article:

www.windowslatest.com/2020/11/01/windows...control-panel-pages/

Dick

I'll add my 2 cents here.

The out of the box WPF controls are nice for small applications, but if you want to create a larger, more complex application, you'll probably have to spend some money on a third party library. Let's take the WPF Controls from DevExpress as an example (because I have some experience with them). They cost ~900$ per developers, but you get an amazing datagrid, a crazy powerful chart control, a good report designer... This three components alone are essential for business applications and will save you a lot of time in development and let you can create beautiful and feature rich UIs for your users. Just check out one of the demos like the "Outlook-Inspired Application" to see, what these controls can do.

I personally like DevExpress, but there are check similar offerings from Telerik, SyncFusion, ...

Volkmar

Hello Volkmar,

I can imagine that these external libraries can be useful if you need a report generator, a chart control and maybe their datagrid is better than the standard WPF datagrid. I have a license for Syncfusion and after checking out some of their controls I found it all disappointing and (for now) stopped using it. I was looking for a good HTML editor with a spell checker (which is is in none of these 3rd party libraries). I tried their very reasonably working RTF editor which has a html import- and export, only to found out that it basically failed when the formatting was a bit more complex.

They do not have directory browser (Devart has one but that looks like a lot my own alternative which I rejected in the end), they do have some autocompletion on textboxes but not for a file path. They have ribbon but that doesn't seem to add anything to the default WPF ribbon. This surely left something to be desired but it's standard in WPF (and not in Winforms I believe). Lots of Syncfusion controls do not add much functionality but focus on the looks, a line around a textbox with a color to choose, etc.

Personally I also happen to like the default WPF more than the "modern UI" / Outlook style design Syncfusion or Devart provide.

So despite I started this to explain what I did to deal with IMO really missing WPF functionality in the Textbox I end with saying that the WPF ribbon is not so bad.

Here's a preview of how I used it in my next PhotOrganize program.

Dick

Hi Dick
Yet again you started an interesting exchange of views in this thread. So, I’ll add mine.

Comparing WPF and WinForms Text Boxes overlooks some very important points: The basic underlying point is that you are not comparing like with like.

.Net is a highly modularised “system of logic”. This allows for independent development of any control etc. safe in the knowledge that whatever way is chosen there needs to be no interaction (or read-across) from one way of doing things to the another, even though they may appear to be doing the same thing.

This “separation of concerns” is fundamental to the operation of .Net. From a developer’s point of view this implies a necessity to preserve such independence in any application code.
There are two ways of painting controls on screen. One is painting each pixel on an x/y canvas using x and y co-ordinates. The other is to use a vector-based approach, using some range and angle from a fixed origin.

And of course, one way can easily be converted to the other using appropriate projections.

The basic language of .Net is CIL. Upstream of this is C#* or a derivative, and downstream is a major subset of machine language determined by the processor – meaning that processing is effected fast and efficiently.
Despite this conversion represents a processing overhead which manifests itself in time taken to re-paint the screen. It is an undesirable and unnecessary overhead which can be prevented by using a Vector-based approach in the first place.

This principle can be traced through to a number of programming constructs outside the conceptual bounds of controls.

* C# is not the only upstream language for CIL. I have just read that the DoD has a version of ADA which targets CIL. This implies, to me at least, that concerns about performance and/or security can be overstated.

Terry

Hello Terry,

Yet again you started an interesting exchange of views in this thread. So, I’ll add mine.

You 've obviously done some study!
I can add something which surfaced after I replaced (only) the Textbox in my WPF screen with a WindowsFormsHost / Textbox .

When I start the program it always nearly immediately shows that Textbox (only) followed by the rest of the WPF control (you can see these in the picture) nearly 3 seconds later. Although the vector based technology sounds an advantage (and there are more) the WPF Design mode editor is often difficult to use and it looks like there is a speed penalty on using WPF while basically, if I understand you right, you (and I) would expect the contrary.

Given the direction WPF and Winforms are going I may have to re-evaluate my choice for WPF.

Dick

Hi Dick

Have attached a short pdf which may partially shed some light on what you are seeing.

Hope it makes some logical sense.

Terry

Hello Terry,

Thanks for your thoughts.

Personally I believe it can be explained a bit more "down to earth": there is a total lack of coordination between Microsoft programmers. Plus a an absence of insight what their customers actually are waiting for. A product like Windows 10 has seen (too) many features which were poorly worked out so hardly anybody is using it, and a certain moment Microsoft stops working on it.

There are dozens of examples, I'll give you one. The Virtual Desktop sounded nice. I would have expected I could define a subset of my desktop with only a few icons on it, which e.g. someone taking over my computer for support (Microsoft itself for example) would see. But no, you can't define anything. You just get the same desktop only you don't see any of the open programs of that moment.

Microsoft published investigations confirming what I write as early as over 10 years ago. Here's an example:

www.microsoft.com/en-us/research/wp-cont...ion-techreport08.pdf

Dick

Hi Dick

I interpret this a bit differently. The report you reference flags up the difficulties of getting teams of developers to co-ordinate things.

Yes it's always been a major problem.

But I see .Net as a positive step to offload this "lack of a co-ordinated manual approach" on to a computerised "enforced accurate approach to co-ordination".

Terry