C# Port

[CrazyEddie]

Yeah, this was actually that it never added a window to the 'top', always one under,

Here you go dude...

Code: Select all

--- window.cs   Mon Jun 14 21:52:00 2004
+++ window.cs   Wed Jun 16 18:48:45 2004
@@ -276,7 +276,7 @@
 
                   // re-add window to parent, which will place it behind all top-most windows,
                   // which in either case is the right place for this window
-                  parent.AddChildImpl(this);
+                  origParent.AddChildImpl(this);
 
                   OnZChangedImpl();
                }
@@ -1258,17 +1258,17 @@
             window.Parent.RemoveChild(window);
          }
 
-         int position = (ChildCount == 0) ? 0 : ChildCount - 1;
+         int position = (ChildCount == 0) ? 0 : ChildCount;
 
          if(!window.AlwaysOnTop) {
             // find last non-topmost window
-            while((position != 0) && children[position].AlwaysOnTop) {
+            while((position != 0) && children[position - 1].AlwaysOnTop) {
                position--;
             }
          }
 
          // add window at the end
-         if(position == (ChildCount - 1)) {
+         if(position == ChildCount) {
             children.Add(window);
          }
          else {


Also fixes a bug in your AlwaysOnTop property setter.

[leedgitar]

Ah crap . Thanks for the fix.

The funny thing is, throughout everything I had ported up until the first time I ran it, AddChild was the one thing that I thought to myself "this will have a bug in it for certain". Looks like I guessed right .

[CrazyEddie]

Ah crap . Thanks for the fix.

The funny thing is, throughout everything I had ported up until the first time I ran it, AddChild was the one thing that I thought to myself "this will have a bug in it for certain". Looks like I guessed right .

I recall when I had to modify the the original version of that method (mk-1 system) to support 'always-on-top', I had similar feelings - and also ended up with some wacky behaviour

[leedgitar]

Short update: I've taken a few days off to refresh myself, and got back into coding mode last night. I went back and reworked a few things in Axiom, which includes a new and improved Input reader which supports buffered input; required for key events in the GUI.

Now that the key events are fired and the modifier (system) keys are being tracked and all the good stuff, I was able to fake input editing by handling the key down event in my testbed and simply appending the character to the text in the static text area from the first demo . That at least allowed me to test all the mappings between key codes and characters, modifier keys (for upper vs. lower case), etc.

I don't know if I'll have anything done in time for the traditional Sunday demo (since it is Fathers Day), but I won't release another one until I at least have the editbox, scrollbars, and the font code tweaked to eliminate the artifacts.

[CrazyEddie]

I don't know if I'll have anything done in time for the traditional Sunday demo (since it is Fathers Day), but I won't release another one until I at least have the editbox, scrollbars, and the font code tweaked to eliminate the artifacts.

I too have missed the Sunday demo day this week Mainly due to the fact that I don't have enough new stuff worth showing off. Oh well. At least next weeks demo's will be worth waiting for

[leedgitar]

Whoa, I can't believe 2 weeks has already gone by since my last update. Anyway, in the last 2 weeks, I have been shifting focus to some overdue cleanup in Axiom, as well as getting running on Linux using Mono 1.0. I'm happy to say that it was successful I seem to be having an issue in Axiom on Linux where some of the textures are showing up white, which at the moment doesn't seem to have any of the obvious causes of such a problem.

Tonight I actually got my GUI demo running on Linux as well, minus the fonts which aren't showing up correctly, even thought I've tested the dynamic font bitmap stuff with GDI+ under Linux and the resulting bitmap came out correct; I'm sure it is related to the above problem in one way or another. Ironically, the dynamic code compilation and all that worked fine

So, I've made all the changes to Axiom that Sinbad mentioned he was going to do with Ogre in terms of eliminating the GuiElements plugin and moving the basic overlay elements into the core. Thats working again, so once I get these issue ironed out, all the Axiom demos will switch to using the new GUI for the FPS readout and such, in addition to something else I am cooking up for it

Stay tuned for a GUI screenshot running on Linux; I'll wait until I get this texture madness worked out before posting one.

[CrazyEddie]

Time flies when you're having fun, eh!?

Getting Axiom to run on Linux is definately a huge deal, and is an ideal way to give the finger to all those who say .Net is not portable, etc (as this proves, .Net has the potential to be more portable).

Am eagerly awaiting the next round of updates for the C#/Axiom version of the Gui, though I'm a little worried at what else you may be cooking up - especially after the spanking you gave my version with your dynamically compiled widgets

Anyways, keep up the excellent work - whatever area you're working on

[leedgitar]

Alright, I'm back in action and coding away! Tonight I eased myself back into development (after some serious downtime) by tackling the uber complicated StaticImage widget .

I need Dropdown and Editbox in short order, so I'll be pounding away on those over the next week or so, in addition to getting the existing core classes in sync with recent changes. Luckily, CrazyEd himself provided a C# port of the Listbox and Scrollbars, which work fantastically. If anyone is up for tackling the Grid widget, XML layout loading, or anything else that would be useful, let me know.

[jwace81]

I'm glad to hear that you are back in action leed I have actually done a little bit of work on CEGUI myself starting with your last release. I have a working xml layout xml layout loading code in this thread (link) I have even taken it a step further an added the ability to bind gui events to functions within an object that are tagged with an appropriate attribute. This is similar to what CrazyEddie wants to do with the scripting support, but all done internally through reflection in C#. The event binding support hasn't yet been published.

I also have an Editbox widget that is about half complete. I decided that I would wait until the support for buffered input made it into Axiom to continue working on it. If you want, I can send you what I have completed.

Also, Bryan on the Axiom forums would like to know if a new sourceforge project should be created to contain the C# port of CEGUI. That is brought up in this thread (link). He has written his own Renderer for his Ovorp project.

J.W.

[CrazyEddie]

I'd help out with anything except the grid widget Man, I hated writing that!

Seriously though, if you do get stuck and need someone to do that, or any other widget, I'd be willing to help out where I can

CE.

[leedgitar]

(Update: copied from the Axiom forums)

Editbox and ComboBox are pretty much done. I still have a general activation issue with children that produces the following crap:

1) The FrameWindow close button appears over top of the titlebar, but does not appear to highlight when the mouse hovers over. This appeared after switching to the new layout, where before the titlebar and close button did not overlap so they were fine.
2) Activating the editbox is funky: sometimes one must click on other widgets first, then come back to the editbox before it accepts input (regardless if the carat is visible or not, heh).
3) The scrollbar appears in a combobox just fine, but does not accept input; looks like the droplist is stealing it.

