How does one find out when an action is complete or when a sequence of actions is complete?
I have a bunch of sprites with different actions depending on the state of them, and when e.g. the sprite is pressed and the state is e.g. state1, then some code should execute. if the sprite is pressed during the execution of cocos2d behind the scenes, then the next state is triggered.
I need to know when the first actions are complete so that I can then "unlock" the sprite and allow for further touch detection.
How do I check if the sequence is done?
Thanks
If you're using CCActions, which it seems like you are, then you can just use CCCallFuncN. It looks something like this:
id doneAction = [CCCallFuncN actionWithTarget:self selector:#selector(yourMethod)];
Just add that to the sequence of actions you're running and it will call 'yourMethod' when they get done.
Related
I'm having a hard time with GLFW's input system, figuring out how to make it work the way I want it, so I've come to people with more experience for wisdom. Using GLFW 3.
There are 3 states 0 Release, 1 Press and 2 Repeat. This is exactly what I would want, only, the key state from Press to Repeat takes about a second to change. Ideally, I would want it to have a state "Press" only for 1 frame, and then change into a repeat state.
The goal: Be able to easily call functions based on what state my key is as follows:
press Tap (do once)
repeat Continuous (do every frame)
release Don't respond
LINK
Please have a look in the files on the link above, and let me know if there's another way around it. Or is the approach itself rubbish, the way I do it? Thanks guys, all feedback and help appreiated.
One way is to simply ignore the "repeat" event, and only go with the "press" and "release" events.
When you get the "press" event set a flag, and clear the flag on the "release" event. Then simply check this flag every frame.
It is very important that there is a delay between "press" and "repeat". Most human beings are incapable of pressing and releasing a key, such that your game only registers the key being pressed for exactly one frame. And the few who are capable of that cannot do so consistently, with any accuracy.
So a user will never be able to "do once". They will be doing it for multiple frames. That's generally bad.
Also, there is a conceptual difference between pressing, holding, and repeating. Holding is just what happens when you hold down the key. Repeating is a facility that is governed by the OS (which is why GLFW doesn't give you a way to set the repeat rate). Key repeating is typically meant for text input (which GLFW takes care of for you anyway via its text-based callback).
Essentially, you should ignore it. In a game situation, a key has 4 possible useful states: not pressed, was just pressed, being held down, and was just released. You can infer this from the button's previous state (which you can store) and the button's current state provided by the callback.
If all you want to do is take an action when a button "was just pressed", then you need to know that the button was not pressed in the previous frame. If the key is pressed now but not in the previous frame, take the action.
In the documentation of Ember.StateManager it's said that : "Inside of an action method the given state should delegate goToState calls on its StateManager". Does it mean that if I send an action message, I necessarily need to transit to another state. Is it possible to stay in the same state but doing some task by sending an action ? For example, I'm in a state "loading" and I run two actions "preprocess" and "display".
Very simply: an action message may but does not have to transition to another state.
Something you didn't ask, but is related and important: it is a bad idea and bad design to call goToState in an enter or exit method.
When dealing with statecharts in general, you can do whatever you want. It's not mandatory to switch states in an event handler. A common case would be an event handler that shows a cancel/save dialog. You can easily put the dialog on the page in the event handler, and proceed accordingly depending on which button is pressed.
A separate question is should every event handler basically just go to another state. In the above scenario, you can certainly go to a "confirm" state, the state-enter method will show the dialog, and there would be two handlers, one for each button. Those handler would in turn go to other states.
Both design choices I think are equally valid, at least in that scenario. If you choose to implement a separate state for every action, you will end up with a lot of small but concise states. If you choose to do stuff in the event handlers themselves, your states will be bigger, but there will be less of them.
One thing I will say is if an event handler is getting complicated, you are probably better of with a new state. Also, be consistent.
For you specific scenario, if I'm reading it right, you want to load data and then change the display to show the data, based on an event. In this case, I would use new states.
So you press a button that starts the process
In the event handler, go to some sort of 'MyDataSection' state
Initial substate is 'loadData'
Enter state method of 'loadData' starts the loading process
Event handler 'dataLoaded' in 'loadData' to handle when the data loads; this means you need to fire an event when the data loads
'dataLoaded' event goes to the 'show' state
show state shows the view (or removes activity indicator etc) and handles any events that come from the display.
What's good here is that if you have multiple ways to get to this section of the app, all actions that lead to this section only need to go to this state, and everything will always happen the same. Also note that since the view event handlers are on the show state, if the user hits a button while the data is loading, nothing will happen.
Hey guys ... Well I'm experiencing this silly problem that whenever I perform a double click event, two mousePressed events are also triggered, meaning that mousePressed event code is also executed twice for no reason .. How can I configure the event such that first the clicks are checked for doubleClick event, and only if this is NOT true, they move on to mousePressed events .. ? Is this possible ?
Before you spend too much time trying to figure this out, consider what Raymond Chen has said about the "Logical consequences of the way Windows converts single-clicks into double-clicks". The techniques he talks about should be easily adaptable to Qt. But also the UI consequences of the "dubious design of having the double-click action be unrelated to the single-click action" - you may be trying to do something that will be confusing to your users (on the other hand - you might trying to prevent something from confusing your users).
Also, the related article, "Why doesn't double-right-click bring up the Properties dialog?" might be of interest.
I'm going to assume you mean for the same widget. The quick and dirty way would be to move the mouse press code into a private method, have the mouse press event set a timer to go off after the expire timer for a possible double click. In the double click code be sure to turn off the timer if it gets called. This will prevent the mouse press event from running twice. In the timer code, have it call the private method.
Basically, when one types, a keydown event happens. If the key is held for more than a certain time (~1 sec) then the key is repeatedly pressed until keyup hapens. I would like to change the time it takes for the key to be automatically repressed in my c++ application. How can this be done?
Thanks
The speed at which a keypress becomes automatically recurring is controlled by Windows.
If you want to manipulate automatic recurrences of key-presses, it might be more advantageous to poll for the state of the key rather than waiting for the keydown event. It depends on how responsive you need your application to be.
This article may help you in figuring out how to query for key states: link
You can use the SystemParametersInfo function to change the keyboard delay and refresh rate, as described in this newsgroup thread.
A simple way to handle this is to establish a buffer of time around the OnKeyDown event. Setup a timer that determines whether control passes to a secondary event handler. If the timer has expired, then it is OK to pass control. If the timer hasn't expired, then you should return and leave the event unhandled. Start the timer right before passing control to your secondary event handler.
void KeyDownHandler(...)
{
// ...
if (TimeLeft() <= 0)
{
StartTimer();
handleKeyDown();
}
}
A timer is better than counting duplicate events because you can't assume that a given system will have the same repeat rate set as yours.
I agree with Stuart that polling for the state of the key might work better. It depends upon what you are trying to accomplish.
Also note that this type of behavior might be highly annoying to your user - why do you need to ignore duplicates?
You might be able to tap into a Windows API but this might be controlled by the OS. Not sure...
You might need to manually draw a command such as to simulate a key press multiple times after a set number of seconds after the key has been pressed.
Use SetKeySpeed api (Kernel)
Okay, using Qt, I'd like to know how to detect the current state of the mouse at any point in time - without a MouseEvent.
Using QCursor::pos(), you can get its position, but is there a way to determine the current state of the buttons?
Basically, I'm looking to verify the state of the mouse when a timer goes off, so it won't be related to any particular MouseEvent, and so there's no MouseEvent to query. I need to know how to query for the mouse's state - in particular the state of the buttons - without having a MouseEvent.
Oh, and I'm using Qt 3, so if such a function has been added in Qt 4 but isn't in Qt 3, it doesn't help me much (though it would still be nice to know about).
Qt::MouseButtons QApplication::mouseButtons () [static]:
Returns the current state of the buttons on the mouse. The current
state is updated syncronously as the event queue is emptied of events
that will spontaneously change the mouse state (QEvent::MousePress and
QEvent::MouseRelease events).
It should be noted this may not reflect the actual buttons held on
theinput device at the time of calling but rather the mouse buttons as
last reported in one of the above events. If no mouse buttons are
being held Qt::NoButton is returned.
Edit: hmm, I just noticed you asked about Qt3.3. This answer applies to Qt4 I'm afraid.
Is it a hard requirement that you don't use MouseEvent? Or can you use MouseEvents indirectly?
If you create a boolean variable for every button and update it with mouse pressed / released events then you could just look at the values of the relevant booleans when the timer goes off.
Update for Qt5 (5.3.2):
if (QGuiApplication::mouseButtons() == Qt::LeftButton) { ... }
I am using a QApplication, but there is no mouseButtons() function there. You will need to include <QGuiApplication>