is it possible to create an application only with containers and no views??

Hi,

I am going to create a multiview application. Its going to be a fully custom controls application. Nothing would be from default ui. That is why i was thinking if its possible to skip creating CAknViews from the application. As the CAknView is responsible for handling view specific commands but my app is going to handle commands from the container itself. Its going to be a touch only application. In this case would it be possible to switch views without CAknView in the application? I was trying and got confused at the following:

To create a screen this is enough:
[CODE]iContainer = CSplashContainer::NewL(ClientRect());[/CODE]
but after that we need to add this control to stack to be able to receive commands like this
[CODE]AddToStackL(iSplashView)[/CODE]

So screen would be visible and take user commands. But what if i have to switch to another view. In that case, i should remove the current view from the stack right?
But there is no method to do this if i don't use CAknView in the application. Its possible only if i use CAknView. May be i don't know yet. To switch view it should be something like this
[CODE]AppUi()->RemoveFromViewStack(*this, iContainer);[/CODE]
but here pointer this should be a CAknView and not a CCoeControl!

Can i do without CAknViews and still able to remove CCoeControls from the stack??

Please suggest.

I actually stopped using Views right after they were introduced with S60, so you could indeed use the good old way, and handle Commands in your AppUI command handling, and us CCoeControl based containers directly in AppUI class.

just remember to change the base class for AppUI class, otherwise you'll end up having some visibility issues with command buttons.

Ok but how do i switch between screens? Is control stack not required in this case? I might have to switch to another screen from the current screen. I should delete the current one and create the second one. But what about control stack??

in general, you would add the CCoeControl based container to the stack with AddToStackL, and then when setting another one there, you would use RemoveFromStack to remove the previous. note that it is stack indeed, and you do need to remember what was added last so you know what's coming out.

Deleting would be an option, it would make it easier to handle the adding/removing from the stack, since you would only have one valid view, and it would be the only one in the stack at any time.

Ok i tried and found that AddToStackL and RemoveFromStack isn't working. App crashes with Kern-Exec 3 when removing the old CCoeControl from stack. I think simple deletion and creation of CCoeControls is easy to go with.

Following is not working from the current CCoeControl
[CODE] iAppUi->RemoveFromStack(this);
iLoginView = CLoginContainer::NewL(CEikonEnv::Static()->EikAppUi()->ApplicationRect());
iAppUi->AddToStackL(iLoginView);
[/CODE]

Also if i try to simple delete the current CCoeControl and create sencond, it gives CONE 44 panic (control still on stack)
[CODE] delete this;
iLoginView = CLoginContainer::NewL(CEikonEnv::Static()->EikAppUi()->ApplicationRect());
[/CODE]

Am i not using them correctly??

what excatly are you thinking on doing with [B]iAppUi->RemoveFromStack(this);[/B] line ? or [B]delete this;[/B] ?

Basically you only need to care on deleting the container-views you are have created, as well as only remove stuff from the stack you have pushed in.

with iAppUi->RemoveFromStack(this);, I am trying to remove the container that i previously added to the stack and then creating the new container and adding it to stack.

same thing with delete this; - trying to delete this container and creating new one.

Simple creation of container-view whenever switching is required is working though.

Even though i got it working with deletion but just wanted to know how to make it working with methods AddToStackL and RemoveFromStack.

Is the way i am using these wrong?

AddToStackL and RemoveFromStack are very good methods. However deleting an object, and assigning a value to one of its members in the next line is just a general C++ problem. Leading to KERN-EXEC 3 in Symbian, especially if you do it in the debugger.
Generally you want to store the next view in an existing object, like AppUi, and not in a deleted one. This entire code snippet could have a better place in the AppUi (RemoveFromStack(iSomething);iLoginView=CLoginContainer::NewL(ApplicationRect());AddToStackL(iLoginView);) when in a piece of code every line refers to a single other object (like AppUi and its methods, like RemoveFromStackL, ApplicationRect, AddToStackL), that code rather belongs to that other object.

[QUOTE]This entire code snippet could have a better place in the AppUi (RemoveFromStack(iSomething);iLoginView=CLoginContainer::NewL(ApplicationRect());AddToStackL(iLoginView);)[/QUOTE]

But i have to switch view from another view. Can this not work in another CCoeControl? Also, i am taking reference of AppUi, so its being done on existing object and not on deleted object.
I am creating the first container-view in the AppUi and then switching to another container-view from the one created in AppUi. I guess that is fine.

Refering to #6, this code in second container-view. But there its throwing kern-exec 3.
AddToStackL is fine but i can't find the correct place for RemoveFromStack and that is crashing the app.

Actually second container-view was still on stack. Removing it in destructor fixed the issue. Done

[QUOTE=raj8nokiaforum;912735]But i have to switch view from another view. Can this not work in another CCoeControl?[/QUOTE]Oh, there are a lot many coding styles which work, than the ones considered being correct. Obviously if you put the view switching mechanism to the AppUi, you can call it from a CCoeControl, as you already did with AddToStackL, etc. But that would be 1 call, and not 3.[QUOTE]Also, i am taking reference of AppUi, so its being done on existing object and not on deleted object.[/QUOTE]I was talking about the[CODE]delete this;
iLoginView = ...[/CODE]part. iLoginView is a member variable in the current object. And the current object has been destroyed in the previous line. I hope you feel why it is not correct.[QUOTE]I am creating the first container-view in the AppUi and then switching to another container-view from the one created in AppUi. I guess that is fine.[/QUOTE]Switching the view is fine. Storing the pointer of the new view in a non-existing object is not.[QUOTE]Refering to #6, this code in second container-view. But there its throwing kern-exec 3.[/QUOTE]Indeed, that makes two of us. I am also talking about #6.