I read that WPF uses DirectX under the hood to perform its rendering, that it doesn't rely on the dinosaurian libraries that WinForms uses to render controls.
So I made my Presentation layer with WPF and it looks the way it should under Win8.
Then I deployed the project to Windows Server 2003... to find out that my nice little custom message box looks awfully WinForms-like and somewhat clunky; the button controls are VERY similar to the WinForms ones, the expander control is no longer shown as a circled ^ arrow and looks like it was drawn in 1998 (picture the ^ arrow on an ugly square flat button that pops up when your mouse hovers over it).
From the Pro WPF in C# 2010 Bible:
Part of the promise of WPF is that you don't need to worry about the details and idiosyncrasies of specific hardware. WPF is intelligent enough to use hardware optimizations where possible, but it has a software fallback for everything. So if you run a WPF application on a computer with a legacy video card, the interface will still appear the way you designed it.
So, is this a lie? To me it is, because it doesn't appear the way I designed it.
If not, then why/how doesn't the thing render identically regardless of the machine that's running it? Is the software fallback somehow designed to mimick Win32/GDI rendering? Is there a way to get my little custom message box to look identical on Win8 and WinServer2K3?
That has NOTHING to do with DirectX / Rendering / video card / any of that.
and EVERYTHING to do with WPF taking the DEFAULT appearance of ALL UI Elements from the Windows Theme.
If you don't want this behavior, you'll have to provide Styles and Templates for ALL UI element types, or otherwise find a way to include PresentationFramework.Aero.dll in your application and use that as the default theme library.
Take a look at this answer
Related
We were able to use automation tool and it was able to identify html objects on Winforms while on WPF it does not since it is rendered as an image.
My main question is what does Winform CEFSharp uses to render and why WPF not able to use a similar rendering mechanism?
Warning: it is a very generic answer. I briefly looked at CEF source (briefly - 3-5 minutes) and the rest are my guesses based on my own WPF/WinForms interop experiences. I've had quite a few. I also played a bit with early Chromium builds. However, all of that was a few years ago, so it may simply be out dated. Maybe Chromium has now first-class WPF support. I have not found any information about that, but if this really happened, I encourage you even stronger to follow the last paragraph.
--
I doubt that there is any reason behind this other than time-cost to implement -
either on CEF or Chromium project.
WinForms and WPF are totally different GUI frameworks, written in different eras, using different architectures, different rendering techniques, different platform features, etc. This is as different as it can be, down to the idea of a "Window" itself.
In WinForms, almost every control is a separate small window-like thing, has a system-wide handle, has a system-tracked region, etc. All controls render themselves almost directly by unmanaged win32 GDI+ functions.
In WPF they don't. In WPF there's only one handle per whole window, controls don't render themselves. Instead they have a definition of their "look" and the WPF renders them to the 'surface', which is then blitted/streamed (sorry, dont remember) to target device.
That's true that CEF uses different approaches. For WinForms they make heavy use of a 'browser component' taken directly from Chromium, for WPF they render to bitmap and show/update the bitmap periodically.
Why? My guess is that it's because Chromium already provided a COM/OCX/ActiveX/whatever component, and WinForms can use it almost directly, thanks to the everything-has-a-handle "feature" - if you can call it a feature - one of the goals and successes of WPF was to eliminate that.
However, I don't think that Chromium at that point of time provides any such component for WPF.
If it does not exist, then for WPF there are only two options - one could embed the WinForms component in WPF window through a special 'host' intermediate control, but that actually hits the performance and also has many problems when some advanced rendering features (like movie streaming) are used. Diagnosing and fixing them is complex, hard, and even unstable (crosshosted components behave very differently on different windows and .net versions, even on .net patches sometimes change them, it can work one one, and freeze on other, hang and render as black on next and cause a blue-screen on another)
Other option for WPF is to use the "offscreen" mode. Chromium can render to a bitmap, so why not. Render to bitmap, and display that. Simple. Quick. No problems.
So, I'd say, it all boils down to a famous quote from Eric Lippert:
The question is "why does [snip] not have this feature?" The answer to that question is always the same. Features are unimplemented by default; [snip] does not have that feature because no one designed, implemented and shipped the feature to customers.
It's great we can at least display Chromium in WPF apps. If you think it can be done better and that it's worth doing, it's open source, feel free to implement it - if not in CEF, then in Chromium itself.
Actually, I have started learning WPF. I have few months of experience in developing Windows Forms applications. Though, I am getting the meaning of a WPF application, but still I am not able to differentiate the difference between two, on the basis of their output.
With reference to this Link: Device Independent Pixel (DPI), I have learnt that whenever the operating system render a WPF application it manages its size itself according to its resolution.
So to check this difference, I created two demo applications in both frameworks and changed the resolutions as well.. but I didn't find any satisfactory difference. Which could explain it is a WPF application and this one is a Windows Forms application.
It does not create any scroll bar on maximizing and doesn't make the button big or small on changing the resolution.
I have read somewhere that Visual Studio 2010 has been rewritten in WPF. But in my experimentation I saw that, (on changing the resolution of desktop) it makes text and graphics unreadable/blurry. On re-sizing its window, everything was getting hidden except the menu-bar. And the menu-bar content was shifting its positioning, e.g. far right one menu items were shifting down. Why?
Kindly make me correct & explain a little more bit (this display issue) too.
To answer this question properly I should write a whole chapter, but I keep it short:
There are three major differences between a WPF application and a Windows Forms application: Layout, Render, Presentation
Layout:
WPF layout system provides a greater flexibility in arranging the elements on the fly. It is based on the Element Bounding Box (as opposed to precise pixels in WinForms) and Measure and Arrange mechanics (as opposed to UpdateLayout in WinForms) that automatically and dynamically finds the place for each element without any need for a manual update.
Basically, all elements bounding box are measured first and then are arranged using multiple methods such as Measure, MeasureCore, ArrangeCore, MeasureOverride, etc.
Unlike WinForms, where you have a pixel-perfect size for everything, in WPF you have much more options and complexity such as Width, ActualWidth and DesiredSize (and even Transforms as LayoutTransform) for the same element.
This is why
As you type in a WPF TextBox, its width might increase and push other elements away or even push some elements into a new row (like the menu bar you've observed)
As the size of a control changes, it affects the available space for other elements. So their size and location might change accordingly.
When the window is being re-sized or resolution is changed, it immediately updates the layout and changes the size of elements in order to fill or fit the space. Here you'll find out more about Layouts.
using Margin alone (without using layout capabilities) to arrange elements is not the best idea in WPF. As it's the WinForms mindset which isn't much helpful while developing WPF.
Render:
WPF uses double data type for Layout (as opposed to pixel-perfect WinForms) and therefore you might see the edges blurry sometimes, but it can be avoided with SnapToDevicePixels=true.
WPF is much more efficient in utilizing the GPU to render a GUI. Try a grid of 30x30 TextBoxes in a Windows Forms application and a WPF application. No matter how messy you write the WPF, it never blinks and it still runs much faster than Windows Forms. Even adding a handful of animations, visual effects and styles on them does not hurt your performance like in Windows Forms.
Remark: To avoid a speed decrease and blinking in a Windows Forms application, you should set DoubleBuffer of the form to "true".
You can use any Transform as RenderTransform to easily implement smooth zoom/rotate, or develop custom GPU-based shader effects, and much more in WPF. (I think everyone agrees that doing such things in WinForms is feasible but real pain and you most likely will give up and move to GDI+ or DX if not out of frustration then because of the bad performance.)
And the last and the most important:
Focus on presentation:
When develping WPF Applications you have to stop thinking in Windows Forms: No more UI events, accessing controls by their names and writing logic in code-behind and start to think in WPF: Binding, Commands, Resources, Styles, Templates, Converters, DependencyProperties and their callbacks.
The real power of WPF lies in separation of 'View' and 'Logic', Which can be achieved using the MVVM pattern.
It makes the most visually-complicated problems quite simple and easy to develop and easy to write Unit Tests for.
Once you got the hang of it, you will realize there's no limit in how you can present the data or show off an awesome GUI looks.
If you've planned to switch to WPF, you've made the right decision. Always stick to MVVM and AVOID CODE-BEHIND AT ALL COSTS! (i.e. unless you are doing a pure UI operation: do not write code in .xaml.cs files, do not access x:Name in cs files and avoid UI events.)
Windows Forms (WinForms) and Windows Presentation Foundation (WPF) are two different ways of building the user interface for your application. Windows Forms is the older technology and its controls are found in the System.Windows.Forms namespace. WPF is a newer technology and its controls are found in the System.Windows.Controls namespace.
WPF
Pros:
Powerful styling and skinning structure
Easy to create your own look and feel
Does support Windows Forms
The future technology for developing Windows Vista applications
The ability to reuse existing code
Highly advanced data binding possible
Cons:
Declarative vs. procedural code
Requires .NET Framework 3.0
Compared to Windows Forms, still in development phase
Requires Dx9 compatible video card for advanced graphics
Windows Forms
Pros:
Extensive documentation to be found on the Internet
Plenty of examples
Does support WPF
Cons:
How long will this be supported? (I've read somewhere that Microsoft is just developing WPF now, only maintenance for Windows Forms).
Design your own look and feel in an application is a lot of work.
I want to create an automated UI test that will test my syncfusion grid. My problem is that the recorder can't recognize this control (or any syncfusion control). I've searched a lot in the internet but I couldn't find any extension so the recorder will recognize my controls (I'm using WinForms, not WPF!), or at least a way to extend the recorder abilities so syncfusion's controls will be recognized somehow.
Is there any easy way to extend the recorder? Or is there any extension available?
Or maybe can I get the grid object from the WinClient that the recorder generates?
Thanks!
Start your program. Run the Spy++ utility. Type Ctrl+F to start the finder tool and drag the bulls-eye onto your form. Ok, Synchronize and have a look-see at the windows that are visible in the tree. If you see regular Windows Forms controls, like a Button or a Label, but not any of the SyncFusion controls then you've probably found the source of the problem.
Component vendors that try to improve .NET controls typically do so by creating 'window-less' controls. They are not really controls, they don't derive from the Control class and don't have a Handle property. They use the surface of the parent to draw themselves, making them look just like controls. The .NET ToolStripItem classes do this. And this is also the approach WPF uses.
The big advantage is that they render quickly and support all kinds of effects that regular controls can't support, like transparency, rotation and anti-aliased window edges. The big disadvantage is that the kind of tool that you are using suddenly gets noddy and can't find the control back. Because they work by finding the Windows window back on your form, there is no window for them.
This is a hard problem to solve, the 'control' exists only in memory and there's no good way for a tool to find it back. Using Accessibility is about the only other way for such a tool to find a control that I can think of. Which would have to be implemented by the control vendor first, a somewhat obscure feature that gets easily overlooked. You really do need the help of the vendor to find a workaround for this. Shouldn't be a problem, that's why you paid them the big money.
This is Rajadurai from Syncfusion. Thank you for your interest in Syncfusion Products. To make UI Test Automation recognize Syncfusion grids(WinForms), some internal support need to be provided in grid whose implementation is in progress and about to be completed. Please submit an incident through Direct-Trac for any further related inquiries in the following link.
http://www.syncfusion.com/Account/Logon?ReturnUrl=%2fsupport%2fdirecttrac
You can also contact us through support#syncfusion.com. We are happy to assist you.
Regards,
Rajadurai
I am developing a CAD like application. This application is cross platform in the sense that I have a main window which is native to the platform it is running on (Linux, Windows and Apple). Within this window I have an OpenGL context and there I do all my rendering. The application in question does not really rely on common controls (radio buttons, check-boxes, labels etc), however there is the need for the user to be able to enter/edit some text. This text could be a few lines long but not more than one hundred.
How would I go about implementing such a control, I don't want to go as deep as developing my own text editor but it would be nice if it had some basic editor controls (cursor movement, delete, insert etc). I also don't want to use the native systems common controls as my own none cross platform code at the moment is the main window.
Any ideas?
Edit: This is informative
OPENGL User Interface Programming
Thank you
I think you are taking a longer approach here.
Rather than providing an interface through OpenGL and writing my own controls, I would go for a cross-platform GUI toolkit such as wxWindows, and use the GLCanvas provided to do my rendering. You'll have all the might and flexibility of common controls, you'll still be able to OpenGLize whatever you want, and the look of your application will be more standard, thus friendlier.
Does it perform drawing by itself, or uses the native UI components provided by Windows in any way?
WPF sort of uses native controls because WPF is the new native way to render controls in Windows - what you consider native is legacy win32, and basically slowly on the way to history.
MS did a lot of optimization in DirectX to allow WPF efficiently to render using the GPU. This is a new "native" interface that is also used to render the Vista upward AERO interface. WPF goes directly to a native layer that then does whatever it can in the GPU - including text rendering.
Now, the reall tricky part in your question is "native UI components provided by windows in ANY MEANS" - well, these low level functions are provided by Windows, so the answer is yes. Primitive drawing operations in a new API were added, but they were added specifically FOR WPF, which is now considered to be sort of the new "native windows presentation layer". MS is slowly moving away from the Win32 API towards WPF for generic presentations (Direct X etc. stays around - WPF is way too generic to be usable for example for high performance first person shooters). As such, given WPF is the new "native components layer", the question gets really tricky to answer ;)
In WPF you can skin all of the controls in whatever way you please by overriding the templates. You absolutely can't do this with win32 controls, so therefore it can't use them.
It uses DirectX 9 to perform all its drawing. It doesn't use WinForms controls