hi,
I use CDirectScreenAccess in my application, so is it necessary to implement CCoeAppUi::HandleForegroundEventL, when I implement MDirectScreenAccess?
Re: Is it necessary to implement CCoeAppUi::HandleForegroundEven
You shouldn't have to, with correctly used DSA.
On AbortNow you have to abort all timers, and set flags so that any already expired timers don't generate a frame.
You will get AbortNow as soon as the visibility change of the window you observe.
If the window is still visible after the change, or when the window becomes visible again, you will get Restart, and then you can get the updated visible region and restart your timers.
Be advised though that HandleForegroundEventL could still be useful in a DSA app (since they don't mean the same thing... You could for example have a non-DSA view too in your app, if you switch to it, then you would get AbortNow, but still be in foreground), but to control any direct screen rendering, you shouldn't have to use it.
I am not sure I get your idea, the HandleForegroundEventL responses to the application, and the AbortNow and Restart just response to one of the views of the application. So if another app is brought to foreground where the DSA view is active, the AbortNow and HandleForegroundEventL are all called.
Re: Is it necessary to implement CCoeAppUi::HandleForegroundEven
Yes, in that case both would be called.
The case I was talking about was a case when a non-DSA view was showing, and another app is brought to foreground.
Then you would only get HandleForegroundEventL, even if another of your views in the same app is DSA
It was simply an example of the fact that AbortNow and HandleForegroundEventL really is two completely different concepts, and that you _could_ have use for HandleForegroundEventL, _even_ if you have implemented AbortNow, since they don't mean the same thing...
Not saying that you always will have.
Your DSA handling, and other rendering handling, should be within AbortNow/Restart, but if you have something you need to do when your app loses or gains focus, that isn't related to DSA or screen rendering, then it is probably useful to keep it in HandleForegroundEventL instead of makeing your DSA code even more complicated.
Forum posts: 1134
You shouldn't have to, with correctly used DSA.
On AbortNow you have to abort all timers, and set flags so that any already expired timers don't generate a frame.
You will get AbortNow as soon as the visibility change of the window you observe.
If the window is still visible after the change, or when the window becomes visible again, you will get Restart, and then you can get the updated visible region and restart your timers.
Be advised though that HandleForegroundEventL could still be useful in a DSA app (since they don't mean the same thing... You could for example have a non-DSA view too in your app, if you switch to it, then you would get AbortNow, but still be in foreground), but to control any direct screen rendering, you shouldn't have to use it.
Forum posts: 14
I am not sure I get your idea, the HandleForegroundEventL responses to the application, and the AbortNow and Restart just response to one of the views of the application. So if another app is brought to foreground where the DSA view is active, the AbortNow and HandleForegroundEventL are all called.
Forum posts: 1134
Yes, in that case both would be called.
The case I was talking about was a case when a non-DSA view was showing, and another app is brought to foreground.
Then you would only get HandleForegroundEventL, even if another of your views in the same app is DSA
It was simply an example of the fact that AbortNow and HandleForegroundEventL really is two completely different concepts, and that you _could_ have use for HandleForegroundEventL, _even_ if you have implemented AbortNow, since they don't mean the same thing...
Not saying that you always will have.
Your DSA handling, and other rendering handling, should be within AbortNow/Restart, but if you have something you need to do when your app loses or gains focus, that isn't related to DSA or screen rendering, then it is probably useful to keep it in HandleForegroundEventL instead of makeing your DSA code even more complicated.
Forum posts: 14
Thank you very much!