I am using:
class ISearchFuncs :
public Osp::Ui::IActionEventListener
, public Osp::Ui::ITextEventListener
, public Osp::Ui::IScrollPanelEventListener {
public:
virtual result CloseOverlayKeyb() = 0;
virtual result InitiateSearch() = 0;
};
but when I try and connect to those interfaces by passing a pointer to ISearchFuncs
the callback/events fail to run. Whereas, connecting up using those interfaces in the class that actually implements them has no such problems. I could live with that but it would be better encapsulation if I could get to the bottom of this problem.
class Form1 :
public Osp::Ui::Controls::Form
, public ISearchFuncs
// , public Osp::Ui::IActionEventListener// see below
// , Osp::Ui::ITextEventListener//deleted due to ambiguity
{
This is how it can be made to work:
EditField *pSearchEditField = new EditField;
TryCatch(E_SUCCESS == (r = pSearchEditField->Construct(Rectangle(labelRect.x + labelRect.width / 6, labelRect.y, 7 * labelRect.width / 12, 80)
, EDIT_FIELD_STYLE_NORMAL, INPUT_STYLE_OVERLAY, false, 100, GROUP_STYLE_MIDDLE)),, GetErrorMessage(r));
pSearchEditField->AddTextEventListener(*this);
pSearchEditField->AddScrollPanelEventListener(*this);
pSearchEditField->AddActionEventListener(*this);
TryCatch(E_SUCCESS == (r = pSearchEditField->SetOverlayKeypadCommandButton(COMMAND_BUTTON_POSITION_LEFT,
L"Done", SearchPanel::ID_BUTTON_SEARCH_EDITFIELD_DONE)),, "");
TryCatch(E_SUCCESS == (r = pSearchEditField->SetOverlayKeypadCommandButton(COMMAND_BUTTON_POSITION_RIGHT,
L"Cancel", SearchPanel::ID_BUTTON_SEARCH_EDITFIELD_CANCEL)),, "");
__pScrollPanel->AddControl(*pSearchEditField);
whereas passing to another class to do the equivalent fails to connect events at run time:
__pSearchPanel->Construct(labelRect, this, __pScrollPanel);
calls:
result SearchPanel::Construct(const Rectangle &rect, ISearchFuncs *pListener, ScrollPanel *pScrollPare) {
result r = E_SUCCESS;
int x1 = rect.width / 6;
int x2 = rect.width * 3 / 4;
int y1 = rect.height / 3;
EditField *pSearchEditField = new EditField;
TryCatch(E_SUCCESS == (r = pSearchEditField->Construct(Rectangle(rect.x + x1, rect.y, x2 - x1, y1)
, EDIT_FIELD_STYLE_NORMAL, INPUT_STYLE_OVERLAY, false, 100, GROUP_STYLE_MIDDLE)),, GetErrorMessage(r));
pSearchEditField->AddTextEventListener(*pListener);
pSearchEditField->AddScrollPanelEventListener(*pListener);
pSearchEditField->AddActionEventListener(*pListener);
TryCatch(E_SUCCESS == (r = pSearchEditField->SetOverlayKeypadCommandButton(COMMAND_BUTTON_POSITION_LEFT,
L"Done", SearchPanel::ID_BUTTON_SEARCH_EDITFIELD_DONE)),, "");
TryCatch(E_SUCCESS == (r = pSearchEditField->SetOverlayKeypadCommandButton(COMMAND_BUTTON_POSITION_RIGHT,
L"Cancel", SearchPanel::ID_BUTTON_SEARCH_EDITFIELD_CANCEL)),, "");
TryCatch(E_SUCCESS == (r = pScrollPare->AddControl(*pSearchEditField)),, "");
Sorry for the code duplication, but this is driving me crazy.
The idiom I am attempting to follow is part of the bada SDK's help.
After being forced to accept the hack I outlined in my question I was getting some errors due to having overriden methods with stubs, IIRC.
I am 90% sure that that was not the reason for the anomoly that inspired my question but 100% sure it's more relevant than pmr's answer.