Well, knowing I really need to manage several toolbars (wxToolbar ones) and would like to stay with wxSmith, I've taken a look at the source (knowing I'm under Windows 7 64-bit with MinGW64, I've worked in another Windows with MinGW32 under VirtualBox) and managed a way. Here it is :
1) In "wxwidgets\defitems\wxstoolbar.cpp", I've commented a part of wxsToolBar::OnCanAddToResource() like this :
bool wxsToolBar::OnCanAddToResource(wxsItemResData* Data,bool ShowMessage)
{
if ( Data->GetClassType() != _T("wxFrame") )
{
if ( ShowMessage )
{
cbMessageBox(_("wxToolBar can be added to wxFrame only"));
}
return false;
}
/* ***eranon : disabled to allow several wxToolbar in a frame (dev being responsible to fix the multi SetToolBar() issue by hand
for ( int i=0; i<Data->GetToolsCount(); i++ )
{
if ( Data->GetTool(i)->GetClassName() == _T("wxToolBar") )
{
if ( ShowMessage )
{
cbMessageBox(_("Can not add two or more wxToolBar classes\ninto one wxFrame"));
}
return false;
}
}
*/
return true;
}
Then, wxSmith doesn't limit the toolbar to one only anymore...
2) Of course, knowing wxSmith generates code calling SetToolBar() for every toolbar, I've had to override this method in my own project (the best would be to manage the stuff from within wxSmith, but it require to go deeper than I had) to do every toolbar be added to a specific container (ie. a panel or a sizer) :
void TestFrame::SetToolBar(wxToolBar* toolBar)
{
// Overrides wxFrame::SetToolbar to customize the association
// NB : workaround to use wxSmith even if it calls SetToolBar systematically
if (toolBar->GetName() == "ID_TOOLBAR2"){
toolBar->Reparent(panelMain);
sizerForT2->Add(toolBar);}
else {
wxFrame::SetToolBar(toolBar);}
}
At this time, it works, but, of course, now I can't open my project in the standard (stable or nightly) Code::Blocks, because it removes my toolbars (except the first one) at first wxSmith launch
If a wxSmith maintainer could confirm me it doesn't have wrong side effects and, if not, if he could manage to remove the lock in the official wxSmith (maybe extending with a choice to do SetToolBar or not), it would be nice
--
EDIT : in some circumstances, I've seen a wrong behavior (not about wxSmith, but about app working) : sometime, the standard location of the toolbar remains visible as reserved area (ie. a transparent, unrefreshed rect w/o toolbar anymore). So, suspecting this to come from the base wxFrame::SetToolBar(), I've prevented this doing my overriding as const (so the passed this pointer is now forced to stay of TestFrame type), like this :
void TestFrame::SetToolBar(wxToolBar* toolBar) const
{
// Overrides wxFrame::SetToolbar to customize the association
// NB : workaround to use wxSmith even if it calls SetToolBar systematically
if (toolBar->GetName() == "ID_TOOLBAR2"){
toolBar->Reparent(panelMain);
sizerForT2->Add(toolBar);}
else {
((wxFrame*) this)->SetToolBar(toolBar);}
}