Author Topic: Icon sizes not 16x16 or other runtime asserts w/ CVS HEAD  (Read 4122 times)

Offline johnl

  • Single posting newcomer
  • *
  • Posts: 5
Icon sizes not 16x16 or other runtime asserts w/ CVS HEAD
« on: November 01, 2005, 04:24:07 am »
I'm using linux, gcc 4.0.1, wxWidgets 2.6.2 (but from the CVS HEAD of the 2.6 branch)

It looks from the message board that people are using CodeBlocks in Linux or at least have some better success than I've had, any tips or are these new errors in CodeBlocks CVS HEAD?

=================

In src/sdk/projectmanager.cpp the wxImageList is created with
src/sdk/projectmanager.cpp:    m_pImages = new wxImageList(16, 16);
however, it tries to load images that are all various sizes. I get a debug assert in wxWidget's wxImageList.

[Debug] 09:50:40 PM: ./src/generic/imaglist.cpp(81): assert "(bitmap.GetWidth() == m_width && bitmap.GetHeight() == m_height) || (m_width == 0 && m_height == 0)" failed: invalid bitmap size in wxImageList: this might work on this platform but definitely won't under Windows.

For example: in void ProjectManager::BuildTree(wxWindow* parent) it tries to load
./src/src/resources/images/folder_open.png is 17x17.

===================
Skip that error and you get

[Debug] 09:57:06 PM: ./src/generic/treectlg.cpp(3547): assert "wxAssertFailure" failed: thawing unfrozen tree control?
Call stack:
...
[11] wxAssert(int, wchar_t const*, int, wchar_t const*, wchar_t const*)
[12] wxGenericTreeCtrl::Thaw()               
[13] ProjectManager::UnfreezeTree(bool)     
[14] ProjectManager::BuildTree(wxWindow*)

========================
More wrong image sizes for wxImageList

[Debug] 09:58:08 PM: ./src/generic/imaglist.cpp(81): assert "(bitmap.GetWidth() == m_width && bitmap.GetHeight() == m_height) || (m_width == 0 && m_height == 0)" failed: invalid bitmap size in wxImageList: this might work on this platform but definitely won't under Windows.

Call stack:
...
[11] wxAssert(int, wchar_t const*, int, wchar_t const*, wchar_t const*)
[12] wxGenericImageList::Add(wxBitmap const&)
[13] EditorManagerInternalData::BuildTree(wxTreeCtrl*)
[14] EditorManager::BuildOpenedFilesTree(wxWindow*)

======================

[Debug] 09:59:02 PM: ./src/generic/imaglist.cpp(81): assert "(bitmap.GetWidth() == m_width && bitmap.GetHeight() == m_height) || (m_width == 0 && m_height == 0)" failed: invalid bitmap size in wxImageList: this might work on this platform but definitely won't under Windows.

Call stack:
....
[11] wxAssert(int, wchar_t const*, int, wchar_t const*, wchar_t const*)
[12] wxGenericImageList::Add(wxBitmap const&)
[13] MessageManager::SetLogImage(MessageLog*, wxBitmap const&)
[14] EditorManager::CreateSearchLog()       

=====================
Then there's some invalid menu items

[Debug] 09:59:37 PM: ./src/common/menucmn.cpp(994): assert "wxAssertFailure" failed: attempt to enable an item which doesn't exist

Call stack:
...
[11] wxAssert(int, wchar_t const*, int, wchar_t const*, wchar_t const*)
[12] wxMenuBarBase::Enable(int, bool)       
[13] MainFrame::OnFileMenuUpdateUI(wxUpdateUIEvent&)    /home/john/wx/CodeBlocks_CVS/codeblocks/src/src/main.cpp:1922
[14] wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const

I canceled in the assert dialog since these menu asserts seemed endless.

Note: To avoid asserts for enabling menu items that don't exist you can use FindItem like this:
#define MBAR_ENABLE(menu_id, val) { wxMenuItem *menuItem = mbar->FindItem(menu_id); if (menuItem) { menuItem->Enable(val); } }

src/src/main.cpp
void MainFrame::OnFileMenuUpdateUI(wxUpdateUIEvent& event)
{
...
    bool canCloseProject = (ProjectManager::CanShutdown() && EditorManager::CanShutdown());
    MBAR_ENABLE(idProjectCloseProject,canCloseProject);
...
}

"Fix" (or at least hide the problem) in this file as well
src/plugins/compilergcc/compilergcc.cpp
void CompilerGCC::OnUpdateUI(wxUpdateUIEvent& event)

Also... though this is a personal preference, using UpdateUI events for enabling menu/toolbar items is often massive overkill. For example UpdateUI events are sent for toolbar tools between just about every event, even just moving the mouse sends them. Using ui events are convenient, but they can tend to make programs a little sluggish.

