See part 1 here

null

Expanding on my initial ideas I decided to go with something similar to the listener/observer design pattern. Basically, objects can register with a Listener as ‘posters’ and other objects can be added to the listener as ‘listeners’. Whenever a poster posts an event to the listener, the Listener updates all those ‘listening’ with the new event.The above screenshot is not UML or in any particular format but shows the general idea.In my previous article I noted the fact that I was not happy with using ’subMenu’ notation. Sub-menu’s are a good concept for a file menu or similar, but not for an actual Menu interface. With a menu interface you don’t really want to have to consider problems like how many levels deep should the menu system go? Who updates what?The listener model allows any number of menus to listener to any other number of menus posting events. Effectively, you get a nice cascading effect.So, after writing a DLL to include things based around the above idea (Listener, ActionEvent, EventPoster, EventListener and so on) and another DLL for the actual GUI set (Menu, GameMenu, MenuItem, Button, TextBox, CheckBox, PictureBox etc) I was in business.It then occurred to me if you were building some sort of consistent interface, you would probably want a way of changing the look and feel of ALL of these widgets easily. Initially, when each component was rendered the component itself had specifed how it was rendered (what colors to use for fill, border, highlight, hovering, textFont etc). I re-wrote a whole lot of this code in the base MenuItem class to allow the setting of all of these parameters individually.So, now each menu item/widget could have it’s color set changed. A nice way of changing an entire widget set was then in order.For this task I wrote a basic Factory class GuiFactory to handle this. The idea was you would set your colour set once in the GuiFactory and then it would return you the appropriate widget using that colour set. If you wanted to then change the colour set, you could do so, and then get an entire new set of widgets conforming to that colour set.Something like the following could then be done.

// Create a factory with a default red colour set.
GuiFactory gf = new GuiFactory(GuiFactory.Red)
// Have factory return us appropriate widgets.
Button btn = gf.CreatButton("TestButton", 75, 50);
TextBox tb = gf.CreateTextBox("TestTextBox", 100,50);
PictureItem = gf.CreatePictureItem("TestPictureItem","SomeTexture");
ChekBox cb = gf.CreateCheckBox("TestCheckBox", 50);

So, it is now easy to get an entire set of widgets/components conforming to the colour set loaded.With the same idea in mind as that above, I’ve *started* on a GuiTexturedFactory. This allows you to load textures into the factory and the components it returns are all constructed with the appropriate textures. So you can skin your components. here to from here? I’ve still got a lot of work to go in creating more GUI components ( I wanted to say widget again but the word just keeps coming out like word vommit. For some reason the word widget just sounds so cool).

I digress, to build a menu system complete with gui components that are somewhat extensible (can change their rendering effect and can be skinned with textures and have the ability to create an component sets that ‘fit together’) is a big task.Both the new listener approach to the menu system and the GUI library i’m writing are coming along nicely. But one tough cookie to crack is developing some form of ‘form designer’. It is all very well in having a GUI library that you can use programmatically; it is another to provide support for easy form creation and component positioning.This wil easily prove to be one of the most difficult aspects of this endeavor. At least in the short term creating some sort of simple positioning system for the Menu componet will provide some relief. Thus, getting some control over the placement of items on the menu.

Basic Menu functionality already includes the ability to have the Menu automatically scale your items (such as a button) to the width of the menu for instance. Or you can opt to place the component onto the Menu using item propeties. That is, you can define an item as being not resizable. So, when it is placed on the menu it is not scaled to fit the menu like in the aforementioned case.To partly aid in placement, I have developed a simple panel component (which can be thought of as similar to Java’s FlowLayout :) Though the overall system is still nowhere near as complex.

// Create a panel with horizontal alignment// and spacing of 5pixels.
Panel myPanel = new Panel("panelName",Panel.Horizontal, 5);
myPanel.Add(component1);myPanel.Add(component2);
myPanel.Add(component3);Menu menu = new Menu("menName");
menu.AddItem(myPanel);

Looking at the above. You can add components to a panel specifying a horizontal layout (or vertical) with default spacing. Then, you would add the panel to a Menu. The menu would then run through all the items on it and call their Render() method. In this case, the panel would then in turn call Render appropriately (for each of the components on it).

Whilst i’m not planning on creating some GIGANTIC Gui system which 100 different layout types and…..you get the picture. I”ll have to create a few things to help until I one day find the time to write a application like a form designer.That’s it for now, time to get back to exploring genetic algorithms :)Tech Tags: