/projects/wx/2.9/wxWidgets/src/common/menucmn.cpp(143): assert
"wxIsStockID(GetId())" failed in SetItemLabel(): A non-stock menu item
with an empty label?
/projects/wx/2.9/wxWidgets/src/common/stockitem.cpp(202): assert "Assert
failure" failed in wxGetStockLabel(): invalid stock item ID
/projects/wx/2.9/wxWidgets/src/osx/menuitem_osx.cpp(55): assert
"wxIsStockID(GetId())" failed in wxMenuItem(): A non-stock menu item
with an empty label?
/projects/wx/2.9/wxWidgets/src/common/stockitem.cpp(202): assert "Assert
failure" failed in wxGetStockLabel(): invalid stock item ID
13:23:17: Debug: No accel key found, accel string ignored.
/projects/wx/2.9/wxWidgets/src/osx/menuitem_osx.cpp(210): assert
"wxIsStockID(GetId())" failed in UpdateItemText(): A non-stock menu item
with an empty label?
/projects/wx/2.9/wxWidgets/src/common/stockitem.cpp(202): assert "Assert
failure" failed in wxGetStockLabel(): invalid stock item ID
I think that this should be a valid state for wxMenuItem and that these
asserts should be removed. For example, code like this should be allowed:
item = wx.MenuItem(menu)
item.SetId(ID)
item.SetText("a menuitem label)
menu.InsertItem(pos, item)
Thoughts?
--
Robin Dunn
Software Craftsman
http://wxPython.org
> I think that this should be a valid state for wxMenuItem and that these
> asserts should be removed. For example, code like this should be allowed:
>
> item = wx.MenuItem(menu)
> item.SetId(ID)
> item.SetText("a menuitem label)
> menu.InsertItem(pos, item)
Without the syntax error of course. ;-)
RD> I think that this should be a valid state for wxMenuItem and that these
RD> asserts should be removed. For example, code like this should be allowed:
RD>
RD> item = wx.MenuItem(menu)
RD> item.SetId(ID)
RD> item.SetText("a menuitem label)
RD> menu.InsertItem(pos, item)
RD>
RD> Thoughts?
I don't like this. A menu item is supposed to have a label and allowing
the above would mean that it can be in temporarily invalid state. And then
we'd need to check in wxMenu::Insert() that the item being inserted is in
valid state. Which seems somewhat unnecessary to me, what's wrong with
creating the item with correct label and id from the beginning? I.e. what's
the advantage of allowing the above?
Regards,
VZ
I agree that being able to have code like the above is not strictly
necessary, but the way that wxMenuItem is documented it would seem to
imply that it is possible even if it is not the best idea, because all
the ctor parameters have default values:
wxMenuItem::wxMenuItem (wxMenu * parentMenu = NULL,
int id = wxID_SEPARATOR,
const wxString & text = wxEmptyString,
const wxString & helpString = wxEmptyString,
wxItemKind kind = wxITEM_NORMAL,
wxMenu * subMenu = NULL
)
However there is at least one situation where a menu item with no label
and a non-stock ID is valid, and that is with wxComboBox in the Mac
ports, since they use a wxMenu for the combo popup. Having an empty
item in the combo's list of choices is something that should be allowed,
but it can't be done without asserts currently, and always telling
people to work around it with " " is not acceptable IMO.
RD> I agree that being able to have code like the above is not strictly
RD> necessary, but the way that wxMenuItem is documented it would seem to
RD> imply that it is possible even if it is not the best idea, because all
RD> the ctor parameters have default values:
RD>
RD> wxMenuItem::wxMenuItem (wxMenu * parentMenu = NULL,
RD> int id = wxID_SEPARATOR,
RD> const wxString & text = wxEmptyString,
RD> const wxString & helpString = wxEmptyString,
RD> wxItemKind kind = wxITEM_NORMAL,
RD> wxMenu * subMenu = NULL
RD> )
This is unavoidable if we want to allow people to create separators using
this ctor because they really don't have any labels. But FWIW I agree that
it isn't ideal and I'd prefer to have different functions for creating
separators and normal items. But it's much too late for this.
RD> However there is at least one situation where a menu item with no label
RD> and a non-stock ID is valid, and that is with wxComboBox in the Mac
RD> ports, since they use a wxMenu for the combo popup.
IMO it's just a detail of the port and should be completely hidden from
the user code.
RD> Having an empty item in the combo's list of choices is something that
RD> should be allowed, but it can't be done without asserts currently, and
RD> always telling people to work around it with " " is not acceptable IMO.
I definitely agree with this. But I think it's wxOSX code that should
translate between empty string and " " as long as it needs to use
wxMenuItems here.
Regards,
VZ
Ok, I'll make a change there instead.