We Keep Coding

How do I get two panels to share a parent's width in Devexpress

This sounds simple to me but I'm not sure if there's a best/suggested way to do it.
I'd like my UI to have a panel docked along the top, split into two panels, left and right, that always share the width of the parent equally. There'll be a minimum overall width so nothing gets squashed, but on resizing I'd like the two panels' widths to always be equal.
I thought of using a split container control but it doesn't do what I want in this case as I can't disable manual resizing.
My current idea is just to override the onResize method (forgot the exact name), and just manually set the two widths to parent.width/2, but it seems a bit roundabout, and potentially slow if it's calling onResize for every pixel's worth of movement.
Is there a better way to do this, or a control/layout that handles this for me?
Disclaimer: I'm using an older version of DevExpress, 10.1.4. It's not my decision and I don't think I can get the team to upgrade at the moment. Using C# on .Net platform 3.5.

I would drop a couple of panels onto the form and set their Size within the form's ResizeEnd event handler. This looks to be the best solution from my point of view.

You can use the XtraLayoutControl to achieve this, but that might be overkill.
Otherwise, you'd have to do it manually.

Windows aero glass form text problem

I use windows form with GlassForm(using Microsoft.WindowsAPICodePack.Shell;). my problem when I change form to GlassForm my textbox texts doesnt

Place a panel on the form set the dock style to fill, set the panel's BackColor to color X and then set the form's TransparencyKey to the same color X.

Yes, that's how it works. With the Aero Glass effect applied, anything drawn in the color black will be rendered as transparent. That includes text in a textbox control. This general theme has been the subject of many other questions here. When well-written, they gather lots of upvotes, but few answers.
There just aren't a lot of good solutions here. All of them that I've come across qualify as both "ugly" and "hackish". Owner-drawing is a reasonable approach when you're using something like a label control, but I wouldn't recommend trying to draw your own textbox—it's just too hard to get right. Someone tried to do that here; like I said, the result is both ugly and hackish. I wasn't satisfied with it for my own use, but it may work for you, depending on how high your standards are.
The goal with owner-drawing, of course, is either to do all of the drawing using GDI+ (which natively supports transparency) instead of GDI (which all of the built-in controls use by default), or calling functions like DrawThemeTextEx, which is specifically designed for rendering text with a shadow that is [somewhat] readable over glass.
As well, the usual tricks like enabling compatible text rendering (which causes the built-in controls to draw using GDI+ routines, as they did in the early versions of .NET) don't work for a textbox.
Honestly, your best bet is to place the textbox over a region of your form that is not rendered as glass. Use the DwmEnableBlurBehindWindow function to selectively enable the glass effect behind certain areas of your form, rather than the entire thing. I provide a complete, ready-to-use .NET implementation in my answer here.

Check this sample out:
http://www.danielmoth.com/Blog/Glass-In-C-An-Alternative-Approach.aspx
I was not studying it any further but putting a TextBox or Button or other components over this Aero glass area worked - the rendered component didn't have the transparency problem. The labels aren't perfect but these can be easily drawn with GDI+
The direct link to the sample project is here: http://www.danielmoth.com/Blog/MothGlass.zip
It looks like he puts a panel behind the control and setting the TransparencyKey for the panel.

handling orientation changes effectively for all controls with small code change

I have a Windows Mobile project built in C#.
I have a lot of ready made forms having various controls on it, from Listviews to Editfields.
When user changes orientation some elements are not refreshing correctly. For example the Listview's columns are same and doesn't accommodate the new screen width change (scrollbars appear or half of the screen is filled).
How do you handle these changes?
Do I need to call for each form these fixes by hand, or I can create some kind of global way to fix this? I would like to go with the simplest method if possible.
I would like to avoid the classic way, to add code to all of my forms. So I am looking for better ways, and I would like to see more ideas.

I'm assuming that most of your controls are using a DockStyle, and that will get you 90% of the way in terms of updating the GUI on orientation changes. For the ListView, you'll have to add in some code.
You can add an event handler on Form.Resize, and there put in code to resize the ListView columns. You can tell portrait vs landscape by comparing width vs height. There's also a way to add an event handler on an actual orientation change, but it's interop and I don't remember the code offhand. Form.Resize should be sufficient for most cases.
You can check out an example here

.Net Windows Forms ListView OwnerDraw LargeImageList leak

I'm ownerdrawing .Net Windows Forms ListView control and see a very strange bug/behavior when I need to draw an image from the associated LargeImageList.
When the View type is a type where LargeImageList is used (Tile, LargeIcon, etc.), I draw item images from the LargeImageList. At that condition, I see a huge memory increase and when you try to scroll ListView this becomes more obvious as you see a jerky scroll as well. This same thing does not happen when the same code uses SmallImageList which is simply like this :
Image MyImage = this.LargeImageList.Images[MyIndex];
e.Graphics.DrawImage(MyImage,MyLocation);
This is reproducable under XP and 7 according to my tests. Is this a known bug, any workaround?
Regards,
Özden

Although I still think this is a bug, I found a workaround. If you draw using ImageList.Draw instead of e.Graphics.DrawImage this problem seems to go away.

How are you managing the invalidated drawing area? As you are saying, looks like you are "overdrawing" the control, I mean, drawing even when it is not necessary.

C# Containers -- Filling a Space Vertically on Resize

I'm new to C# and I've been working on a small project to get the feel with Visual Studio 2008. I'm designing the GUI in C#, and I have a TabControl with three GroupBoxes. These three GroupBoxes are anchored to the left and right of the screen and work perfectly when resized horizontally.
I would like these three boxes to take up 33% of the height of the screen, and gracefully resize. I've tried messing around with anchoring, but I can't seem to find the answer. I've also been searching for something similar, but unfortunately, searching for positioning containers yields all CSS and HTML stuff.
This seems like a pretty common thing to do, but I can't seem to find an easy to way to do it. If someone could point me in the right direction, I'd greatly appreciate it.
Thanks!

Try out the TableLayoutPanel. I believe it does exactly what you want. It allows you to define columns and rows within its area, specifying their width (for columns) and height (for rows) in percentages or pixels. You can then drop a group box into each cell and set its Dock property to Fill, and it will nicely resize along with the cell when the TableLayoutPanel resizes (which can be easily achieved by using docking or anchoring).

This is really a shot in the dark but maybe you could try using split-panels ?
Edit: I've just checked in Visual Studio and I think the TableLayoutPanel might do what you want.
Edit2: dang, beaten to the punch :)

Handle the form's Resize event: Add code to compute the new size/position of the controls in there. Beware to interferences with the controls' Anchor property. You may have to Anchor to None and compute left and right position yourself as well.
Since you're learning, I guess you prefer not to receive a full solution but rather a direction. No code from me then ;-)