I have a simple AppUi derived from CAknAppUi. I create a container in it derived from CCoeControl. I want to add controls to this container at runtime.
Is it possible to add controls to a compound control dynamically? If so,
how? I am not talking about dialogs which you simply do dlg->ExecuteLD(). I am talking about non-window owning controls.
I tried creating my new control and modifying ComponentControl(), SizeChanged() and
CountComponentControls() of the container to reflect the change.
It kinda works, but the new control doesn't get drawn until I touch the arrow keys are cause some kind of update process. When I create the control, I call DrawNow() but that doesn't seem to help either (even though I am doing MakeVisible(ETrue)).
So far I was unable to do that and I am not sure what I missing..
I searched up and down on every forum, but can't find the answer to this. The examples that come with the SDK don't show this either. The SDK examples use CAknView architecture. I don't want to do that because of its complexity and inflexibility..
Anyone have any ideas? Please let me know.
I have an AppUi which creates a iTopContainer. iTopContainer creates an iListBox in its ConstructL( ), and at a later stage (with one of the menu options), it creates an iSubContainer (derived from CCoeControl). iSubContainer creates an iSubListBox in its own ConstructL( ).
The only thing that worked is calling iSubContainer->SetFocus(ETrue, EDrawNow) when I create iSubContainer. iSubContainer has FocusChanged( ) implemented. If I call iSubListBox->DrawNow( ) in FocusChanged( ), then I get the second listbox to be drawn on top of iListBox. Nothing else works! Even calling iSubContainer->DrawNow( ) or DrawDeferred( ) doesn't work even though I can see that the controls are getting called (I put breakpoints in the code).
Does this make sense to anyone? Are listboxes somehow different that they require DrawNow( )??
You have a kind of design problem on the implementation. You should not try to 'force' drawing events, instead let UI framework to call Draw methods independently.
Maybe we need even more specs...
Should iSubContainer to be a child of iTopContainer, if yes there should not be any problem to implement this. SubContainer should call SetContainerWindowL(iTopContainer) and inside SubContainer you should implement e.g. CountComponentControls method which return the count and pointers of childs of SubContainer. There is also need to implement CountConponentControls inside CTopContainer and return iSubContainer there, obviously. This is the basic issue to get all controls to be drawn by framework. If controls overlaps each other it should not be a problem. The top most (some child of SubContainer) control is the last one to be drawn and obviously if this is huge (=has huge rect)control it could hide all other controls.
Next issue is how to handle 'focus'...before that exercise try to get all needed controls to be draw without any DrawNow commands. DrawDeferred is used only to tell framework you have dynamically changed something (in this case you have add SubContainer to be a child of TopContainer) and framework should force a draw event. First it call Draw of TopContainer, later CountOfComponents and will get pointer of SubContainer, it call Draw of SubContainer, and call CountOfComponents of SubContainet etc etc.
It is easier to investigate this kind of issues with simple control types, like label controls. This is becase you can define rect of label to be tiny and location can be different and therefore controls are not draw above each other.