React on right clicked mouse Events [solved]

[JoseMan]

Hi dear Community,

I want to react on a right mouse click on a window.
But how it can be realize?
Normal (left clicked mouse events) I implemented like this:

Code: Select all

   
CEGUI::WindowManager::getSingleton().getWindow((CEGUI::utf8*)windowStr->subscribeEvent(Window::EventMouseClick, Event::Subscriber(&OtherDialog::aHandle, this));


But how I realize "Left-Click-Mouse-Events".

CEGUI Version: 0.7.1
I use C++ & VS2008.

[Jamarr]

You really need to search the forums and main docs before asking these types of questions. They can be answered using simple logic and reasoning, skills you should have developed by the age of 12. I don't mean to offend, but when the answer to your question is already available and you ask it anyway, it insinuates that you feel your time is more valuable than those of us who actually offer help to others via the forum. In most cases, these threads will go completely unanswered. But since I am feeling generous today...

Here is what you know 1) you are subscribing to a mouse-based event (EventMouseClick), 2) this signature of the function handling the event (OtherDialog::aHandle) must take a reference to an EventArgs object, and 3) you want to know how to determine if the right button was pressed.

So, from these pieces of information you can use the Main Docs to deduce the answer. First, take a look at the Class Heirarchy. From here you can see an object called MouseEventArgs being subclassed from EventArgs. Looking at the MouseEventArgs object, you can see that it has a member called button that is typed as a MouseButton enum. Looking as this enum, you can see an item called RightButton.

So, now that you know where the information is, you just need to access that information from within OtherDialog::aHandle. Since you already know that MouseEventArgs derives from EventArgs, you can presume via reasoning that you should cast the EventArgs object you receive to an MouseEventArgs object, and then access the button member to determine which button was clicked. Ex:

Code: Select all

bool OtherDialog::aHandle(const CEGUI::EventArgs& e)
{
   const CEGUI::MouseEventArgs& args = reinterpret_cast<const CEGUI::MouseEventArgs&>(e);
   if (args.button != CEGUI::RightButton)
   {
      return false;
   }
   ...
}


Now that wasn't so difficult, was it....

[Jabberwocky]

when the answer to your question is already available and you ask it anyway, it insinuates that you feel your time is more valuable than those of us who actually offer help to others via the forum.

True, well-said, and funny all at the same time.

[JoseMan]

Thank you very much...
So, in one sentence:
MouseEventArgs is subclassed from EventArgs.
Now I am happy.

And I don't think my time is more valuable.

Bye JoseMan

[CrazyEddie]

I actually think this is something else we could clarify in the docs, because this issue come up quite often[1] - so I think a tutorial or some other introduction document would pay off here.

CE.

[1] I have deliberately did not rant about how the fact that it comes up often should therefore make it easier to search the info At least with it fully documented, we'd have a bigger stick to hit people with

[JoseMan]

...........
..........

Code: Select all

bool OtherDialog::aHandle(const CEGUI::EventArgs& e)
{
   const CEGUI::MouseEventArgs& args = reinterpret_cast<const CEGUI::MouseEventArgs&>(e);
   if (args.button != CEGUI::RightButton)
   {
      return false;
   }
   ...
}


.....

So, still one question:
Why you use the reinterpret_cast and not dynamic_cast?
The reason why I ask:
I made a own class MyWindow which is derived from CEGUI::Window.
When I try to do something like this:

Code: Select all

MyWindow* myWin(dynamic_cast<MyWindow*>(CEGUI::WindowManager::createWindow("Vanilla/StaticImage","MyWindow")));


myWin is NULL.... ?!
Can you say whats the reason for this?

Bye JoseMan

[CrazyEddie]

The reason dynamic_cast returns a zero pointer is because the CEGUI::Window returned from the createWindow call is not an instance of a class that is-a 'MyWindow' (this is pretty basic C++).

[Edited for clarity]

Basically: static_cast uses the 'static' model - it's done at compile time and assumes you know what you're doing. dynamic_cast uses the 'object' model - it's done at run time and checks to make sure the target class is valid for the object instance being cast, if not it returns 0.

From the above, you can see that a static_cast would work in your example, though would be likely crash if you tried to use the object as a 'MyWindow' instance, because it's not a 'MyWindow' instance.

