Subscriber problems

For help with anything that CEGUI doesn't offer straight out-of-the-box, e.g.:
- Implementation of new features, such as new Core classes, widgets, WindowRenderers, etc. ...
- Modification of any existing features for specific purposes
- Integration of CEGUI in new engines or frameworks and writing of new plugins (Renderer, Parser, ...) or modules

Moderators: CEGUI MVP, CEGUI Team

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: Subscriber problems

Postby CrazyEddie » Wed Aug 10, 2005 08:32

Not every update, but the Window class (and therefore all widgets), have an auto-repeat function for the mouse buttons. This will not generate PushButton::EventClicked, but Window::MouseButtonDown messages, so you'll need to adjust where required.

To enable this you need to look at the function:
Window::setMouseAutoRepeatEnabled

For this to work, you also need to be correctly injecting time pulses each update via the function:

System::injectTimePulse

HTH

CE.

User avatar
J_A_X
Quite a regular
Quite a regular
Posts: 72
Joined: Wed Jun 29, 2005 13:18
Contact:

Re: Subscriber problems

Postby J_A_X » Wed Aug 10, 2005 18:55

That's great!

but what does the time injection do and why do I need it? Shouldn't it call the method every update?

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: Subscriber problems

Postby CrazyEddie » Thu Aug 11, 2005 13:32

The time injection tells the system how long has passed since the last time injection - you need it because otherwise the functionality you wish to use will not work (nor will some other stuff, such as tool-tips).

If by every 'update' you mean every frame - if the event repeated every frame, then on some systems where you can get >1000 FPS, things would happen a bit too quickly :lol: This is why the injection system is used here, it allows the system to perform correct repeat-delat/repeat-rate timing.

User avatar
J_A_X
Quite a regular
Quite a regular
Posts: 72
Joined: Wed Jun 29, 2005 13:18
Contact:

Re: Subscriber problems

Postby J_A_X » Thu Aug 11, 2005 16:02

Well, the code I'm using doesn't really matter how fast it's updating, though the time injection might be helpful later on...

Though it doesn't seem to work properly...I don't think it is in fact getting called every update...Unless you have to have the time injection there for it to work.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: Subscriber problems

Postby CrazyEddie » Sun Aug 14, 2005 09:11

Yes, I already said this, but to reiterate...

You must inject the time pulses for the auto-repeat function to work.

User avatar
J_A_X
Quite a regular
Quite a regular
Posts: 72
Joined: Wed Jun 29, 2005 13:18
Contact:

Re: Subscriber problems

Postby J_A_X » Mon Aug 15, 2005 18:31

Well, i got that working no prob.

One thing missing now, I need a function to be called when I click one of the tab button. Is there a way to this from the tab control widget or do I have to get the window using the automatic name giving it to by cegui?

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: Subscriber problems

Postby CrazyEddie » Tue Aug 16, 2005 08:53

Well, there is:

TabControl::EventSelectionChanged

Which fires when the active tab is changed, which happens when somebody clicks the tab button.

If this is not acceptable, then you will have to obtain access to the button yourself; though as always, such low-level stuff must be classified as dangerous, and liable to break (though there are no plans in that area ;) ).

User avatar
J_A_X
Quite a regular
Quite a regular
Posts: 72
Joined: Wed Jun 29, 2005 13:18
Contact:

Re: Subscriber problems

Postby J_A_X » Tue Aug 16, 2005 14:20

I'll see what I can do about that. I think EventSelectionChanged might help. I'll just need to devise a way to find out which child has been selected and that should be good.

Though in my opinion eddie, it would be nice to be able to put a normal button event on the tab buttons themselves without going through the low-level stuff. It can be as easy as just placing a common name to it instead of the automated code.

Just my thought cause some people would like that functionality. Heck, I could probbly do it myself if I have enough time to refine the code before my deadline ;)

User avatar
J_A_X
Quite a regular
Quite a regular
Posts: 72
Joined: Wed Jun 29, 2005 13:18
Contact:

Re: Subscriber problems

Postby J_A_X » Tue Aug 16, 2005 17:40

Well, I've been using the timeinjection extensively for testing. Right now I have this in my update function:

