Yes, it's me lug once more. I've been working on a gui editor for irrlicht. Yes, I know there are several already available. But this one is different. It has a preview render window of irrlicht (far left in screen shot). This window shows what the control looks like rendered in irrlicht engine.
The intent is whenever you move, resize, change property of a control in the gui designer tab (center in the screen shot), it will display the equivalent irrlicht gui control in the irrlicht render window in real time.
Once you get the gui in the position, size you like, you can preview the source code via the "code view" tab (for copy and paste into your project). Click generate button and the tool will produce .h and .cpp files with the relevant gui functionality in code.
You can change the gui in the gui designer using the property of the gui element via the property in the lower right corner of the screen.
Anyway, I figured I use what I've learned on my previous projects like irrDemoBrowser and irrShowMesh and make a GUI editor with all the features that I want in it. This project is just that. Also, it's an excuse for me to learn Visual C# (yes, the render winodw is being powered by irrlicht .net in it's very own thread separate from the gui).
Update:
Here's another shot showing the code view layout:
Update 2:
Here's a pic showing the property in action (for selected button):
Update 3:
BlindSide -- hey, thanks. lug is not a professional gui designer. lug just likes minimalist design.
The irrlicht button and the gui designer button now syncs with one another.
If you resize the button in the designer, you'll see the button in the irrlicht render window resizes too. If you change the text of the button in the gui designer, the text in the irrlicht button will change too. It's hard to see it without a video showing the button resizing in real time. Oh, well. I'll put one up once I get some more done. The sync functionality isn't very smooth yet (result of communication between two threads).
I couldn't figure out how to resize the irrlicht button after creation. So, each time the gui designer button is resize/updated, the old button is destroyed. Then the button is recreated in the irrlicht renderer window with the new gui designer size/text.
Update 4:
After many attempts, lug try and try but cannot find a good side-to-side layout that works. The app layout becomes unweldly and difficult to size. Lug did get the sync better between the designer and the renderer but lug just could not make the dual layout work. If one uses 640x480 res, the control can be made offscreen and resizing it inside the designer makes it all wierd.
lug tried 320x240 res but the two control takes up too much app space. 
So lug will put screen top and bottom like the Nintendo DS layout.
It will be fixed for now. lug will add a "maximize" preview window to allow user to view in larger resolution than 320x240 res. So, designer will be fixed at 320x240 res, then when code generated/preview screen maximized, user can pick another resolution like 800x600 and irrGUIEditor will generate code that position the controls to match that resolution. Well, for now lug will make it like DS layout. When lug figures out the best way to layout the render screen and designer, lug will post update.
Update 5:
Update 6:
Fixed a nasty resize sync issue. Whenever resizing the button, the x2 and y2 values decreased to negative values which makes the irrlicht rendered button disappear. That took several days to figure out.
Update 7:
Update 8:
My oh my. Hiding properties using the propertygrid is a pain. I had to use the browseable(false) hack on every single properites that's in a button control (20+) in a derived button class.
So, for each one, one has to provide a default return value for the get (if it has one). When you consider each property has a different return type, the amount of work adds up really fast.
And that's just for the button control. I would have to do one for each of the equivalent irrlicht controls. Hrmph.
Update 9:
I'm currently rewriting the threading support. The background worker thread is too restrictive for what I wanted to do. So, I'm scrapping it and handling threading manually. I think in the long run, it will prove much more flexible and easier to managed. Thank you all for the show of interest.
