inheritence and ElementRect

Nov 1, 2009 at 7:22 PM

Hi, I'm working on the UI  of my project.

The UI will be made up of SolidColorElement, TexturedElement and TextElement objects, but to organize things, I'd like to have containers to put stuff in it.

A container is an invisible object that has a size and position. And it's child objects are positioned relatively to it (HorizontalAlignment & VerticalAlignment).

Some time ago I tried to implement it, I had problems when drawing, since a container has no graphical representation, I had problems with the shader and child elements did not draw correctly.

The simple solution would probably be to extend a SolidColorElement with an alpha of zero. But is there a better way that wouldn't try to draw an invisible object and that would keep all the functionnalities (relative position, alignment, scale, clipping of children, ...)



Nov 7, 2009 at 1:21 AM


So does anyone have a suggestion on how to create a subclass of ElementRect that won't draw itself, but only it's child, and keep the relative positioning and other functionality?

Nov 8, 2009 at 9:42 PM

Ok nevermind, I don't know what I did wrong the last time I tried it, I guess I forgot to override a method. It seems to work now.

using System;
using System.ComponentModel;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Xen.Graphics;
using Xen.Ex.Graphics2D;

namespace KDF_GUI
	public class ContainerElement : ElementRect
		public ContainerElement(Vector2 sizeInPixels)
			: this(sizeInPixels,false)

		public ContainerElement(Vector2 size, bool normalised)
			: base(size, normalised)
			//This is used when we clip chlidren
			this.AlphaBlend_State = Alpha_BlendState_e.Alpha;

		protected override void BindShader(Xen.DrawState state, bool maskOnly)
			//This is invisible man!

			if (ClipChildren)

		protected override void DrawElement(Xen.DrawState state)
			//This draws the actual element
			//A container is invisible, ... do nothing.

			if (ClipChildren)

		protected override void PreDraw(Microsoft.Xna.Framework.Vector2 size)
			//Updates vertex data when dirty
			//A container has no vertices, ... do nothing.

			if (ClipChildren)

		private Color colour = new Color(Color.White, 0);
		protected override void WriteColours(ref Color topLeft, ref Color topRight, ref Color bottomLeft, ref Color bottomRight)
			topLeft = colour;
			topRight = colour;
			bottomLeft = colour;
			bottomRight = colour;

Nov 9, 2009 at 11:33 PM
Edited Nov 9, 2009 at 11:35 PM

Hi Iarus. Once again apologies for not getting back to you very quickly. You know how these things can be :-)

I'm glad to see you have found a solution. It's not well documented (I admit) but the 'ElementSize' and 'UseSize' virtual properties are quite important in how sized elements behave, so if you find you have size related issues - this will be a place to look.
I'd also suggest you consider some of the other open source XNA UI tool kits out there. There are some very nice ones, and provided you wrap it up in a StateBlock, most of them do play fairly nicely with xen. (Although some insist on sitting in a game component.)

I know in the past other users have managed to integrate them with little trouble. The 2D elements are certainly useful but I would be cautious if you plan to build an entire UI system from scratch - it's one of those things that at first seems fairly trivial but quickly can balloon out of spec. Trust me, I'm rewriting a UI at work right now - while it started with good intentions it quickly grew into a monster (So it feels good to be replacing it.. :-)

For example, a quick search brought up:



Nov 10, 2009 at 5:04 PM

Don't worry about the somewhat late reply, sometime you get -infinity time to work on your own things or even read your emails, it's part of the job. And changing country probably didn't help!

I'll keep in mind 'ElementSize' and 'UseSize', they might be usefull really fast.

I'll look into other UI project, but I'm somewhat confidant that I can make one, as I 've worked with multiple ones since the last 2½ years. I've seen the good, bad and ugly of UI systems across multiple game.

Anyway, it's not like I want to create the best all in one super flexible super awesome menu system that work for everyone and every game.

If porting what I already had to the new method goes well, I should have something that work before the end of next weekend.