Jump to content


Photo

Xnet Won't Close


  • This topic is locked This topic is locked
2 replies to this topic

#1 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 02 January 2006 - 07:36 PM

XNET bug

Is anyone else having intermittent problems getting XNET to close when you click on the “X” at the extreme top right of the XNET screen?

I find it usually (but not always) refuses to close if I
1. Start Xenocide.
2. Open XNET
3. Click on “Alien Craft”
4. Click on “Recon”

If I then try opening and closing a few other topics in XNET, close usually starts working again.

Even when close doesn’t work, the top right region of the screen does “blink” when I click on the close control. So I know CEGUI is accepting the click. (I have confirmed this with logging.)

One thing I did notice is that there seems to be different “close” handling for different views.
e.g. The statistics (and options) dialogs register a member function to respond to the “close”, and in the function they post an event.

EventMap eventMap(FrameWindow::EventCloseClicked);
eventMap.handler(dialog, &Statistics::handleClose, this);
bool  Statistics::handleClose(const EventArgs& evt)
{
    GameController::instance().postEvent(TIntrusivePtr<States::EvHideStatistics>(new States::EvHideStatistics()));

    return true;
}

However, XNET and Baseview just create a temporary event object.
eventMap.handler("XNet/Back", States::EvHideXNet());
eventMap.handler("Baseview/Back", States::EvExitBaseview());


Could someone please explain why these are different, or point me at the relevant thread where this is discussed? (Aside, I’d like to know some more about this event stuff. For the transactions dialog, I just cut and pasted the event logic that the statistics dialog used. I’m not entirely sure that was the right thing to do.)

A final point, when I replaced
       eventMap.handler("XNet/Back", States::EvHideXNet());

with
eventMap.setEventType(Window::EventMouseClick);
eventMap.handler("XNet/Back", &XNet::handleClose, this);


bool XNet::handleClose(const CEGUI::EventArgs& e)
{
    OutputDebugString("XNet/Back clicked");
    GameController::instance().postEvent(TIntrusivePtr<States::EvHideXNet>(new States::EvHideXNet()));
    return true;
}

the “close” button now consistently works.


Thanks
Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#2 dteviot

dteviot

    Programming Department

  • [Xenocide Senior Members]
  • 1,479 posts

Posted 02 January 2006 - 07:42 PM

Whoops. Found:
http://www.xcomufo.c...?showtopic=7551
and
http://www.xcomufo.c...?showtopic=6878
and
http://www.xcomufo.c...?showtopic=6748

Edited by dteviot, 02 January 2006 - 07:43 PM.

Saving the world from the scum of the universe is hard work. Especially when you have to create the scum to begin with.

#3 guyver6

guyver6

    Captain

  • Xenocide Programming Department
  • 599 posts

Posted 03 January 2006 - 04:05 AM

That's not a problem of FSM, it's Ogre's input system problem. This was fixed by one of our contributors (Ogre patch), but since noone was willing to compile new ogre package when I was away, it stayed like this. Ogre Dagon has this fix too, and I have it compiled and Rincewind have ported Xenocide to use Dagon. It's all in "dagonsquirrel" branch, where we also work with Garo on python, so it's really unstable now :)

EDIT: btw, strange thing that
eventMap.handler("XNet/Back", States::EvHideXNet());
doesn't do the same job as what you did. It should do the same...

Edited by guyver6, 03 January 2006 - 04:08 AM.

Posted Image
Sourceforge: guyver6
LinkedIn: Andrzej Haczewski
"A good business idea, they say, can be explained in one sentence. Similarly, each program entity should have one clear purpose."

Join #xenocide at irc.freenode.net.