CEGUI (Crazy Eddie's GUI) Forums

Hi, I want to do a code that when mouse arrow is hover a cegui button, button1 for example, button2 and button3 became in mouse hover state to, even mouse arrow is not over them.

I thought in something like fireEvent(), but is not working.

How can I do that?

Thanks for help

You can't set the "mouse hover" state for a button explicitly, unless you were to move the mouse cursor position; two buttons can't have the mouse hover state simultaneously, since that would leave the widgets in an inconsistent state.

Thanks for your reply CrazyEddie. In this case, what should I do? I have to change the image of some specific buttons when mouse is houver one specific button.

Thanks for help

Ok. I have thought about the situation a little, and the best solution I could come up with so far was to have your skin use properties (via PropertyDefinition and ImageProperty) for the images to be drawn. Using these properties you can then change the appearence of other buttons by setting the appropriate images in response to the mouse entering some other button.

So in the WidgetLook you might define the property:


Within the ImageryComponent you could use this like so:


Then in your code, in response to the mouse entering some other button, you could do:


Obviously you would also have to fill out this to include any other images that form part of the button imagery (and also add code to re-set those images as required).

CE.

I obtain to use ImageProperty in ImagerySection of the FrameComponent type?

CrazyEddie wrote:You can't set the "mouse hover" state for a button explicitly, unless you were to move the mouse cursor position; two buttons can't have the mouse hover state simultaneously, since that would leave the widgets in an inconsistent state.

I agree ultimately that - in the code - a person should be setting whatever property of whatever widget(s) to change how they need, but I don't see why you would call it an inconsistent state.

A state is consistent if it does what is expected. The trigger doesn't matter, although you might get hooked on the naming conventions [hover implies a mouse is hovering over it, but in reality, an apple is an apple, and a state is a state]. The point I'm making is that the trigger is not connected to the state: we define the trigger to cause whatever transition.

It makes just as much sense for a a button to be in the hover state every 5th sunday as it does for it to be when the mouse moves over it. I think it would be neat to see widget->SetState(...).

There's a difference between a display state and an internal state.

When the internal state is hover then the display state is change accordingly, as well as activating the tooltip system; when the mouse hovers over a window its tooltip is displayed/shown if the mouse remains there for some time and hidden when the mouse moves.

If you monitor the ??mouse enters/hovers my window?? event then you can respond by changing the visual representation of your window, the so called display state. However the internal state of the window remains consistent with the other parts of Cegui, mainly the tooltip system.

Hope this is clear.

Rackle wrote:There's a difference between a display state and an internal state.

When the internal state is hover then the display state is change accordingly, as well as activating the tooltip system; when the mouse hovers over a window its tooltip is displayed/shown if the mouse remains there for some time and hidden when the mouse moves.

If you monitor the ??mouse enters/hovers my window?? event then you can respond by changing the visual representation of your window, the so called display state. However the internal state of the window remains consistent with the other parts of Cegui, mainly the tooltip system.

Hope this is clear.

I understand this, however, CE implies that the display state is the priority, although he hints at it being the internal state. To say having two mouse hovers creates an inconsistent state is silly, because internally, you can do whatever you want if you program for it. It is only consistent because of the visual link to that state. If you create an event "EventActivateOther" it doesn't create an inconsistent state because...you programmed for it. Again, it is only inconsistent because you let it be.

And you shouldn't be programming the core of the system to make some other aspect ( that uses the core ) work. If you have to build your events in such a way to make tooltips work, that just means the tooltip is built wrong, I would think...yeah?

edit: Bah, I followed this link from another thread, saw my post, and thought I had just forgotten about a post I had made. Then I checked the dates =p Oh well, hehe, the point remains =p