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
WPF versus Winforms: how to get a decent directory selection option
WPF versus Winforms: how to get a decent directory selection option
Hello Terry,
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
You 've obviously done some study!Yet again you started an interesting exchange of views in this thread. So, I’ll add mine.
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
WPF versus Winforms: how to get a decent directory selection option
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
Have attached a short pdf which may partially shed some light on what you are seeing.
Hope it makes some logical sense.
Terry
- Attachments
-
- Separation of Concerns.pdf
- (159.61 KiB) Downloaded 84 times
WPF versus Winforms: how to get a decent directory selection option
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:
https://www.microsoft.com/en-us/researc ... port08.pdf
Dick
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:
https://www.microsoft.com/en-us/researc ... port08.pdf
Dick
WPF versus Winforms: how to get a decent directory selection option
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
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