We Keep Coding

What are the point in layouts/panels?

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.

Reordering and Dragging adorners are not visible inside the Flyout

I just tested the ListView control in Windows 8.1 for my Windows Store application. I really like the Reordering and Dragging of Items in the ListView and it is obviously required to use inside the Flyout for my application.
Unfortunately i get some problem with the Dragging and ReOrdering of ListView items when i use inside the Flyout. Begin with, Dragging of Items are working fine as expected in the normal display. If i use inside of Flyout, Dragging adorner is not visible over the Flyout and instead it comes beneath the Flyout.
I have attached the screenshots in the normal and Flyout display.
Sample has been attached in the below SkyDrive link. It would be helpful to you guys to grasp more information about the problem.
https://skydrive.live.com/embed?cid=89346CF5C45CEB8C&resid=89346CF5C45CEB8C%212942&authkey=APwj9svhnGFMqwY

This is not going to be a satisfying answer. I have been struggling with the same issue for a while now. I decided to move the reordering to the top AppBar only to discover that the same issue shows up there too.
I found an existing question on msdn and added my own comment and according to a Microsoft employee this is not a bug but a feature:
http://social.msdn.microsoft.com/Forums/windowsapps/en-US/c1add91a-e887-4d08-a3f8-884ec22239f6/dragged-gridview-item-is-not-visible-when-it-is-dragged-over-appbar
As for a solution:
You can change your design and move the reordering out of the settings flyout into the main screen.
You make your own flyout / top application bar control.

How to have windows forms control catch drag enter instead of embedded WPF canvas

This is a pretty basic setup. I have a System.Windows.Forms Panel that holds an ElementHost control that holds a System.Windows.Controls Canvas. The user begins a drag operation and the drag enter event is fired from the Canvas control, but what I really want is for the canvas to ignore the drag enter and for the event to be caught by the parent System.Windows.Forms.Panel that holds the canvas. How can I do this?

The simple answer to this, is that you cannot do that. If you mix Win32, WPF, or DirectX technologies on top of each other, then the one on top takes precedence and it is a black hole to the other technologies. The limitation you are experiencing is called Airspace and if you search around you will find many articles discussing airspace restrictions and mixing WPF/Winforms/DirectX content. Please see the following link:
Technology Regions Overview
There may be methods that would help to provide a workaround for what you are trying to accomplish. For example, handling the input in WPF and then passing it explicitly back to your program in some other manner. Some quick googling shows:
Mitigating Airspace Issues
WPF and Win32 Interoption

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?

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.