In Game maker... after the instance is destroyed I want there to be few seconds delay before the game moves to main menu room. I have added alarm 0 after the instance destroy and in alarm 0 i have added message box saying game over and also move to room - main menu. But that alarm is not triggering. No action is taking place after the instance is destroyed. If I don't use alarm the message box pops up before the instance is destroyed completely. What can be done about it? I would really appreciate any kind of help!
Alarm of course does not work, because you destroy the object in which is the alarm.
The easiest way - to create a new object (as an example, with the name obj_wait), in create event write:
alarm [0] = room_speed * 3;
and inside the alarm0:
room_goto (r_main_menu); // your menu room
When destroying of your object, create an instance:
instance_create (0, 0, obj_wait);
Related
I have a Qt application, where, among other things, there is a function render which goes through a list of objects and creates for each an according (subclassed) QGraphicsPathItem which it then puts as a child in a (subclassed) QGraphicsScene. (It is done in the code below through a visitor GGObjConstructor which gets initialized with the variable scene which is the scene where the items are to be added to).
XTimer timer;
timer.start();
gobjlist gobjlis = ogc._gobjectlis;
GGObjConstructor ggoc(scene, z_value, bkground_color);
for(auto obj: gobjlis) {
obj->exec( &ggoc );
}
timer.stop();
My class XTimer is used in an obvious way to measure the time for this proceeding.
Now the problem is: Only the time spent in the loop where all the items are prepared and inserted into the scene is measured by timer. For a typical example with ~165000 items this gives about 7.5 sec as timer-value at reaching timer.stop(). But the application is after these 7.5 sec still frozen, with the screen-window where the scene is to by displayed yet invisible and only after about 25 sec (hand-stopped) suddenly the display window appears with all the items to be displayed.
Now of course I would like to measure these "freeze time" (or time till the application becomes responsive again, or maybe time till display window appears). But I found no way to do this although I looked some time through stackoverflow or the net in general. The best hint I found was
stackoverflow question
The answer there seemed to imply, that it would be not really simple to achieve (overriding paintEvent method and such things).
Question: Is this true? Or is there a simple way to measure the time till the application becomes responsive again/the image is really displayed?
I had a similar problem with an application once, where I wanted to measure the time the app freezes to figure out with logging what was causing these freezes. What I came up was to measure how long the Eventloop of the mainthread was not responding, because this directly corresponds to a frozen app.
The basic idea is to not run a QApplication but inherit from QApplication and override the notify() function. Some apps do this anyway to catch exceptions which would otherwise break the eventloop. Here is some pseudo-code which should bring the idea across:
bool MyApplication::notify( QObject * receiver, QEvent * event )
{
// something like storing current time like:
// auto start = std::chrono::system_clock::now();
// auto elapsed = std::chrono::duration_cast<std::chrono::milliseconds>(start - end );
// if( elapsed.count() > 1000 ){
// log something like: Mainthread responds again after <elapsed> seconds
// }
// Note that end must be a member variable
// end = start;
return QApplication::notify(receiver, event);
}
Note 1: If your app does not continuesly run through notify() you can for testing purposes introduce a dummy QTimer which triggers faster than the logging time threshold.
Note 2: if you use multiple threads, esp. QThreads it could be necessary to filter the receiver object and perform that code only if the reciever is in the mainthread.
With this code you can log every freeze of the main-thread (frozen GUI) and determine the length of the freeze. With proper logging you can figure out whats causing the freezes.
Keep in mind that this will only log after the freeze has resolved!
Addition:
It is more complicated and slow, but for debugging/investigation purposes you can store the last event and Object-Tree of the reciever and log that as well. Than you even know which was the last event which triggered the freeze and the recieving Object.
Im having activity A.Inside that im having Fragment Fa.
In Fa im having button Bu.
When users clicks the Bu then it will start the thread.The status of progress of thread and after completing the result is shown in the activity via handler.
But when user clicks the button the thread starts and b4 completion of thread when user clicks back button means then activity/fragment closed then handler become null.
But thread runs and after completing throws null pointer for handler.
I need if user clicks back button means how to make fragment/activity will wait till thread need to complete?
The following are my configuration details
Android minimum sdk version = 4.4
I need to make a Music Player using Qt, in which the slider slides as the song progresses.
this->ui->horizontalSlider->setValue(10);
sleep(1);
this->ui->horizontalSlider->setValue(20);
I was trying things like above but could not cause it to display the changing values, as the program pauses for 1 second and only the second value(20) is displayed.
How can i achieve this?
Whatever library you use for audio playback should asynchronously notify you of progress in playing the file. You should react to such progress and update the slider. Using hardcoded delays will quickly desynchronize the slider from real audio playback, even if we forget the fact that you block the event loop.
In any modern application development framework there's generally no need ever to block a thread to sleep. If you write such code, it's the wrong approach in 99.99% of the cases.
Sleeping will block the program for 1 second. Meaning that anything going on (music playback, or any process running inside your app) will basically not work.
What will happen is that the program will set the value to 10, sleep one second (nothing will happen), set 20, and block the program for 1 second again. So basically, your program blocks all the time, and sets the slider's value every second.
The solution is to get the progress value, for example :
int total_time, current_time; //Durations in seconds
int progress; //Will hold the progress percentage
//Somehow you get the total song time and the current song timer
//...
progress = (current_time/total_time)*100
this->ui->horizontalSlider->setValue(progress);
Or :
/*When initializing the slider*/
int total_time; //Duration in seconds
//Somehow you get the the total song time...
//...
this->ui->horizontalSlider->setRange(0,total_time);
And in your routine
/* In the routine where you refresh the slider */
int current_time; //Duration in seconds
//Somehow you get the the current song timer...
//...
this->ui->horizontalSlider->setValue(current_time);
EDIT: I do not want to call the object destructor as suggested in this thread.
I have connected a button to a slot. This slot starts a process.
ui->btnActivate->setText("Start");
connect(ui->btnActivate, SIGNAL(clicked()),this, SLOT(startProcess()));
After the process finishes, I do
ui->btnActivate->setText("Close");
connect(ui->btnActivate, SIGNAL(clicked()),this, SLOT(close()));
But now the button starts the process and then run close. How can I disconnect the first connection before altering the buttons behaviour? I would like to avoid calling the Destructor
Simply use 1 of the 5 signatures of QObject::disconnect to simply remove a connection between 2 objects without destroying any of them.
Please excuse the long post. I was playing around with a simple app and wanted to save a custom object in a fragment across an orientation change. Previously within activities this used to be handled using the onRetainNonConfigurationInstance() / getLastNonConfigurationInstance() methods. Seeing as these methods are now deprecated, the documentation encourages the use of fragments and the setRetainInstance(boolean) method.
I went ahead and played around with this method and then noticed a strange difference in behaviour when it came to saving the state of the fragments across orientation change. First up, a very brief explanation of the app I was playing with:
Main Activity
Fragment A (First fragment shown on app launch)
This is a simple fragment with 3 EditText controls. Each one has an ID in the layout file. The fragment also includes a button which when selected replaces Fragment A with Fragment B and saves the transaction on the backstack.
Fragment B
This is a fragment with an empty layout. If back is pushed, Fragment A is restored from the backstack.
Scenarios
Scenario A - setRetainInstance(false):
App launches and fragment A is displayed.
I enter values into the EditText fields and select the button.
Fragment B is displayed. I change device orientation once and hit the back key.
Fragment A is displayed with the entered values (view state) intact.
Scenario A - setRetainInstance(true):
The same behaviour takes place as above
Scenario B - setRetainInstance(false):
App launches and fragment A is displayed.
I enter values into the EditText fields and select the button.
Fragment B is displayed. I change device orientation twice and hit the back key.
Fragment A is still displayed with the entered values (view state) intact.
Scenario B - setRetainInstance(true):
App launches and fragment A is displayed.
I enter values into the EditText fields and select the button.
Fragment B is displayed. I change device orientation twice and hit the back key.
Fragment A is displayed with empty EditText controls, i.e. none of the entered values (view state) still intact.
For some reason the use of setRetainInstance(true) interferes with the view state of fragment A (on the backstack) when the orientation changes more than once.
Possible Explanation
I started getting nervous about the use of setRetainInstance while not having a full understanding of what was going on, so I dug around in the support library source code to try figure it out. At a very high level, I think this may be what is going on with setRetainInstance(true):
Fragment A is displayed, button is pressed and Fragment A is replaced by Fragment B. As part of this process, the FragmentManager (FM) removes Fragment A and fragmentA.mRemoving flag is set to true.
Change orientation the first time. At this point the FM attempts to save all state of the fragments:
Parcelable saveAllState() {
...
if (f.mState > Fragment.INITIALIZING && fs.mSavedFragmentState == null) {
fs.mSavedFragmentState = saveFragmentBasicState(f);
Fragment A has a CREATED state and has a null saved state, so it qualifies to have its state saved.
The activity is destroyed as part of the orientation change. Long story short, Fragment A has its state changed to INITIALIZING.
The activity is recreated and an attempt is made to move the state of the fragments to CREATED. However, at this point there is a check in the FM moveToState() method:
if (f.mRemoving && newState > f.mState) {
// While removing a fragment, we can't change it to a higher state.
newState = f.mState;
}
Because fragmentA.mRemoving remains true from step 1 as the fragment was retained (not recreated), it does not have its state increased to CREATED but remains in the INITIALIZING state. Note that even if one presses the back key now, Fragment A will still have its state intact, as a result of its state being saved in step 2.
Change orientation for the 2nd time. Once again the FM attempts to save all state of the fragments:
Parcelable saveAllState() {
...
if (f.mState > Fragment.INITIALIZING && fs.mSavedFragmentState == null) {
fs.mSavedFragmentState = saveFragmentBasicState(f);
However, because Fragment A is in the INITIALIZING state it does not qualify to have its state saved. Hence, once orientation completes for the 2nd time, if the back key is pressed the state of Fragment A is no longer intact.
Questions
Is this behaviour expected? Perhaps this relates to the documentation discouraging the use of setRetainInstance and backstack fragments?
How should we deal with view state and the use of setRetainInstance? Perhaps my use case is incorrect, but I would be nervous using the setRetainInstance functionality with this difference in behaviour.
Once again, sorry for the long post. Feedback will be appreciated as always.