splash screen basics knowldge needed

I want to make a splash screen for my application. I do not know where to put the jpg file. I have copied it to gfx folder in carbide.But what path shoul I give to open the jpg file. eg. _LIT(KtxMySplashImage,"\\private\\<My SID>\\splash.mbm" );

Basically the path depends solely on how you would want to store it. So indeed it is good idea to have them in your private folder, and in that cae you can use same path as you show already there. Do note though to determine the drive on runtime, as well as , do remember to add all required files into your pkg file as well.

I have little doubt. by private folder-> does it mean this path
C:\S60\devices\S60_3rd_FP2_SDK_v1.1\epoc32\winscw\c\private
1>I have to copy my jpg file there?
2>Then I have .jpg file. Where do I get splash.mbm? or can I use splash.jpg?
3> If I copy it there, how I will deliver the app? do I need to create the image in the same path in phone after installing the app?the deliverables may not have the image there? I need the image to be embedded in the app. but after writing this I feel that I am going wrong somewhere in my understanding.
4>what is <MySID> in the path?I guess it is UID3 in mmp file?

You can get some code pieces from [url]http://www.developer.nokia.com/Community/Wiki/Splash_screen_with_image_using_Symbian_C%2B%2B[/url], though the article does not contain a complete application.
Your private path is the \private\<SID> on any drive. <SID> is your Secure ID, in 8-digit hexadecimal format, without any (0x, $, h, etc.) prefix or postfix. Secure ID can be specified in the .mmp file with the SECUREID keyword. If it is not specified, it defaults to your UID (specified by the UID keyword, which is always present). The 0x100039ce is a common UID for all kind of graphical applications, so the other one is "yours" (usually 0xEsomething if you generate a new project with Carbide.c++)
You can use .jpg, but in that case loading it will require some work with CImageDecoder. It operates asynchronously by default, but actually it is possible to "straigthen" out with the EOptionAlwaysThread flag. See [url]http://www.developer.nokia.com/Community/Wiki/Archived:How_to_decode_images_synchronously_using_Symbian_C%2B%2B[/url], the second code snippet.
.mbm is the native bitmap format of Symbian, it can be loaded with a simple CFbsBitmap::Load call. It is built from .bmp images, the .mmp file supports it. If your SDK contains an example called "Graphics", containing files like ball.bmp, and background.bmp, you can check how its .mmp file creates the .mbm.
Here is a Wiki article about .mmp stuff, it also shows this bitmap magic: [url]http://www.developer.nokia.com/Community/Wiki/MMP_file[/url]

I have a tab component in my application flow. I am setting it through resource in .rss file
[CODE]
RESOURCE EIK_APP_INFO
{
/**/menubar = r_menubar;
/**/cba = R_AVKON_SOFTKEYS_OPTIONS_EXIT;
status_pane = r_service_mobile_status_pane;
}

RESOURCE STATUS_PANE_APP_MODEL r_service_mobile_status_pane
{
panes=
{
SPANE_PANE
{
id = EEikStatusPaneUidNavi;
type = EAknCtNaviPane;
resource = r_service_mobile_navi_decorator;
}
};
}
[/CODE]

The problem I am facing is-> the tab component is still present in the splash screen, whereas it should have come in the second screen.The views belonging to the tab are not there, only the top portion is showing. How can I fix it. Any suggestions?

Why not keep splash screen as full screen view(when activating splash screen instead of passing clientRect(), pass ApplicationRect() )

after the splas screen is over with its work, I want do delete it but it crashes.There is no crash if i do not delete thw view.can I delete a view?

[CODE]
iSplashView = new (ELeave) CViewSplash;

CleanupStack::PushL( iSplashView );
iSplashView->ConstructL();
AddViewL( iSplashView ); // transfer ownership to CAknViewAppUi
CleanupStack::Pop( iSplashView );
iSplashViewId = iSplashView->Id();
SetDefaultViewL( *iSplashView );



--------------------------------------------------------------------------------------------------
CViewNormal* NormalView = new (ELeave) CViewNormal;

