What are the point in layouts/panels? - c#

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.

Related

Custom Control in WPF as necessary as in Winforms?

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).

WPF layout changes (Fill, Full, Snapped)

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

Windows Forms templated data

I am developing an application that wraps Lua to enable interactivity with geometric shapes and their properties and I am about to finish but... in the main window, I have a flowlayout panel that should show the properties for said shape, as how Lua dictates.
Here comes problem/question as I don't think clearing the panel and re-adding the controls that represent each property, each time I have to update the properties is a good idea nor the most effective solution, is there something I can do to enhance this?

Generic approach to create flow charts in WPF

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.

How can I create a button with an embedded close button

I am trying to create a panel which will have a set of "buttons" on it.
These buttons should have the following behaviour:
Appear similar to a tag (with
rounded edges)
Contain a red
cross to remove the filter/tag from
the panel, similar to the way internet
explorer tabs have an embedded cross to close the individual tab.
allow the user to click
on the tag and respond like a normal
button (as long as the click is not
in the red cross)
Number 1 is no problem, this is just appearance, however, regarding numbers 2 and 3, I am not sure if there is already code out there do to something similar...and I dont really want to reinvent the wheel if I can avoid it!
My question is: Does anyone know if there is something out there in infragistics which will do this simply, or will I need to write this myself by subclassing winform buttons?
Thanks in advance!
Is this new development or maintenance of an existing project?
If it is maintenance, you have a somewhat tougher time ahead. You'll implement a UserControl, probably segmented into two buttons. Use docking to get the behavior as correct as possible. The far right button would contain your cross image; the left (which would need to auto-expand as you resize the control) would contain your primary button behavior. Play with the visual styles until you get them right (EG, removing borders, etc).
If this is new development, and you haven't gotten too far into it, you might consider using Windows Presentation Framework (WPF) instead of WinForms. It will be easier to build the control and get it to look exactly how you want it. WPF includes an extremely powerful control compositing system which allows you to layer multiple controls on top of each other and have them work exactly as you'd expect, and it carries the added advantage of allowing full visual control out-of-the-box.
Either way, this is more work than dropping in an external component ... I've used Infragistics for years, and I can't think of anything they have which is comparable. The closest, but only if you're building an MDI application and these controls are for window navigation, is the Tabbed MDI window management tools -- and there, only the tabs (which replace window title bars) have this behavior.
I don't think that infragistics can do something like this. The UltraButton control can't.
Implementing a own control wouldn't be that hard.
your probably going to have to make a costume control for this type of work.

Categories