During an interview, the company was asking about my use of custom controls in WPF. I have found with all of the power of the WPF way of creating a control (datatemplate, control template, styles,triggers etc... ) that having to write a custom control that overrides the OnRender method really hasn't been necessary. Later found out that most of their development has been in Winforms.
If coming at a control from a 100% WPF direction, how often is it necessary to write a customcontrol with OnRender overrides? The Winform approach is really not making use of the WPF composition technique of creating controls and it seemed like a question not based on much WPF knowledge.
Thanks
Harold
Good question (though a bit opinion-based) and no answers? Fixing.
If you are winforms-experienced developer, then thinking winform-way is still acceptable in wpf. For a while. This is where you may find self making mostly custom controls (containing xaml and code, or even without xaml). But the more you learn, the less you need that. Many many tasks can be completed in wpf simply because it is very flexibly. Every entity consist of something what can be customized: templates, styles, converters, behaviors or even plain event handling.
You can start with custom control and then find out what you don't really need it (or it can be downgraded to simple restyling).
When I started making first serious wpf project, there were 3 custom controls and they are still. Here is why.
Outlined TextBlock. Simply because you need custom OnRender (to build and draw geometry for outline).
Animated content. To apply transition animation when changing content. I could almost make it without custom control, but there is a problem - calculating animations logic when transitioning left-to-right, right-to-left, up-down or down-up. It's waaaay easy to have in one custom control. But possible with UserControl and view, not as pretty still.
Graph. Simply because it's too complicated to be presented with Visual and because of performance using gdi+ gives millions of points (hundered thousands figures) to be drawn within ms.
Conclusion: it's good and useful, though way less than it was in winforms (where you simply had no other option).
Related
I have just started getting into learning WPF, and to add controls to the window I just move them from the toolbox and onto the window. Then I can continue moving them to put them in the places I want. Now I have got into layouts/panels, stack panels, canvas,dock panels etc and I am struggling to understand why they are useful if you can just drag and move objects/controls on the screen yourself.
For example dock panels, using the dock property you can put the object on the left,right,bottom,top,lastchildfill. You can dock a textbox to the left by using the property, DockPanel.Dock = "Left", but why can't I just move it there myself?
First off, don't even waste time drag/dropping controls into a WPF app. By placing controls in this manner, you are severely limiting your design potential in WPF. Most serious WPF designers don't even bother dragging controls, they hand type all of the XAML. Arguably, this is how WPF was designed. Leveraging XAML allows your layouts to be totally dynamic in ways that WinForms could never dream of, but you have to hand code the XAML.
Do you see where this is going? Don't drag/drop controls when designing WPF apps! Every conference I've been to stresses this fact! Grid panels are a huge part of WPF layouts, and are crucial to getting your controls to end up where you expect.
The hardest part about learning WPF is figuring out it is not WinForms with nice graphics. It is a totally different beast, with a steep learning curve! Hand coding XAML is extremely tedious at first, but once you learn the names of all the controls and the important properties, you'll be cranking out UIs way faster than the old drag/drop method.
You can move the controls manually, but different layout panels can automatically handle controls positioning when You add new controls or when the window is resized.
Please take a look at description on MSDN and on CodeProject that describes different types of containers.
I am working on a Win8 app destined for the Windows Store. Hurdles I am trying to overcome is how to deal with the different ways an app can be displayed.
Currently, my main pages is a LayoutAwarePage so it has logic to handle different visual states. However, my question is more how to make my page render differently depending on its state.
I thought, initially, that you basically created a layout for each state that the application supports. But it seems like the VisualStateManager portion of the XAML is just an area where you make piecemeal modifications to the design (hide an element, change an alignment).
I am working with a grid that has many columns and rows to organize my controls and it looks great in fullscreen. However, this doesn't work at all in the snapped state, as most of my controls become hidden off screen. I could certainly add a ScrollViewer control, but this is basically a hack and a usability nightmare for a user.
Thanks for any insight!
It might be that your app doesn't lend itself to snapped view. You are allowed to simply display a message / image that states this. Alternatively, consider just showing the columns that are most important.
The standard MS way seems to be to replace horizontal oriented controls with vertical ones - maybe a listview or something would look better. You'll probably find your code easier to read if you have one control for snapped and another for full screen.
Not exactly related to your question, but Blend works very well with XAML to allow you to manipulate the grid or show the relevant control.
Here is a very good guide from Jerry Nixon.
http://blog.jerrynixon.com/2012/12/walkthrough-implementing-snapview-in.html
I'm a fairly new programmer; semi-seasoned. But I still need a lot of learning. So I've focused on a few languages. C# is the big one.
Now I know Visual Studio lets you simply pull a button straight out of the toolbox. You now have a control; that manipulates that object.
I'd like to get really deep into programming a button for instance. Create my own custom buttons; Where I can draw the shape, size, gradients, hover effects, glass effects, drop-downs, really get into the nuts and bolts to create these reusable, dynamic, decorative controls.
What is the best starting point? Any advice seasoned developers could share with me?
Add a xaml "UserControl" to your project and make the WPF content of what you wanna render on the control in "Template" property. Then you should use some Binding expression to load content and handle events. It's so simple to do that and make whatever custom thing you need in WPF. There is no need to do paint things like .NET 2.
Cheers
I would like to know if there is a way to manipulate an App's UI live while running?
I am not a designer and I have many problems sometimes regarding matching colours etc.
The next problem is that anytime I would like to change e.g. the colour of a control I have to quit the App then go to VS2012, apply my changes, build and execute it again to see simple changes.
I know that I see any changes in the designer but I have to see the resulting screen to get an impression of the whole.
Is there a way to achieve this?
Add a secret keypress while Debug flag is set, that raises a form and allows you to select controls and expose a property sheet for them. Be a bit of work to get right, and a good stick of code even using reflection. Might be better off with a storyboard type app to do your designing.
Unlike styles in WPF which can be dynamically adjusted (which made this type of run-time adjustment simple), there isn't as elegant of a solution for Windows Store apps. Ideally, you'd have all of your UI and colors, etc. defined in XAML files and not settable through other means (as it becomes a longer term maintenance issue).
I'd suggest just adding enough test data and configuration so that you can see the look and feel of the pages (with colors, etc.) at design-time. Blend and Visual Studio are now quite good at showing a very reasonable near final rendering of the elements of the application. It's generally not too difficult to do anymore.
One thing I've done in the past was to make a single page/form that contained all of the styles and controls in a large scroll viewer. Then, we set it so it was configurable to the be the first thing to run. The tweak/build cycle was pretty fast, and the results were still very manageable.
I have to create an animated flow chart GUI which displays different states. Further on demand the flow chart elements are re-positioned and re-sized if the focus shifts to certain elements.
All of this is no problem, with drawing shapes, animations, etc. provided by WPF this is an easy, though by hand and alot of manually is done.
The problem I am facing is, that there will be > 40 of these flow charts.
Is there a template mechanism or generic approach to generalize this task?
Creating a set of user controls is the right way to deal with this problem.
The advantage is, animation and design can be encapsulated into the user control files. This way they don't polute the main application code.
There is a project called Graph# http://graphsharp.codeplex.com/ an there must be similar projects on codeplex.