CleanupStack::PushL( NormalView );
NormalView->ConstructL(iTabGroup);
AddViewL( NormalView ); // transfer ownership to CAknViewAppUi
CleanupStack::Pop( NormalView );
iNormalViewId = NormalView->Id(); // view id to get view from CAknViewAppUi

SetDefaultViewL( *NormalView );
ActivateLocalViewL((iNormalViewId));
RemoveView (iSplashViewId );
delete iSplashView;

[/CODE]

why not follow the view switching flow in symbian : [url]http://www.developer.nokia.com/Community/Wiki/Switching_views_on_Symbian[/url]

You should be able to delete the view after it has been removed - if you can't then there is a problem which you will have to debug based on the type of crash.

... or you can take Vineet's advice - the normal flow doesn't delete the view, but the view deletes its CCoeControl which is what would consume most of the memory.

Hi Hamish Willee,
Thanks for your reply. I am not getting carash if I do not include the following lines->
RemoveView (iSplashViewId );
delete iSplashView;
But I get the crash if I include them
Rest my code is same as given in the link suggested by Vineet
I am not using any resources except for 2 in the container of the view->
CFbsBitmap* iBgPic;
CImageDecoder* iDecoder;

and the destructor of container is as follows->
CViewContainerSplash::~CViewContainerSplash()
{
Cancel();
if(iBgPic)
{
delete iBgPic;
iBgPic=NULL;
}
if(iDecoder)
{
delete iDecoder;
iDecoder=NULL;
}
}

Symbian shows some short error messages by default, however in development time it is better to enable the longer version: [url]http://www.developer.nokia.com/Community/Wiki/Extended_panic_code[/url]

As wizard says, find out more about the crash and we can possibly better explain why this is failing. In any case, the big resource here is probably your iBgPic - so provided that is deleted when the view is deactivated, the fact that you still have a view in existence is unlikely to be a problem on current devices.

hi, I have enabled the "Extended panic code file" option in Tools -> Preferences menu. this create file "errrd" in C:\S60\devices\S60_3rd_FP2_SDK_v1.1\epoc32\winscw\c\resource. I run the application, but I do not get a panic code. the emulator just vanishes after running for sometime. also while debugging it shows "no source found for ekern.exe". I think the view::DoDeactivate function is not called when view is switched. I conclude as I notice iContainer is deleted in CViewSplash::~CViewSplash()
after i call RemoveView (iSplashViewId );
as i have the code
void CViewSplash::DoDeactivate()
{
if ( iContainer )
{
AppUi()->RemoveFromViewStack( *this, iContainer );
delete iContainer;
iContainer = NULL;
}


}

CViewSplash::~CViewSplash()
{
if ( iContainer )
{
AppUi()->RemoveFromViewStack( *this, iContainer );
delete iContainer;
iContainer=NULL;
}



}
In fact , I think that may be CViewSplash::DoDeactivate() is called after RemoveView (iSplashViewId );

and I found that- If i include RemoveView (iSplashViewId ); , CViewSplash::DoDeactivate() is not called
If i do not include RemoveView (iSplashViewId ); , CViewSplash::DoDeactivate() is called last.
but RemoveView (iSplashViewId ); is the last line of APPUI->ConstructL(). So, I think I should not delete the view. It is not possible in my case.

There's no need to call RemoveView() to delete/deactivate the splash view. Simply implement DoDeActivate() in the splash view & also no need to write the same lines of code in its destructor.

When you need to activate the NormalView then call ActivateLocalViewL(viewid), this would invoke the splashView's DoDeActivate() & NormalView's DoActivate().

[QUOTE=sandeepmhptr3;907619]but I do not get a panic code. the emulator just vanishes after running for sometime. also while debugging it shows "no source found for ekern.exe".[/QUOTE]The debugger breaks into the code before the panic note is displayed. However on the top of the call stack the panic code should be visible (it is some 8-10 character text, often upper case and a number).
The actual machine code instruction raising the debugger is residing in ekern.exe, however if you start scrolling the call stack, sooner or later you will find your own code with source, showing the exact line which raises the panic.