Right now, my scrollbar is made up of 3 buttons (its children). The buttons currently consume mouse down, up, click, and drag. The scrollbar then hooks into these 3 buttons and does what it wants them to do. Therefore, I do not use the new bubble-up-the-stack feature of my GUI in this scenario.
I'm still not quite clear on when I should use this and when I should listen to child events.
Is my current technique a good way to do it, or should my button instead not consume these events and receive events intended for the buttons and do stuff based on that?
Thanks
In this case the 3 buttons (I presume up, down, and slider) don't have enough information to do anything on their own; the best they can do is interact with the main scrollbar control and tell it what modifications it should make. In that case it might just be cleaner to have the scrollbar do all the message processing itself. It already needs to deal with things like arrow keys, correct?
Related
I have an odd problem here.
I'm working on an application, and within one of my classes I'm monitoring my mouse events.
The weird thing is, my mouse move event will only get called if any mouse button is pressed.
I'm not even filtering for any button presses within the method; the method itself doesn't even get called unless I click on this object itself (the one that's monitoring it).
What generally causes this type of error to happen?
I'm not sure if it's relevant, but I have 2 different things monitoring my mouse inputs: 1) the main program monitoring the global mouse coordinates, and 2) an object within my program monitoring the mouse coordinates within itself.
Edit
So the problem has to be because mouse move event is generally used when people are dragging the cursor along the screen right?
My reason for not needing it like that is because I'm building a custom context menu of sorts, and I need to know when an item is hovered over.
It turns out that I didn't truly set everything within my class to enable mouse tracking.
I somehow thought if the class itself was set to have it enabled, I wouldn't need to set it to all the sub objects, but now I see how that wouldn't make any sense at all.
So just to clarify my solution:
The items that I needed to track my cursor's position needed to have
setMouseTracking(true);
I'm making my first game in Irrlicht (C++), an RTS with mouse control
and when you select a tile (by clicking on it) it lights up and some gui button appear on the screen (not in a gui window mind you, I like it this way):
http://i1139.photobucket.com/albums/n549/Adam_Halley-Prinable/Untitled2.png
However, since i switched to mouse control, the buttons wont register my mouse clicks. The click goes straight through the button and selects the tile behind instead:
http://i1139.photobucket.com/albums/n549/Adam_Halley-Prinable/Untitled3.png
Is there a way I can say "Buttons get top priority for clicks"?
I'm using MyEventReceiver, which i've messed around with to accept mouse clicks and that.
Thanks a bunch :D
If anyone else has the same problem, ill tell you how I solved it :)
Go through the MyEventReceiver.h and get rid of all the "return true;"'s in the mouse section.
Don't ask me why, but it works, and appears to have no side effects. Make sure you leave the "return false;" at the end of the section there.
Your event receiver fires before the GUI gets access to the event, if you want to pass it to the GUI then you can do this by manually posting it to the GUIEnvironment in your event receiver.
if (guienv->postEventFromUser(event))
return true; // abort because the gui wanted it
// .. pick nodes
// possibly post event to scene manager
return true; // remember to return true so gui/smgr don't get the event again
For my Gui I want to use the following system:
The way it works is that, if the widget under the mouse does not consume a mouse or kb event, it is passed to that widget's parent until it is consumed or the desktop is reached.
Just one thing puzzles me about it. Does that mean if a Button, for whatever reason has a Label as one of its children. If I click the label, would that not mean that my button, which is under the label would click (since a label does not consume the mouse), which is undesired in this case. Does that mean I'd have to do if(mouseEvent.source == this){do button stuff} ?
Thanks
If the label is a child widget, then yes, the label will attempt to eat the event, fail (as usually the label doesn't have a handler method) and thus pass the event back up to the button.
Chances are the easiest way to do this is to derive a subclass of the Label class, and override the handle function (assuming this is possible in your toolkit - which it should be in any decent toolkit). You can then use your handle function to capture mouse clicks, and pass any other event back up to the button.
Comparing pointers is probably a bad idea and is slightly dependent on the way the toolkit is implemented - for instance, it might deem the source as the button (because that's what it expects), not the label.
Though I find it highly strange that a Label is a widget in itself.....
It looks like you need a special kind of "Label" which consumes mouse events. You should be able to create a customized widget (derived from Label) that consumes mouse events for this specific case.
If that Label widget is from a third party that cannot be derived/subclassed, you should wrap the Label in another widget: A simple widget that consumes mouse events and has only one child, the original Label.
Here is the problem:
The way the GUI system I'm using works is as follows:
A widget can listen to mouse events. The listeners can consume an event they are listening to and as a result, the widget they were listening to will not receive the event, even if it was intended for them, only the listener will have received it.
The problem comes in here:
A scrollpane has a ListBox inside. The listbox can be scrolled. The Scrollpane can also be scrolled. What happens right now is when I mousewheel and the widget under the mouse is the listbox, both the listbox and the scrollpane move. The only solution I see is that the scrollpane consumes all mousewheel events, but then there is no way for the ListBox to ever be scrolled.
The behavior I desire is for the ListBox to scroll when it has focus, but if I did this, it would not work because for example if a radio button inside the scrollpane is focused, I still want the scrollpane to scroll, it is only for widgets with scrollbars such as textbox and listbox where this is not desired.
Thanks
Also, the gui system I'm using is my own which I'm developing.
The usual way to deal with this is that the ListBox only consumes the event if it actually scrolls. If you place the mouse in the listbox and use the scrollwheel the listbox scrolls until it reaches its scroll limit. After that further moves of the wheel cause the scrollpane to scroll.
Obviously there are variants on that - the important thing is to decide what you actually want to happen.
You also need another way of scrolling the scrollpane, so that if the user explicitly wants to scroll it they can, without having to scroll to the end of the ListBox. Scrollbars on the ScrollPane would be one way. You should also make sure there is a way of scrolling the ListBox without using the mouse wheel.
I have two questions:
How to hide cursor for all programs? I tried to hide the cursor by using
ShowCursor, but it only works in my program. The cursor still appears when moving
cursor outside of my program.
How to disable mouse operations for all programs? I use SetWindowsHookEx to hook mouse and prevent other programs to processing the mouse operations. I can hook the clicks, but the problem is that I can't hook the "move". When I move the mouse to menu or system buttons ("minimize/restore/close"), they are highlighted. This means they can still "see" the mouse.
Can anyone help me please?
I shudder to wonder what you are trying to do, but the easiest way to do this, assuming you have an otherwise well behaving application, is to use SetCapture and ReleaseCapture when your app has a window in the foreground. You can also use ClipCursor(RECT *) to ensure that the cursor stays in a window under your control.
You can use SetCursorPos to keep the cursor centered in your window. Please, don't hide my mouse cursor, it's not yours.
Hiding the cursor globally is difficult. You can create a fullscreen, transparent window and use ShowCursor on that, but of course it will also receive all mouse events then. Maybe it works for your particular case, though, since you also want to disable mouse input.
You can use SetWindowsHookEx with a WH_MOUSE_LL hook to disable mouse movement. If you return a nonzero value from your hook procedure, the mouse cursor will stay put.
All that being said, it does sound like you're trying to do something evil, or at least something your users might not like. I would advise to think twice whether this is really what you need.
The only legitimate reason (that I can imagine) for this would be to make a "kiosk". If that's your goal, search for, or re-state the question as a Kiosk question.