HTH

CE.

[JoseMan]

....
....
HTH
CE.

Okay...
What you had said sounds logic.
Ok, If I try to do this:

Code: Select all

MyPushButton* myButton(dynamic_cast<MyPushButton*>(CEGUI::WindowManager::createWindow("Vanilla/Pushutton","MyButton")));


and MyPushButton is derived from CEGUI::PushButton it will works, I mean myButton is not NULL ?
If I'm right, its possible to make the same with a Vanilla/StaticImage?

Bye J..

Mayby I have to read the WHOLE documentation;

P.s.: Sorry for my english

[CrazyEddie]

Well, no this probably will not work either. The point being that the particular object instance that is being returned from the WindowManager is probably a CEGUI::PushButton, not a MyPushButton; just because you derive a subclass from PushButton does not magically make every PushButton an instance of the MyPushButton class.

In order to get instances of MyPushButton out of WindowManager you have to register that new class with the system and make a scheme mapping that uses it.

For example, if you give your MyPushButton class a static String variable named WidgetTypeName, you can use the templatised system to register your class, so you might have this as the class:

Code: Select all

class MyPushButton : public CEGUI::PushButton
{
public:
    //! This will identify this class within the system
    static const CEGUI::String WidgetTypeName;

    MyPushButton(const CEGUI::String& type, const CEGUI::String& name) :
        CEGUI::PushButton( type, name )
    {
    }
};

// define static data
const CEGUI::String MyPushButton::WidgetTypeName( "MyWidgets/MyPushButton" );

Now to register this with the system so instances of "MyWidgets/MyPushButton" can be created you do:

Code: Select all

CEGUI::WindowFactoryManager::addFactory< CEGUI::TplWindowFactory<MyPushButton> >();

Then if you take the vanilla.scheme file and change this line:

Code: Select all

<FalagardMapping WindowType="Vanilla/Button" TargetType="CEGUI/PushButton" Renderer="Falagard/Button" LookNFeel="Vanilla/Button" />

to

Code: Select all

<FalagardMapping WindowType="Vanilla/Button" TargetType="MyWidgets/MyPushButton" Renderer="Falagard/Button" LookNFeel="Vanilla/Button" />

Now whenever you create a "Vanilla/Button" the actual type of the object returned from the WindowManager will be a MyPushButton and the dynamic_cast will succeed.

HTH

CE.

[JoseMan]

Ahhhh,

thank you very much, I become to understand the technique of CEGUI.
I will try this at home.

Btw:
I think not I'm a stupid noob programmer but some techniques I don't know.
Mayby you can give me some keywords that help me to understand this technique.

Bye ...

[CrazyEddie]

I think not I'm a stupid noob programmer but some techniques I don't know.

It's my belief that this is true of us all; we are all on this journey and nobody can ever truly "know it all" - there are so many things still to learn, to try out and to try and understand. This is what keeps it interesting for me, and If ever I get to the point where I feel this is no longer true, I know that is the point where I should hang up my guns

Mayby you can give me some keywords that help me to understand this technique.

The specific technique we use in CEGUI (i.e. that described above) is pretty much just what things have evolved into over time, as opposed to a choice of some existing design pattern or idiom. Having said that, if we split the whole thing up a little, we can get to some common patterns. Much of the window creation system is an example of the Abstract Factory - which allows creation of specific classes that the system knows nothing about - thus making it extensible at runtime (this is used not only for WIndow based classes but also WindowRenderer classes and in SVN for RenderEffects too). The way we basically combine Window based classes with a WindowRenderer (and RenderEffect) to create the illusion of a single type could be considered an application of a Decorator pattern.

CE.

[agamemnus]

Here's a similar idiot-type question.

I see that "pushed" is the Falagard state for "a button is left-clicked", but what is the state for "a button is right-clicked", and/or would there be a way to make my own state?

[CrazyEddie]

"Pushed" is the state when the mouse is within the button's hit-test area and the left mouse button is held down after the left mouse button was depressed while within the button's hit-test area. There is no similar definition for other buttons. To add such definitions would require either an alternative WindowRenderer class for the widget or in extreme cases a complete new widget class.

CE.