There is likely a subtle variation in the

MoveToFront/AlwaysOnTop/AddChild functionality that I still have yet to identify; all these problems are similar in nature.

Regardless, I'm happy with where the GUI is at the moment, and the sooner this gets into CVS, the sooner people can help find my screw ups! . So, in the next night or 2 I'll get this into the new CVS location.

Controls that people can feel free to volunteer for porting include (but are not limited to):
- Tab control
- Grid.
- Multi-line editbox
- Windows look controls (all)

[CrazyEddie]

The scrollbars in the combobox do not get inputs because the drop-list captures input. I modified the C++ version to get around this by testing children of a window with input capture so they get a chance to process the input first. However, this also causes some issues (in the C++ size a window so small so the mouse enters a child window and you'll see what I mean). I am going to come up with a final solution over the next couple of weeks.

I might be temptedto do one of those widgets, I'll let you know

Do we have forums on the ceguisharp project yet? As we could use them so people know what everyone else is working on I haven't been doing much as I've had to rebuild my main system after a hardware failure, I should finish that today, and start work on the GUI stuff again tomorrow

CE.

[leedgitar]

http://ceguisharp.sf.net will now take you to the exclusive forum for the GUI port.

[CrazyEddie]

Cool

Over the weekend, I'll revisit the Listbox and add the missing sort functionality. Then possibly do the header widget bits as preparation for the grid

CE.