Launching a dialog when the application starts

[Uriah Eisenstein]

Hi all,
I want to launch a dialog when my application starts. It is a standard S60 application based on CAknViewAppUi. I'm working with S60 3rd Edition, FP1.
There are two reasons for this dialog: normally, I want a login form. Moreover, for Symbian Signed test (CON-02) I want to display a Privacy Statement dialog.
Initially, I've tried launching the login dialog from the AppUi ConstructL method. I've found that if it is a waiting dialog, there's a serious bug: if I switch to another application while the dialog is still displayed, then return to my application, the CBA of the dialog is replaced by that of the application - but the menu is disfunctional, the dialog handles all keypresses except the softkeys, and the only thing I can do with the application is close it from the Task List.
I've partially solved this by setting a very short timer from my ConstructL, which will launch the dialog after construction is finished. However, if I switch away from my application very quickly after starting it, I face the same problem.
Now I've started working on a Privacy Statement displayed in a CAknMessageQuery dialog, and found that even if it is non-waiting I still encounter a similar problem. In this case the dialog is simply dismissed by pressing any key, and then the application is operational. However, this doesn't allow me to get any input from the dialog, since the CBA is again the application CBA ("Menu" only). (I want input from this dialog in order to allow the user to have it not displayed again).

I've searched around but found mostly stuff about auto-starting application on boot...
So, is there any better place or method to launch a dialog immediately when an application starts, without bugs? ;) There should be, at least for those Privacy Statements...

P.S. While at it, if anyone has any idea how to add a "don't display this message again" checkbox to the dialog, it'd be sweet :)

Thanks in Advance!
Uriah

[pbmau]

Hi Uriah....I was in exactly the same position then I figured out you could do this in the main apps 'activate' event..i.e

AppUi::HandleForegroundEventL(TBool aForeground)

is called when the app gets and loses focus, you could do it here, just have a flag so that any subsequent getfocus events are not processed.

hope this is helpful )

[Uriah Eisenstein]

Thanks, I think I've actually tried it long ago and encountered the same problems... Possibly the first HandleForegroundEventL is called from the same context as ConstructL. But maybe it's changed on 3rd Edition, I'll try when I have time.

[Nitin SuperByte]

yeah... u may use ur form in starting of ur application.. for this just call ur form in ConstructL() of CUrAppUi.cpp.

CUrForm* iUrForm=CUrForm::NewL();
iUrForm->ExecuteLD(R_UR_FORM_DIALOG);

[mrtj]

Hi, did you find any solution for this problem? I experienced with asynchronous callback to be sure that AppUi construction is finished, CAknForm, HandleForegroundEventL, nothing helps: if application is in the background no kind of dialog is displayed, the application is dimmed but the softkeys are from the application.

[flokrates]

I had the same issues as described in this thread and finally found a solution for this problem. The trick is to use an asynchronous callback in order to create the dialog on startup from the correct context. Well, here we go:

Add following to your AppUi or View header file, whereever you like:

// Creates and runs the dialog.
TInt OnShowDialog();

// Invoked by async. callback. Forwards call to "OnShowDialog" to get out of the static class scope.
static TInt StaticOnShowDialog(TAny* aPtr);

// Asynchronous callback (CActive, one-shot).
CAsyncCallBack* iAsyncCb;

In the implemenation you have to do following on startup of your AppUi/view:

TCallBack cb(MyClass::StaticOnShowDialog, this); // We're passing the "this" pointer here, we'll use it later in the static callback.

iAsyncCb = new (ELeave) CAsyncCallBack(cb, CActive::EPriorityStandard);

// Enqueus the callback in the active scheduler.
iAsyncCb->CallBack();

The active scheduler will enqueue the asynchronous callback and invoke the class method "StaticOnShowDialog" of your class from the proper context:

TInt MyClass::StaticOnShowDialog(TAny* aPtr)
{
    // The given pointer is the object pointer to MyClass, so we can cast it safely.
    return static_cast<MyClass*>(aPtr)->OnShowDialog();
}

Finally, in the method "OnShowDialog()" you can create your dialog:

TInt MyClass::OnShowDialog()
{
    // Create and run the dialog ...
}

flokrates

[Uriah Eisenstein]

Thanks a lot for the detailed answer! I'll be sure to try this when I have time :)

[Uriah Eisenstein]

:-(
It didn't fix what I needed... The Privacy Statement dialog still got the wrong CBA.
Oh well, at least it can be dismissed by pressing the navigation key.
The login form I simply don't display if in the background, to avoid that bug.
Thanks everyone...

[mrtj]

Currently I hold the dialog in a member variable of the AppUi and at each foreground (and dynamic layout change) event I delete the dialog and immediately re-create it. It seems this is working, at least in the 90% of the cases (the remaining 10% I still don't understand but decided it'll be good enough :))

[amitkankani]

Well I am using dialogs (custom though) and not facing any problems...

But I would think, form as the best way to do it. After app launch and (splash if any), you switch to the form and show this form, with check boxes and text field carrying the privacy statement.
This shouldn't be a problem !

[Uriah Eisenstein]

I think I need to emphasize the problem: it is not that I can't display a dialog at startup, it is that the dialog softkeys (CBA) get messed up in a specific scenario. This did happen to me with a form as well.

Any of you who is launching a dialog at startup can try this - if you're just launching it from the AppUi ContructL, switch away from the application while the dialog is displayed. When you return to the application, it will display its main view CBA (e.g. Options/Back) instead of the dialog's CBA, and the menu won't function properly.
When I'm launching the dialog from a callback (e.g. a timer) rather than ConstructL itself, the bug can still be reproduced by starting the application and quickly pressing the End key, before the application screen is actually displayed.

BTW I'm running the form using ExecuteLD and Privacy Statement dialog with RunLD, both of them are non-waiting but as I've mentioned in my initial post this doesn't seem to have an effect.