The GUI for CodeBlocks shows at this point, but there are tons more errors.

Thanks for any tips, I can provide patches for some of these, but if the developers have access to a Linux box, most of these errors seem trivial and can be very quickly fixed.

Regards,
    John Labenski

Offline johnl

  • Single posting newcomer
  • *
  • Posts: 5
Re: Icon sizes not 16x16 or other runtime asserts w/ CVS HEAD
« Reply #1 on: November 03, 2005, 06:55:44 am »
So... nobody else gets these errors from wxImageList at least? I find that hard to believe since the checks were added to wxWidgets/src/generic/imaglist.cpp 2 years, 3 months ago (ver 1.31).

======================

So in lieu of any news, here's a fix for wxComboBox not having SetString in platforms other than MSW

editorconfigurationdlg.cpp:478:3: warning: #warning "wxComboBox::SetString() doesn't work under non-win32 platforms"

[[email protected] CodeBlocks_CVS]$ cvs diff -bu2  ./codeblocks/src/sdk/editorconfigurationdlg.cpp
Index: ./codeblocks/src/sdk/editorconfigurationdlg.cpp
===================================================================
RCS file: /cvsroot/codeblocks/codeblocks/src/sdk/editorconfigurationdlg.cpp,v
retrieving revision 1.24
diff -b -u -2 -r1.24 editorconfigurationdlg.cpp
--- ./codeblocks/src/sdk/editorconfigurationdlg.cpp     2 Nov 2005 14:12:50 -0000       1.24
+++ ./codeblocks/src/sdk/editorconfigurationdlg.cpp     3 Nov 2005 05:31:55 -0000
@@ -463,5 +463,4 @@
 void EditorConfigurationDlg::OnRenameColorTheme(wxCommandEvent& event)
 {
-#ifdef __WXMSW__
     wxTextEntryDialog dlg(this, _("Please enter the new name of the new color theme:"), _("New theme name"), m_Theme->GetName());
     if (dlg.ShowModal() != wxID_OK)
@@ -472,10 +471,15 @@
     int idx = cmbThemes->FindString(m_Theme->GetName());
     if (idx != wxNOT_FOUND)
+    {
+#ifdef __WXMSW__
         cmbThemes->SetString(idx, name);
-    ConfigManager::Get()->RenameGroup(_T("/editor/color_sets/") + m_Theme->GetName(), _T("/editor/color_sets/") + name);
-    m_Theme->SetName(name);
 #else
-       #warning "wxComboBox::SetString() doesn't work under non-win32 platforms"
+        // NOTE: wxComboBox::SetString() doesn't work under non-win32 platforms
+        cmbThemes->Delete(idx);
+        cmbThemes->Insert(name, idx);
 #endif
+    }
+    ConfigManager::Get()->RenameGroup(_T("/editor/color_sets/") + m_Theme->GetName(), _T("/editor/color_sets/") + name);
+    m_Theme->SetName(name);
 }

Regards,
    John Labenski

Offline doscott

  • Multiple posting newcomer
  • *
  • Posts: 17
Re: Icon sizes not 16x16 or other runtime asserts w/ CVS HEAD
« Reply #2 on: November 03, 2005, 10:33:36 pm »
I only get these errors if I build wx with debugging enabled.

Offline johnl

  • Single posting newcomer
  • *
  • Posts: 5
Re: Icon sizes not 16x16 or other runtime asserts w/ CVS HEAD
« Reply #3 on: November 04, 2005, 05:20:29 am »
> I only get these errors if I build wx with debugging enabled.

Precicely; wxASSERT_MSG, wxCHECK_MSG/RET are empty #defines (see include/wx/debug.h) when compiled in release mode. That why I always compile in debug mode to ensure that the code is correct. Most of these checks are very important (eg. checking for NULL pointers) and you can get segfaults without warning if they're ignored.

Regards,
    John Labenski

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Icon sizes not 16x16 or other runtime asserts w/ CVS HEAD
« Reply #4 on: November 04, 2005, 05:38:34 pm »
Has anyone applied (or tried to) Johnl's patch?

Offline grv575

  • Official tester
  • Regular
  • ***
  • Posts: 381
Re: Icon sizes not 16x16 or other runtime asserts w/ CVS HEAD
« Reply #5 on: November 05, 2005, 02:34:11 am »
I've been too busy to do testing lately - bogged down with school projects ( :( sorry) but I do remember getting crashes due to some wxString stuff.  Don't know if this is the same issue...

Also, I agree that the UpdateUI event should be trimmed down.  It's noticable when you open the project/global options dialog and move the mouse (mouse movement slows to a crawl on my box).