Code: Select all

CEGUI::System::getSingleton().injectTimePulse(0.01);


When the second are anything lower than that, it doesn't work.
I want it to be lower because the auto repeat for the mouse event gets fired around every half second, which isn't 0.01 second...

Is it possible to have it fired every frame update?

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: Subscriber problems

Postby CrazyEddie » Thu Aug 18, 2005 13:14

The value you pass in should not be constant - it's a measure of time between frames. It should work fine with lower values, initial testing for this was done on the Ogre driver running at 600 FPS, which would give an interval of around 0.00166f.

You set the delay and rate for the auto-repeat via the Window class API. (setAutoRepeatDelay & setAutoRepeatRate methods).

billconan
Just popping in
Just popping in
Posts: 12
Joined: Wed May 17, 2006 14:11

Re: Subscriber problems

Postby billconan » Sat Jun 24, 2006 07:35

CrazyEddie wrote:Ok. Consider the following code, which shows one general approach. There are some additional notes at the bottom of the post.

Code: Select all

class myDemoClass_1
{
public:
    // other methods
    ...

    void assignHandlers();

    //
    // Handler methods
    //
    bool handleQuitButton(const CEGUI::EventArgs& args);
    bool handleShowWindowButton(const CEGUI::EventArgs& args);
    bool handleHideWindowButton(const CEGUI::EventArgs& args);

    ...
};

//
// code
//
void myDemoClass_1::assignHandlers()
{
    using namespace CEGUI;

    // get Window manager to save constantly getting singleton.
    WindowManager& wmgr = WindowManager::getSingleton();

    // find the quit button, and assign its handler
    wmgr.getWindow("mySampleApp/QuitButton")->subscribeEvent(
        PushButton::EventClicked,
        Event::Subscriber(&myDemoClass_1::handleQuitButton, this));

    // find the hide button, and assign its handler
    wmgr.getWindow("mySampleApp/HideButton")->subscribeEvent(
        PushButton::EventClicked,
        Event::Subscriber(&myDemoClass_1::handleHideWindowButton, this));

    // find the show button, and assign its handler
    wmgr.getWindow("mySampleApp/ShowButton")->subscribeEvent(
        PushButton::EventClicked,
        Event::Subscriber(&myDemoClass_1::handleShowWindowButton, this));
}

bool myDemoClass_1::handleQuitButton(const CEGUI::EventArgs& args)
{
    // this does not exist in this example, it's intended to
    // represent a global object where we can signal the app
    // to terminate.
    myGlobalApp.signalQuit(true);

    // signal that we handled the event, to prevent
    // possible propogation of event to other windows.
    return true;
}

bool myDemoClass_1::handleShowWindowButton(const CEGUI::EventArgs& args)
{
    using namespace CEGUI;

    WindowManager& wmgr = WindowManager::getSingleton();
    // find the window to show/hide
    wmgr.getWindow("mySampleApp/someWindow")->show();

    // signal that we handled the event, to prevent
    // possible propogation of event to other windows.
    return true;
}

bool myDemoClass_1::handleHideWindowButton(const CEGUI::EventArgs& args)
{
    using namespace CEGUI;

    WindowManager& wmgr = WindowManager::getSingleton();
    // find the window to show/hide
    wmgr.getWindow("mySampleApp/someWindow")->hide();

    // signal that we handled the event, to prevent
    // possible propogation of event to other windows.
    return true;
}


The key thing here, which some people initially miss, is the use of the 'this' pointer when creating the Event::Subscribers. Here we're passing 'this' because this is an instance of the object containing the handler functions. If your handler functions were in some other class, say 'myHandlersClass', then instead of passing 'this' you would need to pass a pointer to an instance of the 'myHandlersClass'. If you are subscribing free functions, or static member functions you do not need this object pointer at all, and can just pass a pointer to the function.



this is what i did:

Code: Select all

theMainFrame->subscribeEvent(FrameWindow::EventCloseClicked, &allOver);


bool allOver(e) is a subscribing free function.

and i got access violation.


Return to “Modifications / Integrations / Customisations”

Who is online

Users browsing this forum: No registered users and 16 guests