MSW, wxListbook: why the icons are shifted in the listview control

[AsmWarrior]

Hi, when migration CodeBlocks' base library from wx 2.8 to wx3.0.2, I meet a layout issue, that is the icons in the listbook is not in the center of the listview. Please have a look at the image below. The left image is a screen shot from the wx 3.0.2(or wx trunk) build of C::B, and the right image is from a wx2.8 build of C::B.

When I test the wx trunk's sample notebook, it does not have the layout issue. So, my question is: what cause such layout issue? Thanks?

BTW: the full issue is explained in a C::B's ticket, see:https://sourceforge.net/p/codeblocks/tickets/234/, I even wrote a very simple listbook which have only one panel, but the opened wxListbook still have such issue if opened inside C::B.

Thanks.

Asmwarrior

[Vadim Zeitlin]

On Sat, 9 Jan 2016 05:55:22 -0800 (PST) AsmWarrior wrote:

A> Hi, when migration CodeBlocks' base library from wx 2.8 to wx3.0.2, I meet
A> a layout issue, that is the icons in the listbook is not in the center of
A> the listview. Please have a look at the image below. The left image is a
A> screen shot from the wx 3.0.2(or wx trunk) build of C::B, and the right
A> image is from a wx2.8 build of C::B.
A>
A> When I test the wx trunk's sample notebook, it does not have the layout
A> issue. So, my question is: what cause such layout issue? Thanks?

I suspect the fact that the listbook is created initially without the
images and they are added to it later (if I understood the C::B ticket
correctly) triggers the problem, but I have no idea why.

Have you tried adding a PostSizeEvent() call to see if it can help to work
around the problem? If it doesn't, it would be really great if you could
find a way to reproduce this in the notebook or, perhaps, the xrc sample so
that I could debug it there.

Thanks,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[asmwarrior]

On 2016-1-14 23:28, Vadim Zeitlin wrote:
> On Sat, 9 Jan 2016 05:55:22 -0800 (PST) AsmWarrior wrote:
>
> A> Hi, when migration CodeBlocks' base library from wx 2.8 to wx3.0.2, I meet
> A> a layout issue, that is the icons in the listbook is not in the center of
> A> the listview. Please have a look at the image below. The left image is a
> A> screen shot from the wx 3.0.2(or wx trunk) build of C::B, and the right
> A> image is from a wx2.8 build of C::B.
> A>
> A> When I test the wx trunk's sample notebook, it does not have the layout
> A> issue. So, my question is: what cause such layout issue? Thanks?
>
> I suspect the fact that the listbook is created initially without the
> images and they are added to it later (if I understood the C::B ticket
> correctly) triggers the problem, but I have no idea why.

Thanks for the reply. You are 100% correct here. Our C::B's menu event handler looks like below:

void MainFrame::OnSettingsEditor(cb_unused wxCommandEvent& event)
{
EditorConfigurationDlg dlg(Manager::Get()->GetAppWindow());
// dlg.SendSizeEvent(wxSEND_EVENT_POST);
// dlg.SendSizeEvent();

if (dlg.ShowModal() == wxID_OK)
{
......
}
}

In the constructor of the EditorConfigurationDlg, it load the XRC file(at this time, only text in listview, no icons is added), and after that, we set the images by calling SetPageImage() function of wxListBook, and later SetImageList(). Whether first call SetImageList(), and later call
SetPageImage() or call them in reverse order does not change the issue status.

>
> Have you tried adding a PostSizeEvent() call to see if it can help to work
> around the problem? If it doesn't, it would be really great if you could
> find a way to reproduce this in the notebook or, perhaps, the xrc sample so
> that I could debug it there.
>
>

Adding PostSizeEvent() call with arguments 0 or wxSEND_EVENT_POST does not solve my problem. Also, I have already created a small wxDialog based app. That is: when I hit a button on the dialog, a new wxDialog opened and loads the whole XRC file(which is the same thing used in the C::B) is loaded, I also post the screen shot in C::B ticket, see(https://sourceforge.net/p/codeblocks/tickets/_discuss/thread/81546138/bcbc/attachment/wx-sample-show-listbook-xrc.png)and the strange thing is, I can't reproduce such issue. I have have tested the wx's notebook sample, and it still can't expose this issue.

In our C::B's code, I can even reduce the XRC file used in EditorConfigurationDlg to only one panel with one button, but the issue still happens, see the imageshot(https://sourceforge.net/p/codeblocks/tickets/_discuss/thread/81546138/84a5/attachment/a-simple-listbook-error.png)

So, I really don't know how to reproduce this bug to a simple wx code, sorry.

Thanks.
Asmwarrior

[Vadim Zeitlin]

On Fri, 15 Jan 2016 09:17:47 +0800 asmwarrior wrote:

a> In the constructor of the EditorConfigurationDlg, it load the XRC
a> file(at this time, only text in listview, no icons is added), and after
a> that, we set the images by calling SetPageImage() function of
a> wxListBook, and later SetImageList(). Whether first call SetImageList(),
a> and later call SetPageImage() or call them in reverse order does not
a> change the issue status.

In principle, you must call SetImageList() first so that the code could
(even if it doesn't do it now) verify that correct image indexes are used.
Also, if you look at wxListbook::GetListCtrlFlags() you can see that it
does different things depending on whether there is an image list or not,
so maybe you should try defining a dummy image list in XRC (and replace it
with the real one later) to work around the problem?

a> So, I really don't know how to reproduce this bug to a simple wx code,
a> sorry.

It will have to be debugged in C::B itself then, but not by me, I'm
afraid. To begin with, you probably want to look at what does
wxListCtrl::MSWGetBestViewRect() return.

Good luck,

[asmwarrior]

Hi, VZ, thanks, I just did what you suggested, and I create a very tiny XRC file which contains a wxListBook, with one panel and one icon.
I even't don't call any function, just load the XRC file when in the constructor of the dialog. I still see difference when the dialog is opened from a tiny wx sample and the C::B.

Here is the image shot when opened from tiny wx sample, looks quite good



Here is the image shot when opened from C::B's menu event handler



Look, it is already different. The second image shot shows the issue now.

BTW, I see some alert when open the dialog from the C::B. One is:



If I click the "Cancel", the dialog just opened, but the icon is not shown quite well(as you can see in the second image shot).
Now, when I click the "X" button in the dialog, the whole C::B hangs. I don't know the reason, but maybe, the Debug Alert shows something, but I really don't know what does this Debug Alert means. (I'm building both wx sample program and C::B against wx git master head).

In the attachment, there is an XRC file and the dummy png file.

Thanks.

Asmwarrior

[Vadim Zeitlin]

On Sun, 17 Jan 2016 22:59:37 +0800 asmwarrior wrote:

a> Here is the image shot when opened from C::B's menu event handler
a>
a> Look, it is already different.

I have no idea how is this possible :-( Could you be using a modified
version of wxListbook or its XRC handler in C::B?

a> BTW, I see some alert when open the dialog from the C::B.
[A hint: press Ctrl+C to copy the message box test instead of making a
screen shot, this is faster]

This is definitely a problem. You need to break into the debugger and find
out why is AddChild() being called twice.

Regards,

[asmwarrior]

On 2016-1-18 22:43, Vadim Zeitlin wrote:
> On Sun, 17 Jan 2016 22:59:37 +0800 asmwarrior wrote:
>
> a> Here is the image shot when opened from C::B's menu event handler
> a>
> a> Look, it is already different.
>
> I have no idea how is this possible :-( Could you be using a modified
> version of wxListbook or its XRC handler in C::B?

Thanks for the reply. It looks like this issue is NOT related the XRC handler in C::B, because I can reproduce this issue by just running C++ code inside the constructor of the dialog, such as:

MyDialog1::MyDialog1( wxWindow* parent, wxWindowID id, const wxString& title, const wxPoint& pos, const wxSize& size, long style ) : wxDialog( parent, id, title, pos, size, style )
{
this->SetSizeHints( wxDefaultSize, wxDefaultSize );

wxBoxSizer* bSizer1;
bSizer1 = new wxBoxSizer( wxVERTICAL );

m_listbook1 = new wxListbook( this, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxLB_DEFAULT );
wxSize m_listbook1ImageSize = wxSize( 80,80 );
int m_listbook1Index = 0;
wxImageList* m_listbook1Images = new wxImageList( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() );
m_listbook1->AssignImageList( m_listbook1Images );
wxBitmap m_listbook1Bitmap;
wxImage m_listbook1Image;
m_panel6 = new wxPanel( m_listbook1, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxTAB_TRAVERSAL );
m_listbook1->AddPage( m_panel6, wxT("hihiihi"), false );
m_listbook1Bitmap = wxBitmap( wxT("compiler.png"), wxBITMAP_TYPE_ANY );
if ( m_listbook1Bitmap.Ok() )
{
m_listbook1Image = m_listbook1Bitmap.ConvertToImage();
m_listbook1Images->Add( m_listbook1Image.Scale( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() ) );
m_listbook1->SetPageImage( m_listbook1Index, m_listbook1Index );
m_listbook1Index++;
}

bSizer1->Add( m_listbook1, 1, wxEXPAND | wxALL, 5 );


this->SetSizer( bSizer1 );
this->Layout();

this->Centre( wxBOTH );
}


The the result dialog also have shifted icons, but at this time, I don't see the alert message box shown, and close the dialog dose not hang the C::B.

>
> a> BTW, I see some alert when open the dialog from the C::B.
> [A hint: press Ctrl+C to copy the message box test instead of making a
> screen shot, this is faster]

Thanks, I never know CTRL+C in the message box can copy the text content. Just tried and it works fine.

>
> This is definitely a problem. You need to break into the debugger and find
> out why is AddChild() being called twice.
>

This may be a little beyond my ability, because I need to at least know all the logic about window construction.
But I will try it.

BTW, I have reported some wx bug in wx-user maillist:
help: wired crash issue which only happens in Windows XP system with release build of wx 3.0.2
https://groups.google.com/d/topic/wx-users/6sAlKVVpQiI/discussion

Maybe, this is an related issue under WinXP, currently I can only tested on WinXP.

Asmwarrior

[Vadim Zeitlin]

On Tue, 19 Jan 2016 21:07:04 +0800 asmwarrior wrote:

a> Thanks for the reply. It looks like this issue is NOT related the XRC
a> handler in C::B, because I can reproduce this issue by just running C++
a> code inside the constructor of the dialog, such as:

Thanks, this is useful to know as we can eliminate a lot of things from
consideration now.

But, just to be sure: if you use this code in e.g. the minimal sample it
still doesn't show the problem? This seems completely incredible :-(

[asmwarrior]

On 2016-1-21 1:31, Vadim Zeitlin wrote:
> On Tue, 19 Jan 2016 21:07:04 +0800 asmwarrior wrote:
>
> a> Thanks for the reply. It looks like this issue is NOT related the XRC
> a> handler in C::B, because I can reproduce this issue by just running C++
> a> code inside the constructor of the dialog, such as:
>
> Thanks, this is useful to know as we can eliminate a lot of things from
> consideration now.
>
> But, just to be sure: if you use this code in e.g. the minimal sample it
> still doesn't show the problem? This seems completely incredible :-(
>
> VZ
>

Hi, VZ, thanks.
I just created a very simple wx minimal sample, and when I click on the menu item, I just open the wxDialog.
I use the C++ code to construct this dialog, so no XRC related code.

You have to add two member declaration inside the Header file, such as:

wxListbook *m_listbook1;
wxPanel *m_panel6;

I see that the application just crashed. It has such call stack

Program received signal SIGSEGV, Segmentation fault.
At F:\wx\wxWidgets_trunk\src\generic\listbkg.cpp:277
----------------------------------------------
[debug]> bt 30
[debug]#0 0x00829369 in wxListbook::SetImageList (this=0xe891338, imageList=0xe88c9b8) at F:\wx\wxWidgets_trunk\src\generic\listbkg.cpp:277
[debug]#1 0x004051a9 in wxWithImages::AssignImageList (this=0xe8914c4, imageList=0xe88c9b8) at F:\wx\wxWidgets_trunk\include\wx\withimages.h:50
[debug]#2 0x004017e2 in NewDialog::NewDialog (this=0x22f424, parent=0xe8d5d58) at D:\temp\test-listbook-load-xrc2\NewDialog.cpp:241
[debug]#3 0x00402840 in test_listbook_load_xrc2Frame::OnAbout (this=0xe8d5d58, event=...) at D:\temp\test-listbook-load-xrc2\test_listbook_load_xrc2Main.cpp:106
[debug]#4 0x005a387a in wxAppConsoleBase::HandleEvent (this=0xe83b898, handler=0xe8d5d58, func=(void (wxEvtHandler::*)(wxEvtHandler * const, wxEvent &)) 0x40281a <test_listbook_load_xrc2Frame::OnAbout(wxCommandEvent&)>, event=...) at F:\wx\wxWidgets_trunk\src\common\appbase.cpp:657
[debug]#5 0x005a38d6 in wxAppConsoleBase::CallEventHandler (this=0xe83b898, handler=0xe8d5d58, functor=..., event=...) at F:\wx\wxWidgets_trunk\src\common\appbase.cpp:669
[debug]#6 0x0066c4cf in wxEvtHandler::ProcessEventIfMatchesId (entry=..., handler=0xe8d5d58, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1381
[debug]#7 0x0066b507 in wxEventHashTable::HandleEvent (this=0x41308c <test_listbook_load_xrc2Frame::sm_eventHashTable>, event=..., self=0xe8d5d58) at F:\wx\wxWidgets_trunk\src\common\event.cpp:989
[debug]#8 0x0066c93f in wxEvtHandler::TryHereOnly (this=0xe8d5d58, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1578
[debug]#9 0x00cb6c04 in wxEvtHandler::TryBeforeAndHere (this=0xe8d5d58, event=...) at F:\wx\wxWidgets_trunk\include\wx\event.h:3662
[debug]#10 0x0066c78b in wxEvtHandler::ProcessEventLocally (this=0xe8d5d58, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1511
[debug]#11 0x0066c72c in wxEvtHandler::ProcessEvent (this=0xe8d5d58, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1484
[debug]#12 0x0081084f in wxWindowBase::TryAfter (this=0xe889bf0, event=...) at F:\wx\wxWidgets_trunk\src\common\wincmn.cpp:3468
[debug]#13 0x0066c757 in wxEvtHandler::ProcessEvent (this=0xe889bf0, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1497
[debug]#14 0x0066c9cb in wxEvtHandler::SafelyProcessEvent (this=0xe889bf0, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1602
[debug]#15 0x0080b89c in wxWindowBase::HandleWindowEvent (this=0xe889bf0, event=...) at F:\wx\wxWidgets_trunk\src\common\wincmn.cpp:1542
[debug]#16 0x007d1419 in wxMenuBase::DoProcessEvent (menu=0xe890d88, event=..., win=0xe8d5d58) at F:\wx\wxWidgets_trunk\src\common\menucmn.cpp:676
[debug]#17 0x007d1362 in wxMenuBase::SendEvent (this=0xe890d88, itemid=101, checked=-1) at F:\wx\wxWidgets_trunk\src\common\menucmn.cpp:646
[debug]#18 0x00794851 in wxFrameBase::ProcessCommand (this=0xe8d5d58, item=0xe890e50) at F:\wx\wxWidgets_trunk\src\common\framecmn.cpp:294
[debug]#19 0x0070585e in wxFrame::HandleCommand (this=0xe8d5d58, id=101, cmd=0, control=0x0) at F:\wx\wxWidgets_trunk\src\msw\frame.cpp:799
[debug]#20 0x00705a58 in wxFrame::MSWWindowProc (this=0xe8d5d58, message=273, wParam=101, lParam=0) at F:\wx\wxWidgets_trunk\src\msw\frame.cpp:849
[debug]#21 0x006da75f in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 (hWnd=0x60178, message=273, wParam=101, lParam=0) at F:\wx\wxWidgets_trunk\src\msw\window.cpp:2649
[debug]#22 0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#23 0x00060178 in ?? ()
[debug]#24 0x00000111 in ?? ()
[debug]#25 0x00000065 in ?? ()
[debug]#26 0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:

----------------------------------------------
NOTE that I see the in the function:

----------------------------------------------
void wxListbook::SetImageList(wxImageList *imageList)
{
const long flagsOld = GetListCtrlFlags();

wxBookCtrlBase::SetImageList(imageList);

const long flagsNew = GetListCtrlFlags();

wxListView * const list = GetListView();

// We may need to change the list control mode if the image list presence
// has changed.
if ( flagsNew != flagsOld )
{
// Preserve the selection which is lost when changing the mode
const int oldSel = GetSelection();

list->SetWindowStyleFlag(flagsNew);
if ( list->InReportView() )
list->InsertColumn(0, wxS("Pages"));

// Restore selection
if ( oldSel != wxNOT_FOUND )
SetSelection(oldSel);
}

list->SetImageList(imageList, wxIMAGE_LIST_NORMAL);
}

----------------------------------------------
The list is just NULL.

BTW: I'm using wx git master HEAD version, which I cloned at 2015-12-27.
I first guess that the function call

m_listbook1->AssignImageList( m_listbook1Images );

should be put after initialization of m_listbook1Images, but If I adjust the code to something like below:

----------------------------------------------

this->SetSizeHints( wxDefaultSize, wxDefaultSize );

wxBoxSizer* bSizer1;
bSizer1 = new wxBoxSizer( wxVERTICAL );

m_listbook1 = new wxListbook( this, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxLB_DEFAULT );
wxSize m_listbook1ImageSize = wxSize( 80,80 );
int m_listbook1Index = 0;
wxImageList* m_listbook1Images = new wxImageList( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() );

//m_listbook1->AssignImageList( m_listbook1Images );

wxBitmap m_listbook1Bitmap;
wxImage m_listbook1Image;
m_panel6 = new wxPanel( m_listbook1, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxTAB_TRAVERSAL );
m_listbook1->AddPage( m_panel6, wxT("hihiihi"), false );
m_listbook1Bitmap = wxBitmap( wxT("compiler.png"), wxBITMAP_TYPE_ANY );

m_listbook1Image = m_listbook1Bitmap.ConvertToImage();
m_listbook1Images->Add( m_listbook1Image.Scale( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() ) );

m_listbook1->AssignImageList( m_listbook1Images );

m_listbook1->SetPageImage( m_listbook1Index, m_listbook1Index );
m_listbook1Index++;


bSizer1->Add( m_listbook1, 1, wxEXPAND | wxALL, 5 );


this->SetSizer( bSizer1 );
this->Layout();

this->Centre( wxBOTH );

----------------------------------------------
The crash still happens due to the empty pointer. The crash call stack is:

[debug]> bt 30
[debug]#0 0x00d9079c in wxWindowBase::HasFlag (this=0x0, flag=512) at F:\wx\wxWidgets_trunk\include\wx\window.h:668
[debug]#1 0x00d944ee in wxListCtrlBase::IsVirtual (this=0x0) at F:\wx\wxWidgets_trunk\include\wx\listbase.h:453
[debug]#2 0x0070f19a in wxListCtrl::InsertItem (this=0x0, info=...) at F:\wx\wxWidgets_trunk\src\msw\listctrl.cpp:1684
[debug]#3 0x0070f4ae in wxListCtrl::InsertItem (this=0x0, index=0, label=L"hihiihi", imageIndex=-1) at F:\wx\wxWidgets_trunk\src\msw\listctrl.cpp:1751
[debug]#4 0x008295bc in wxListbook::InsertPage (this=0xe891338, n=0, page=0xe88c078, text=L"hihiihi", bSelect=false, imageId=-1) at F:\wx\wxWidgets_trunk\src\generic\listbkg.cpp:325
[debug]#5 0x00cc9d83 in wxBookCtrlBase::AddPage (this=0xe891338, page=0xe88c078, text=L"hihiihi", bSelect=false, imageId=-1) at F:\wx\wxWidgets_trunk\include\wx\bookctrl.h:186
[debug]#6 0x004018c9 in NewDialog::NewDialog (this=0x22f424, parent=0xe8d5d58) at D:\temp\test-listbook-load-xrc2\NewDialog.cpp:210
[debug]#7 0x0040282c in test_listbook_load_xrc2Frame::OnAbout (this=0xe8d5d58, event=...) at D:\temp\test-listbook-load-xrc2\test_listbook_load_xrc2Main.cpp:106
[debug]#8 0x005a387a in wxAppConsoleBase::HandleEvent (this=0xe83b898, handler=0xe8d5d58, func=(void (wxEvtHandler::*)(wxEvtHandler * const, wxEvent &)) 0x402806 <test_listbook_load_xrc2Frame::OnAbout(wxCommandEvent&)>, event=...) at F:\wx\wxWidgets_trunk\src\common\appbase.cpp:657
[debug]#9 0x005a38d6 in wxAppConsoleBase::CallEventHandler (this=0xe83b898, handler=0xe8d5d58, functor=..., event=...) at F:\wx\wxWidgets_trunk\src\common\appbase.cpp:669
[debug]#10 0x0066c4cf in wxEvtHandler::ProcessEventIfMatchesId (entry=..., handler=0xe8d5d58, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1381
[debug]#11 0x0066b507 in wxEventHashTable::HandleEvent (this=0x41308c <test_listbook_load_xrc2Frame::sm_eventHashTable>, event=..., self=0xe8d5d58) at F:\wx\wxWidgets_trunk\src\common\event.cpp:989
[debug]#12 0x0066c93f in wxEvtHandler::TryHereOnly (this=0xe8d5d58, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1578
[debug]#13 0x00cb6c04 in wxEvtHandler::TryBeforeAndHere (this=0xe8d5d58, event=...) at F:\wx\wxWidgets_trunk\include\wx\event.h:3662
[debug]#14 0x0066c78b in wxEvtHandler::ProcessEventLocally (this=0xe8d5d58, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1511
[debug]#15 0x0066c72c in wxEvtHandler::ProcessEvent (this=0xe8d5d58, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1484
[debug]#16 0x0081084f in wxWindowBase::TryAfter (this=0xe889bf0, event=...) at F:\wx\wxWidgets_trunk\src\common\wincmn.cpp:3468
[debug]#17 0x0066c757 in wxEvtHandler::ProcessEvent (this=0xe889bf0, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1497
[debug]#18 0x0066c9cb in wxEvtHandler::SafelyProcessEvent (this=0xe889bf0, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1602
[debug]#19 0x0080b89c in wxWindowBase::HandleWindowEvent (this=0xe889bf0, event=...) at F:\wx\wxWidgets_trunk\src\common\wincmn.cpp:1542
[debug]#20 0x007d1419 in wxMenuBase::DoProcessEvent (menu=0xe890d88, event=..., win=0xe8d5d58) at F:\wx\wxWidgets_trunk\src\common\menucmn.cpp:676
[debug]#21 0x007d1362 in wxMenuBase::SendEvent (this=0xe890d88, itemid=101, checked=-1) at F:\wx\wxWidgets_trunk\src\common\menucmn.cpp:646
[debug]#22 0x00794851 in wxFrameBase::ProcessCommand (this=0xe8d5d58, item=0xe890e50) at F:\wx\wxWidgets_trunk\src\common\framecmn.cpp:294
[debug]#23 0x0070585e in wxFrame::HandleCommand (this=0xe8d5d58, id=101, cmd=0, control=0x0) at F:\wx\wxWidgets_trunk\src\msw\frame.cpp:799
[debug]#24 0x00705a58 in wxFrame::MSWWindowProc (this=0xe8d5d58, message=273, wParam=101, lParam=0) at F:\wx\wxWidgets_trunk\src\msw\frame.cpp:849
[debug]#25 0x006da75f in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 (hWnd=0xd013a, message=273, wParam=101, lParam=0) at F:\wx\wxWidgets_trunk\src\msw\window.cpp:2649
[debug]#26 0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#27 0x000d013a in ?? ()
[debug]#28 0x00000111 in ?? ()
[debug]#29 0x00000065 in ?? ()
[debug](More stack frames follow...)
[debug]>>>>>>cb_gdb:

and it is because in the function:
----------------------------------------------
bool
wxListbook::InsertPage(size_t n,
wxWindow *page,
const wxString& text,
bool bSelect,
int imageId)
{
if ( !wxBookCtrlBase::InsertPage(n, page, text, bSelect, imageId) )
return false;

GetListView()->InsertItem(n, text, imageId);

// if the inserted page is before the selected one, we must update the
// index of the selected page
if ( int(n) <= m_selection )
{
// one extra page added
m_selection++;
GetListView()->Select(m_selection);
GetListView()->Focus(m_selection);
}

if ( !DoSetSelectionAfterInsertion(n, bSelect) )
page->Hide();

UpdateSize();

return true;
}

----------------------------------------------
GetListView() returned a NULL pointer.


So, I guess there are something wrong inside the wxListBook.

BTW: all the above testing C++ code of construction dialog is generated from the wxFormBuilder 3.5 RC1.

asmwarrior

[PB]

Regarding the last crashing/asserting example code.

I may have got lost somewhere in the thread, but when I compile and run the most recent example, I get no crash. I also cannot see any image shift: screenshot?

I used slightly modified code to create a minimal self-contained example (still a long way to SSCE though) and used wxwin.png from the dnd sample as the bitmap.
My setup: wxWidgets master from 17.12.2015, VC 2008 Express, Win7 32-bit

#include <wx/wx.h>
#include <wx/listbook.h>

class MyDialog1 : public wxDialog
{
public:
    wxListbook *m_listbook1;
    wxPanel *m_panel6;    

    MyDialog1::MyDialog1()
        : wxDialog(NULL, wxID_ANY, "MyDialog")
    {

            this->SetSizeHints( wxDefaultSize, wxDefaultSize );

            wxBoxSizer* bSizer1;
            bSizer1 = new wxBoxSizer( wxVERTICAL );

            m_listbook1 = new wxListbook( this, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxLB_DEFAULT );
            wxSize m_listbook1ImageSize = wxSize( 80,80 );
            int m_listbook1Index = 0;
            wxImageList* m_listbook1Images = new wxImageList( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() );

            m_listbook1->AssignImageList( m_listbook1Images );
            wxBitmap m_listbook1Bitmap;
            wxImage m_listbook1Image;
            m_panel6 = new wxPanel( m_listbook1, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxTAB_TRAVERSAL );
            m_listbook1->AddPage( m_panel6, wxT("hihiihi"), false );

            m_listbook1Bitmap = wxBitmap( wxT("wxwin.png"), wxBITMAP_TYPE_ANY );
            if ( m_listbook1Bitmap.Ok() )

            {
                    m_listbook1Image = m_listbook1Bitmap.ConvertToImage();
                    m_listbook1Images->Add( m_listbook1Image.Scale( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() ) );

                    m_listbook1->SetPageImage( m_listbook1Index, m_listbook1Index );
                    m_listbook1Index++;
            }

            bSizer1->Add( m_listbook1, 1, wxEXPAND | wxALL, 5 );


            this->SetSizer( bSizer1 );
            this->Layout();

            this->Centre( wxBOTH );
    }

};

class MyApp : public wxApp
{
public:    
    virtual bool OnInit()
    {
        wxInitAllImageHandlers();
       
        MyDialog1 dlg;

        dlg.ShowModal();
        return false;
    }
};
IMPLEMENT_APP(MyApp)

[asmwarrior]

On 2016-1-21 14:58, PB wrote:
> Regarding the last crashing/asserting example code.
>

> I may have got lost somewhere in the thread, but when I compile and run the most recent example, I get no crash. I also cannot see any image shift: screenshot <http://imgur.com/tXzSWzf>?

>
> I used slightly modified code to create a minimal self-contained example (still a long way to SSCE though) and used wxwin.png from the dnd sample as the bitmap.
> My setup: wxWidgets master from 17.12.2015, VC 2008 Express, Win7 32-bit
>
> |
> #include<wx/wx.h>
> #include<wx/listbook.h>
>
> classMyDialog1:publicwxDialog
> {
> public:
> wxListbook *m_listbook1;
> wxPanel *m_panel6;
>
> MyDialog1::MyDialog1()
> :wxDialog(NULL,wxID_ANY,"MyDialog")
> {
> this->SetSizeHints(wxDefaultSize,wxDefaultSize );
>
> wxBoxSizer*bSizer1;
> bSizer1 =newwxBoxSizer(wxVERTICAL );
>
> m_listbook1 =newwxListbook(this,wxID_ANY,wxDefaultPosition,wxDefaultSize,wxLB_DEFAULT );
> wxSize m_listbook1ImageSize =wxSize(80,80);
> intm_listbook1Index =0;

> wxImageList*m_listbook1Images =newwxImageList(m_listbook1ImageSize..GetWidth(),m_listbook1ImageSize.GetHeight());
> m_listbook1->AssignImageList(m_listbook1Images );

> wxBitmap m_listbook1Bitmap;
> wxImage m_listbook1Image;
> m_panel6 =newwxPanel(m_listbook1,wxID_ANY,wxDefaultPosition,wxDefaultSize,wxTAB_TRAVERSAL );
> m_listbook1->AddPage(m_panel6,wxT("hihiihi"),false);
> m_listbook1Bitmap =wxBitmap(wxT("wxwin.png"),wxBITMAP_TYPE_ANY );
> if(m_listbook1Bitmap.Ok())
> {
> m_listbook1Image =m_listbook1Bitmap.ConvertToImage();
> m_listbook1Images->Add(m_listbook1Image.Scale(m_listbook1ImageSize.GetWidth(),m_listbook1ImageSize.GetHeight()));
> m_listbook1->SetPageImage(m_listbook1Index,m_listbook1Index );
> m_listbook1Index++;
> }
>
> bSizer1->Add(m_listbook1,1,wxEXPAND |wxALL,5);
>
>
> this->SetSizer(bSizer1 );
> this->Layout();
>
> this->Centre(wxBOTH );
> }
> };
>
> classMyApp:publicwxApp
> {
> public:
> virtualboolOnInit()
> {
> wxInitAllImageHandlers();
>
> MyDialog1dlg;
>
> dlg.ShowModal();
> returnfalse;
> }
> };
> IMPLEMENT_APP(MyApp)
> |
>
>
>
>

Hi, PB, thanks.
I can reproduce this issue on your code(you code does not build successfully, and I need to change ".." to "." and remove the "MyDialog1::", and use my own png file, so here is a minimal sample code to reproduce the shifted icon issue.

My environment is: windows xp, mingw-build 5.2, wx-git-master(cloned 2015-12-27).
Here is the code:

#include <wx/wx.h>
#include <wx/listbook.h>


class MyDialog1 : public wxDialog
{
public:
wxListbook *m_listbook1;
wxPanel *m_panel6;

MyDialog1()
: wxDialog(NULL, wxID_ANY, "MyDialog")
{
this->SetSizeHints( wxDefaultSize, wxDefaultSize );

wxBoxSizer* bSizer1;
bSizer1 = new wxBoxSizer( wxVERTICAL );

m_listbook1 = new wxListbook( this, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxLB_DEFAULT );
wxSize m_listbook1ImageSize = wxSize( 80,80 );
int m_listbook1Index = 0;
wxImageList* m_listbook1Images = new wxImageList( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() );
m_listbook1->AssignImageList( m_listbook1Images );
wxBitmap m_listbook1Bitmap;
wxImage m_listbook1Image;
m_panel6 = new wxPanel( m_listbook1, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxTAB_TRAVERSAL );
m_listbook1->AddPage( m_panel6, wxT("hihiihi"), false );

m_listbook1Bitmap = wxBitmap( wxT("compiler.png"), wxBITMAP_TYPE_ANY );

if ( m_listbook1Bitmap.Ok() )
{
m_listbook1Image = m_listbook1Bitmap.ConvertToImage();
m_listbook1Images->Add( m_listbook1Image.Scale( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() ) );
m_listbook1->SetPageImage( m_listbook1Index, m_listbook1Index );
m_listbook1Index++;
}

bSizer1->Add( m_listbook1, 1, wxEXPAND | wxALL, 5 );


this->SetSizer( bSizer1 );
this->Layout();

this->Centre( wxBOTH );
}
};

class MyApp : public wxApp
{
public:
virtual bool OnInit()
{
wxInitAllImageHandlers();

MyDialog1 dlg;

dlg.ShowModal();
return false;
}
};
IMPLEMENT_APP(MyApp)

And Here is the result screen shot (in attachment).

@VZ, I think this is the minimal sample to reproduce this bug.

Asmwarrior

[PB]

AsmWarrior,

FWIW I took the code from and verbatim pasted it into my VC2015 Express project. It was on a different computer than in my previous post, but the wxWidgets version and OS was the same; now I even used the compiler.png from C::B (SVN 10376).

Code compiled and run just fine. No crash, no image shift even when I tried running it in Windows XP Mode (Windows XP Virtual PC available for Win7 Pro users), still the same: http://i.imgur.com/HF8P87I.png

I have also pulled the current master from the GitHub, rebuild wxWidgets and your code. Everything still works as it did before.

So it looks to me like there is no problem with the code? Can you test it with a MS Visual C++ or perhaps also run it on another computer? I unfortunately do not have a working GCC wxWdgets build at hand atm...

PB

[Vadim Zeitlin]

On Thu, 21 Jan 2016 23:02:55 +0800 asmwarrior wrote:

a> I can reproduce this issue on your code(you code does not build
a> successfully, and I need to change ".." to "." and remove the
a> "MyDialog1::",

I'm not sure where there was a ".." in the original version, but I do see
the "MyDialog1::" problem, it's a MSVC bug (it should refuse to compile
such code but it allows it), but it doesn't change anything.

a> and use my own png file,

Do you mean that you can't reproduce the bug with another PNG file, e.g.
something returned from wxArtProvider (so that we could eliminate the
external file)?

a> @VZ, I think this is the minimal sample to reproduce this bug.

Could you please put the final version in a gist on GitHub to make it
easier to track it if you change it again (e.g. to get rid of the
compiler.png)? I'll try to test it with MinGW, it's not impossible that
it's compiler-dependent... Which version of MinGW (and which distribution,
i.e. MinGW-w64, TDM-GCC, something else?) do you use?

Thanks,

[asmwarrior]

On 2016-1-22 6:15, Vadim Zeitlin wrote:
> On Thu, 21 Jan 2016 23:02:55 +0800 asmwarrior wrote:
>
> a> I can reproduce this issue on your code(you code does not build
> a> successfully, and I need to change ".." to "." and remove the
> a> "MyDialog1::",
>
> I'm not sure where there was a ".." in the original version, but I do see
> the "MyDialog1::" problem, it's a MSVC bug (it should refuse to compile
> such code but it allows it), but it doesn't change anything.
>
> a> and use my own png file,
>
> Do you mean that you can't reproduce the bug with another PNG file, e.g.
> something returned from wxArtProvider (so that we could eliminate the
> external file)?

I think I can reproduce this issue by the wxArtProvider's icon. I have created a github gist test code, see here:

https://gist.github.com/asmwarrior/3d1e618a32789476fd59

>
> a> @VZ, I think this is the minimal sample to reproduce this bug.
>
> Could you please put the final version in a gist on GitHub to make it
> easier to track it if you change it again (e.g. to get rid of the
> compiler.png)? I'll try to test it with MinGW, it's not impossible that
> it's compiler-dependent... Which version of MinGW (and which distribution,
> i.e. MinGW-w64, TDM-GCC, something else?) do you use?
>
> Thanks,
> VZ

I use this one:

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/5.2.0/threads-posix/dwarf/i686-5.2.0-release-posix-dwarf-rt_v4-rev0.7z/download

I build the wx trunk with the following command: (I build a debug version of wx 3.x, because the release version of 3.0.2 wx will make C::B crash under windows xp)

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=debug UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-Wno-unused-local-typedefs -Wno-deprecated-declarations -fno-keep-inline-dllexport" >log-debug.txt 2>&1


I hope you can find the reason.

Asmwarrior

[Igor Korot]

Hi,

Can you try to build with MSVC?

Thank you.

>
>
> I hope you can find the reason.
>
> Asmwarrior
>
>

> --
> Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
>
> To unsubscribe, send email to wx-users+u...@googlegroups.com
> or visit http://groups.google.com/group/wx-users

[asmwarrior]

Hi, Sorry, I don't have any MSVC at hand...And MSVC is quite a big software, I'm not sure how slow it will run on my windows XP.

Asmwarrior

[asmwarrior]

On 2016-1-22 22:36, Igor Korot wrote:

> Hi,
>
> On Fri, Jan 22, 2016 at 9:03 AM, asmwarrior <asmwa...@gmail.com> wrote:
>> On 2016-1-22 6:15, Vadim Zeitlin wrote:
>>> On Thu, 21 Jan 2016 23:02:55 +0800 asmwarrior wrote:
>>>
>>> a> I can reproduce this issue on your code(you code does not build
>>> a> successfully, and I need to change ".." to "." and remove the
>>> a> "MyDialog1::",
>>>
>>> I'm not sure where there was a ".." in the original version, but I do see
>>> the "MyDialog1::" problem, it's a MSVC bug (it should refuse to compile
>>> such code but it allows it), but it doesn't change anything.
>>>
>>> a> and use my own png file,
>>>
>>> Do you mean that you can't reproduce the bug with another PNG file, e.g.
>>> something returned from wxArtProvider (so that we could eliminate the
>>> external file)?
>>
>> I think I can reproduce this issue by the wxArtProvider's icon. I have created a github gist test code, see here:
>>
>> https://gist.github.com/asmwarrior/3d1e618a32789476fd59
>>

I just tested by the wx-git-master HEAD:

SHA-1: a03df746f0573b374ddf06a69af969cbf2db850c

* Fix harmless parameter shadowing warnings

Rename local variables to avoid clashes with the function parameters.

Closes #17343, #17344.

And with the latest mingw-build version:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/5.3.0/threads-posix/dwarf/i686-5.3.0-release-posix-dwarf-rt_v4-rev0.7z/download

But I still get the same bad result. The icon looks like get re-sized, see attachment.

It looks like the icons are centered, but the image just does not show correctly.

Here is the test code:

#include <wx/wx.h>
#include <wx/listbook.h>


class MyDialog1 : public wxDialog
{
public:
wxListbook *m_listbook1;
wxPanel *m_panel6;

wxPanel *m_panel7;

MyDialog1()
: wxDialog(NULL, wxID_ANY, "MyDialog")
{
this->SetSizeHints( wxDefaultSize, wxDefaultSize );

wxBoxSizer* bSizer1;
bSizer1 = new wxBoxSizer( wxVERTICAL );

m_listbook1 = new wxListbook( this, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxLB_DEFAULT );
wxSize m_listbook1ImageSize = wxSize( 80,80 );
int m_listbook1Index = 0;
wxImageList* m_listbook1Images = new wxImageList( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() );
m_listbook1->AssignImageList( m_listbook1Images );
wxBitmap m_listbook1Bitmap;
wxImage m_listbook1Image;
m_panel6 = new wxPanel( m_listbook1, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxTAB_TRAVERSAL );

m_listbook1->AddPage( m_panel6, wxT("test11111 1111111111"), false );
m_panel7 = new wxPanel( m_listbook1, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxTAB_TRAVERSAL );
m_listbook1->AddPage( m_panel7, wxT("test22222 2222222222"), false );

m_listbook1Bitmap = wxBitmap( wxT("compiler.png"), wxBITMAP_TYPE_ANY );
if ( m_listbook1Bitmap.Ok() )
{
m_listbook1Image = m_listbook1Bitmap.ConvertToImage();
m_listbook1Images->Add( m_listbook1Image.Scale( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() ) );

m_listbook1->SetPageImage( 0, 0 );
m_listbook1->SetPageImage( 1, 0 );

}

bSizer1->Add( m_listbook1, 1, wxEXPAND | wxALL, 5 );


this->SetSizer( bSizer1 );
this->Layout();

this->Centre( wxBOTH );
}
};

class MyApp : public wxApp
{
public:
virtual bool OnInit()
{
wxInitAllImageHandlers();

MyDialog1 dlg;

dlg.ShowModal();
return false;
}
};
IMPLEMENT_APP(MyApp)

And the 80*80 icon png file is also in attachment.

Thanks.

Asmwarrior

[asmwarrior]

FYI, today, I have a bad news, because I see this issue on our wx 2.8.12 based C::B release, see this post:

Bad icons of C::B in the 16.01 release - http://forums.codeblocks.org/index.php/topic,20871.msg142502/topicseen.html#msg142502

So, this is an issue which exists for a long time.

Asmwarrior

[Catalin]

Hello,

The attached patch to minimal sample shows what could be the same issue.

To see the issue apply the patch, run the sample, enlarge the main frame until the vertical scrollbar disappears, then slowly shrink it until the vertical scrollbar is needed again. I see an intense scrollbar flicker, and after that sometimes the list is correctly shown but after the immediately following size event the images look badly aligned. So you get a 50-50% chances of catching either behaviour.
One problem is with the toolbar flicker, which leads to another painting issue that makes the listbook look like it is wider than it really is.

I've used for this wxW-trunk (November 2015) and MSVC 2013.

Regards,
C

[asmwarrior]

Hi, Catalin, I can confirm this bug, thanks.
But I'm not sure this is exactly the one I original reported. The long text "test11111 1111111111" are still in the same line in your test code, while in my original bug report, the long text were just wrapped, and they became two lines, see the image shot in my post: http://forums.codeblocks.org/index.php/topic,20871.0.html

I'm testing it under wx-git-master(I pulled yesterday), and mingw-build gcc 5.3 compiler(from mingw-w64 sourceforge site), windows XP sp3.
I attach three screen shots, and it looks like the 2.png is the bug, right?


Asmwarrior

[Vadim Zeitlin]

On Sun, 24 Jan 2016 08:59:50 +0000 (UTC) 'Catalin' via wx-users wrote:

Cvwu> The attached patch to minimal sample shows what could be the same issue.
Cvwu>
Cvwu> To see the issue apply the patch, run the sample, enlarge the main
Cvwu> frame until the vertical scrollbar disappears, then slowly shrink it
Cvwu> until the vertical scrollbar is needed again. I see an intense
Cvwu> scrollbar flicker, and after that sometimes the list is correctly
Cvwu> shown but after the immediately following size event the images look
Cvwu> badly aligned. So you get a 50-50% chances of catching either
Cvwu> behaviour. One problem is with the toolbar flicker, which leads to
Cvwu> another painting issue that makes the listbook look like it is wider
Cvwu> than it really is.

Hi,

Thanks for the patch, I do indeed see the problem with it. AFAICS there
are in fact 2 problems: the first one is that wxListCtrl is made too wide
when relying on its width-from-height computation (it would be the same in
the other direction, i.e. too tall for the given width, too) because we
account for the size of its borders twice. This seems to be the originally
reported bug which results in a shift by 4 pixels which, while hardly
catastrophic, is indeed annoying. But this is easy to fix and I just did it
in a358c898c55bcda640cfc21da2fa7fbca663914c: Asmwarrior, please let me know
if it fixes your problem.

The second problem is with the incorrect control size due to scrollbar
hysteresis. This one is more mysterious and is difficult to debug. I am not
sure what exactly is going on here, but I suspect we might need to stop
relying on WS_[HV]SCROLL flag bits which don't seem to be always getting
set in sync, and use GetItemRect() to check if the last item fits into the
returned space. Unfortunately I ran out of time to try this today and I'm
not sure when I'm going to be able to get back to it, so if somebody wants
to try doing it, it would be most welcome.

Regards,

[Igor Korot]

Vadim et al,

In the meantime it would be nice if someone check the trac and open a new ticket
for a second issue if its not already there.

Thank you.

[asmwarrior]

On 2016-1-25 9:57, Vadim Zeitlin wrote:
> On Sun, 24 Jan 2016 08:59:50 +0000 (UTC) 'Catalin' via wx-users wrote:
>
> Cvwu> The attached patch to minimal sample shows what could be the same issue.
> Cvwu>
> Cvwu> To see the issue apply the patch, run the sample, enlarge the main
> Cvwu> frame until the vertical scrollbar disappears, then slowly shrink it
> Cvwu> until the vertical scrollbar is needed again. I see an intense
> Cvwu> scrollbar flicker, and after that sometimes the list is correctly
> Cvwu> shown but after the immediately following size event the images look
> Cvwu> badly aligned. So you get a 50-50% chances of catching either
> Cvwu> behaviour. One problem is with the toolbar flicker, which leads to
> Cvwu> another painting issue that makes the listbook look like it is wider
> Cvwu> than it really is.
>
> Hi,
>
> Thanks for the patch, I do indeed see the problem with it. AFAICS there
> are in fact 2 problems: the first one is that wxListCtrl is made too wide
> when relying on its width-from-height computation (it would be the same in
> the other direction, i.e. too tall for the given width, too) because we
> account for the size of its borders twice. This seems to be the originally
> reported bug which results in a shift by 4 pixels which, while hardly
> catastrophic, is indeed annoying. But this is easy to fix and I just did it
> in a358c898c55bcda640cfc21da2fa7fbca663914c: Asmwarrior, please let me know
> if it fixes your problem.
>

Thanks!
I just pull the wx git repo, and build the wx library, and rebuild c::b.
I see my reported issue still exists.

Asmwarrior

[Vadim Zeitlin]

On Mon, 25 Jan 2016 22:19:49 +0800 asmwarrior wrote:

a> I just pull the wx git repo, and build the wx library, and rebuild c::b.
a> I see my reported issue still exists.

I'd really like to reduce the amount of uncertainty here, so could you
please check if this fixes the problem with the extra pixels in Catalin's
example for you first?

Also, perhaps I'm misunderstanding you from the beginning: what exactly is
the problem you're trying to fix? I saw that the icon was offset by 2
pixels horizontally due to the extra 4 pixels being added to the control
width compared to its best width. Are you speaking about the same thing or
something else entirely?

[asm warrior]

2016-1-25 下午11:17，"Vadim Zeitlin" <va...@wxwidgets.org>写道：
>
> On Mon, 25 Jan 2016 22:19:49 +0800 asmwarrior wrote:
>
> a> I just pull the wx git repo, and build the wx library, and rebuild c::b.
> a> I see my reported issue still exists.
>
>  I'd really like to reduce the amount of uncertainty here, so could you
> please check if this fixes the problem with the extra pixels in Catalin's
> example for you first?

OK, I will test and report back.
I use phone now.

>
>  Also, perhaps I'm misunderstanding you from the beginning: what exactly is
> the problem you're trying to fix? I saw that the icon was offset by 2
> pixels horizontally due to the extra 4 pixels being added to the control
> width compared to its best width. Are you speaking about the same thing or
> something else entirely?
>

There are three issues in my original post.
1. icon get shifted
2. icon get resized, so it's blur
3. the label text under icon get wrapped

THANKS

asmwarrior

[Igor Korot]

asmwarrior/Vadim,

Is ticket 4379 covers one of this problem?

Thank you.

>
> THANKS
>
> asmwarrior

[asmwarrior]

Hi, Igor Korot, thanks.

I just create a minimal sample code to run the test code in http://trac.wxwidgets.org/ticket/4379
(BTW: the associated forum discussion is: https://forums.wxwidgets.org/viewtopic.php?f=1&t=15999)

Here is the code: (I just merge the .h and .cpp file in one cpp file, see below)
---------------------------------------------
#include <wx/wx.h>
#include <wx/listbook.h>


#include <wx/dialog.h>

class wxCheckBox;
class wxSpinCtrl;
class wxListbook;
class wxComboBox;

#define BFSETTINGSDLG_ID_BUTTONOK 1 + wxID_HIGHEST
#define BFSETTINGSDLG_ID_BUTTONCANCEL 2 + wxID_HIGHEST

///
class BFSettingsDlg2 : public wxDialog
{
private:

public:
/// constructor
BFSettingsDlg2 (wxWindow* pParent);

/// virtual destructor
virtual ~BFSettingsDlg2 ();

///
void OnClose (wxCloseEvent& event);

DECLARE_EVENT_TABLE();
}; // class BFSettingsDlg2


#include <wx/listbook.h>
#include <wx/button.h>
#include <wx/sizer.h>
#include <wx/checkbox.h>
#include <wx/stattext.h>
#include <wx/spinctrl.h>
#include <wx/listctrl.h>
#include <wx/imaglist.h>
#include <wx/statline.h>
#include <wx/treebook.h>
#include <limits.h>

BEGIN_EVENT_TABLE(BFSettingsDlg2, wxDialog)
EVT_CLOSE (BFSettingsDlg2::OnClose)
END_EVENT_TABLE()

//
BFSettingsDlg2::BFSettingsDlg2 (wxWindow* pParent)
: wxDialog(pParent, wxID_ANY, wxString(_("Global Settings")))
{
// the book
wxTreebook* pBook = new wxTreebook(this,
wxID_ANY,
wxDefaultPosition,
wxDefaultSize,
wxNB_LEFT);

// *** PROJECT-page ***
wxPanel* pPageProject = new wxPanel(pBook);
wxBoxSizer* pPageProjectSizerTop = new wxBoxSizer(wxVERTICAL);

// custom ctrl
wxPanel* pPrjCtrl = new wxPanel(pPageProject);
wxStaticBoxSizer* pStopStaticSizer = new wxStaticBoxSizer(wxVERTICAL, pPrjCtrl);
wxStaticText* pLabelA = new wxStaticText(pPrjCtrl, wxID_ANY, _("ABCD"));
pStopStaticSizer->Add(pLabelA, wxSizerFlags(0).Expand());
pPrjCtrl->SetSizer(pStopStaticSizer);

pPageProjectSizerTop->Add(pPrjCtrl, wxSizerFlags(0).Expand());
pPageProject->SetSizer(pPageProjectSizerTop);
pBook->AddPage(pPageProject, _("Default Project"));

// sizer and arrange
wxBoxSizer* pDlgSizer = new wxBoxSizer(wxVERTICAL);
pDlgSizer->Add(pBook, wxSizerFlags(0).Expand().Border());
SetSizerAndFit(pDlgSizer);
ShowModal();
}


//
/*virtual*/ BFSettingsDlg2::~BFSettingsDlg2 ()
{
}


void BFSettingsDlg2::OnClose (wxCloseEvent& event)
{
Destroy();

}

class MyApp : public wxApp
{
public:
virtual bool OnInit()
{
wxInitAllImageHandlers();

BFSettingsDlg2 dlg(NULL);

dlg.ShowModal();
return false;
}
};
IMPLEMENT_APP(MyApp)
---------------------------------------------

I don't see any issue here, see the screen shot as attachment.

So, I think it is not related to my reported issue.

Asmwarrior

[asmwarrior]

On 2016-1-25 23:16, Vadim Zeitlin wrote:
> On Mon, 25 Jan 2016 22:19:49 +0800 asmwarrior wrote:
>
> a> I just pull the wx git repo, and build the wx library, and rebuild c::b.
> a> I see my reported issue still exists.
>
> I'd really like to reduce the amount of uncertainty here, so could you
> please check if this fixes the problem with the extra pixels in Catalin's
> example for you first?
>

Just tested, and I still see the Catalin reported issue. I mean sometimes, I see see the extra whitespace in the right margin(at this time, no scroll bar is shown)

Asmwarrior

[Vadim Zeitlin]

On Tue, 26 Jan 2016 10:26:28 +0800 asm warrior wrote:

aw> There are three issues in my original post.
aw> 1. icon get shifted
aw> 2. icon get resized, so it's blur
aw> 3. the label text under icon get wrapped

I don't think (2) is a problem at all, i.e. this is the expected behaviour
AFAICS. I didn't realize (3) was a problem. But (1) should be fixed by my
change.

On Tue, 26 Jan 2016 21:10:11 +0800 asmwarrior wrote:

a> On 2016-1-25 23:16, Vadim Zeitlin wrote:

a> > On Mon, 25 Jan 2016 22:19:49 +0800 asmwarrior wrote:
a> >

a> > a> I just pull the wx git repo, and build the wx library, and rebuild c::b.
a> > a> I see my reported issue still exists.
a> >
a> > I'd really like to reduce the amount of uncertainty here, so could you
a> > please check if this fixes the problem with the extra pixels in Catalin's
a> > example for you first?
a>
a> Just tested, and I still see the Catalin reported issue. I mean
a> sometimes, I see see the extra whitespace in the right margin(at this
a> time, no scroll bar is shown)

Yes, I explicitly wrote that this bug still remains. Again, my fix was for
your problem (1) above only.

Anyhow, to go forward, it would be great if you could produce the same
patch as Catalin made for your issue (3). Although, to be honest, this
seems like a rather low priority problem to me.

[asmwarrior]

HI, VZ, it looks like my reported issues (1,2,3) only exist on Windows XP, and I have the same program (the Code::Blocks release 16.01) has different results. On WinXP, it has the issues, but it does not have issues on Windows 7(64bit) system.

Asmwarrior

[Vadim Zeitlin]

On Thu, 04 Feb 2016 10:36:10 +0800 asmwarrior wrote:

a> HI, VZ, it looks like my reported issues (1,2,3) only exist on Windows
a> XP, and I have the same program (the Code::Blocks release 16.01) has
a> different results. On WinXP, it has the issues, but it does not have
a> issues on Windows 7(64bit) system.

Sorry, I'm afraid I just can't muster the motivation to debug XP-specific
problems. Any patches would still be welcome, of course, as long as we
support it, but I don't have any users under XP since a very long time any
more...

[asmwarrior]

On 2016-2-4 11:03, Vadim Zeitlin wrote:
> On Thu, 04 Feb 2016 10:36:10 +0800 asmwarrior wrote:
>
> a> HI, VZ, it looks like my reported issues (1,2,3) only exist on Windows
> a> XP, and I have the same program (the Code::Blocks release 16.01) has
> a> different results. On WinXP, it has the issues, but it does not have
> a> issues on Windows 7(64bit) system.
>
> Sorry, I'm afraid I just can't muster the motivation to debug XP-specific
> problems. Any patches would still be welcome, of course, as long as we
> support it, but I don't have any users under XP since a very long time any
> more...
>
> Regards,
> VZ
>

Hi, VZ, I think I have found one reason of my reported issue under Windows XP. That is the transparent png.

I just did a simple test. My original "compiler.png" is a transparent png, and it shows badly in the listbook's icon.
But if I save the "compiler.png" as "compiler.bmp", and load the "compiler.bmp" in my test app, the result is quite good.

See the attachment screen shots.
Does this means the Windows XP listctrl does not support transparent bitmaps correctly?

Thanks.

Asmwarrior

[Vadim Zeitlin]

On Thu, 04 Feb 2016 22:00:34 +0800 asmwarrior wrote:

a> Does this means the Windows XP listctrl does not support transparent
a> bitmaps correctly?

There is code in wxImageList::Add() explicitly clearing alpha channel when
using comctl32.dll < 6, so if you use "classic theme", this could indeed be
the case. OTOH the commit 89422628 which changed this, did it only for the
toolbars (see Trac #2609), so perhaps it could still work for the list
view, you could try reverting this commit locally and checking what does it
give...

[asmwarrior]

On 2016-2-4 23:49, Vadim Zeitlin wrote:
> On Thu, 04 Feb 2016 22:00:34 +0800 asmwarrior wrote:
>
> a> Does this means the Windows XP listctrl does not support transparent
> a> bitmaps correctly?
>
> There is code in wxImageList::Add() explicitly clearing alpha channel when
> using comctl32.dll < 6, so if you use "classic theme", this could indeed be
> the case. OTOH the commit 89422628 which changed this, did it only for the
> toolbars (see Trac #2609), so perhaps it could still work for the list
> view, you could try reverting this commit locally and checking what does it
> give...
>
> Regards,
> VZ
>

OK, thanks, and I think the alpha channel is not that important than the listview width issue.

I just see two screen shots of C::B's listbook(that's based on wx2.8.12, no alpha channel related issue here), but I see that sometimes, the column is too narrow, and sometimes, it looks good.

You can see the two screen shots in our C::B forum:
http://forums.codeblocks.org/index.php/topic,20871.msg142927.html#msg142927

I'm trying to fix this issue, but can you give me any suggestions? It looks like in my case, the function:

wxSize wxListCtrl::MSWGetBestViewRect(int x, int y) gives wrong size?

as you commit a358c898c55bcda640cfc21da2fa7fbca663914c.

Asmwarrior

[asmwarrior]

For wx3 I just debugged, I see the column width is 141, see the image shot:
http://forums.codeblocks.org/index.php/topic,20871.msg142928.html#msg142928

For the function:

wxSize wxListCtrl::MSWGetBestViewRect(int x, int y) const
{
const DWORD rc = ListView_ApproximateViewRect(GetHwnd(), x, y, NO_ITEM);

wxSize size(LOWORD(rc), HIWORD(rc));

// We have to add space for the scrollbars ourselves, they're not taken
// into account by ListView_ApproximateViewRect(), at least not with
// commctrl32.dll v6.
const DWORD mswStyle = ::GetWindowLong(GetHwnd(), GWL_STYLE);

if ( mswStyle & WS_HSCROLL )
size.y += wxSystemSettings::GetMetric(wxSYS_HSCROLL_Y);
if ( mswStyle & WS_VSCROLL )
size.x += wxSystemSettings::GetMetric(wxSYS_VSCROLL_X);

// OTOH we have to subtract the size of our borders because the base class
// public method already adds them, but ListView_ApproximateViewRect()
// already takes the borders into account, so this would be superfluous.
return size - DoGetBorderSize();
}

The original size.x value is always 125, and add the scroll bar width, I get 141, but I think we need 146. As shown in my post:
http://forums.codeblocks.org/index.php/topic,20871.msg142927.html#msg142927

Asmwarrior

[Vadim Zeitlin]

On Sat, 06 Feb 2016 13:53:07 +0800 asmwarrior wrote:

a> I just see two screen shots of C::B's listbook(that's based on wx2.8.12,
a> no alpha channel related issue here), but I see that sometimes, the
a> column is too narrow, and sometimes, it looks good.
a>
a> You can see the two screen shots in our C::B forum:
a> http://forums.codeblocks.org/index.php/topic,20871.msg142927.html#msg142927
a>
a> I'm trying to fix this issue, but can you give me any suggestions? It
a> looks like in my case, the function:
a>
a> wxSize wxListCtrl::MSWGetBestViewRect(int x, int y) gives wrong size?
a>
a> as you commit a358c898c55bcda640cfc21da2fa7fbca663914c.

I don't think this commit is the problem, the difference you see is much
greater than 4 pixels corresponding to the border width, isn't it?

On Sat, 06 Feb 2016 14:19:51 +0800 asmwarrior wrote:

a> For wx3 I just debugged, I see the column width is 141, see the image shot:
a> http://forums.codeblocks.org/index.php/topic,20871.msg142928.html#msg142928
a>
a> For the function:
a>
a> wxSize wxListCtrl::MSWGetBestViewRect(int x, int y) const
a> {
a> const DWORD rc = ListView_ApproximateViewRect(GetHwnd(), x, y, NO_ITEM);
a>
a> wxSize size(LOWORD(rc), HIWORD(rc));
a>
a> // We have to add space for the scrollbars ourselves, they're not taken
a> // into account by ListView_ApproximateViewRect(), at least not with
a> // commctrl32.dll v6.
a> const DWORD mswStyle = ::GetWindowLong(GetHwnd(), GWL_STYLE);
a>
a> if ( mswStyle & WS_HSCROLL )
a> size.y += wxSystemSettings::GetMetric(wxSYS_HSCROLL_Y);
a> if ( mswStyle & WS_VSCROLL )
a> size.x += wxSystemSettings::GetMetric(wxSYS_VSCROLL_X);
a>
a> // OTOH we have to subtract the size of our borders because the base class
a> // public method already adds them, but ListView_ApproximateViewRect()
a> // already takes the borders into account, so this would be superfluous.
a> return size - DoGetBorderSize();
a> }
a>
a> The original size.x value is always 125, and add the scroll bar width, I
a> get 141, but I think we need 146. As shown in my post:
a> http://forums.codeblocks.org/index.php/topic,20871.msg142927.html#msg142927

So does it work for you if you undo the commit a358c8 mentioned above? If
so, we could avoid doing it for XP as ListView_ApproximateViewRect() could
be working differently there (or maybe not even XP but, rather, pre v6
comctl32.dll which you seem to be using, don't you?).

[asmwarrior]

Thanks, VZ. It looks like commit a358c8 does not change the wrong behavior.

I change the function like below to ensure the width is much bigger than 146.

wxSize wxListCtrl::MSWGetBestViewRect(int x, int y) const

{

const DWORD rc = ListView_ApproximateViewRect(GetHwnd(), x, y, NO_ITEM);

wxSize size(LOWORD(rc), HIWORD(rc));

// We have to add space for the scrollbars ourselves, they're not taken

// into account by ListView_ApproximateViewRect(), at least not with

// commctrl32.dll v6.

const DWORD mswStyle = ::GetWindowLong(GetHwnd(), GWL_STYLE);

if ( mswStyle & WS_HSCROLL )

size.y += wxSystemSettings::GetMetric(wxSYS_HSCROLL_Y);

if ( mswStyle & WS_VSCROLL )

size.x += wxSystemSettings::GetMetric(wxSYS_VSCROLL_X);

// OTOH we have to subtract the size of our borders because the base class

// public method already adds them, but ListView_ApproximateViewRect()

// already takes the borders into account, so this would be superfluous.

return size + 2*DoGetBorderSize();
}

But I still get bad icons, see image shot in attachment.
The window width is 153 pixel now. It is 141 + 3 * DoGetBorderSize().

The main issue is that the "text label" under the icon is wrapped, this is not the expect behaviour.

Asmwarrior

[Vadim Zeitlin]

On Sun, 07 Feb 2016 10:08:19 +0800 asmwarrior wrote:

a> The main issue is that the "text label" under the icon is wrapped, this
a> is not the expect behaviour.

Sorry, I really don't know what to do about this. If it worked fine in
2.8, your best bet is to try to find the differences between listctrl.cpp
in that version and 3.0 and see if you can find the change which broke
this.

[asmwarrior]

On 2016-2-7 21:15, Vadim Zeitlin wrote:
> On Sun, 07 Feb 2016 10:08:19 +0800 asmwarrior wrote:
>
> a> The main issue is that the "text label" under the icon is wrapped, this
> a> is not the expect behaviour.
>
> Sorry, I really don't know what to do about this. If it worked fine in
> 2.8, your best bet is to try to find the differences between listctrl.cpp
> in that version and 3.0 and see if you can find the change which broke
> this.
>
> Regards,
> VZ
>

Hi, VZ, the text label wrapped issue happens in both wx 3.0 and wx 2.8 on my Windows XP.
I have find some reasons that why the text label get wrapped(I will post it in another email post), but before that, I would like to report an minimal sample code to reproduce a crash issue of wxListbook on my system.

I attach a patch file against our minimal.cpp file in wx git master code base. This patch is just a slightly changed version of Catalin's patch on our discussion.

With my patch, there are two places we create a wxListbook, one is in the main frame which is added by Catalin's patch, and it works fine here.
What I try to do is just use quite similar code in the constructor of a wxDialog. (You can open the dialog by clicking the about menu item)
In my test, I get a crash if I want to create the wxListbook inside the constructor of wxDialog.

Here is the crash call stack:

[debug]Program received signal SIGSEGV, Segmentation fault.
[debug]0x007a9709 in wxListbook::SetImageList (this=0xe850720, imageList=0xe8514d8) at F:\wx\wxWidgets_trunk\src\generic\listbkg.cpp:277
[debug] F:\wx\wxWidgets_trunk\src\generic\listbkg.cpp:277:8473:beg:0x7a9709
[debug]>>>>>>cb_gdb:

Program received signal SIGSEGV, Segmentation fault.
At F:\wx\wxWidgets_trunk\src\generic\listbkg.cpp:277

[debug]> bt 30
[debug]#0 0x007a9709 in wxListbook::SetImageList (this=0xe850720, imageList=0xe8514d8) at F:\wx\wxWidgets_trunk\src\generic\listbkg.cpp:277
[debug]#1 0x00405135 in wxWithImages::AssignImageList (this=0xe8508ac, imageList=0xe8514d8) at F:\wx\wxWidgets_trunk\include\wx\withimages.h:50
[debug]#2 0x004042d0 in TestDialog::TestDialog (this=0x22f430, parent=0xe84d9d0) at F:\wx\wxWidgets_trunk\samples\minimal\minimal.cpp:56
[debug]#3 0x004021da in MyFrame::OnAbout (this=0xe84d9d0) at F:\wx\wxWidgets_trunk\samples\minimal\minimal.cpp:245
[debug]#4 0x0052387a in wxAppConsoleBase::HandleEvent (this=0xe83b7a8, handler=0xe84d9d0, func=(void (wxEvtHandler::*)(wxEvtHandler * const, wxEvent &)) 0x4021b4 <MyFrame::OnAbout(wxCommandEvent&)>, event=...) at F:\wx\wxWidgets_trunk\src\common\appbase.cpp:657
[debug]#5 0x005238d6 in wxAppConsoleBase::CallEventHandler (this=0xe83b7a8, handler=0xe84d9d0, functor=..., event=...) at F:\wx\wxWidgets_trunk\src\common\appbase.cpp:669
[debug]#6 0x005ec52b in wxEvtHandler::ProcessEventIfMatchesId (entry=..., handler=0xe84d9d0, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1381
[debug]#7 0x005eb563 in wxEventHashTable::HandleEvent (this=0x41306c <MyFrame::sm_eventHashTable>, event=..., self=0xe84d9d0) at F:\wx\wxWidgets_trunk\src\common\event.cpp:989
[debug]#8 0x005ec99b in wxEvtHandler::TryHereOnly (this=0xe84d9d0, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1578
[debug]#9 0x00c373d4 in wxEvtHandler::TryBeforeAndHere (this=0xe84d9d0, event=...) at F:\wx\wxWidgets_trunk\include\wx\event.h:3662
[debug]#10 0x005ec7e7 in wxEvtHandler::ProcessEventLocally (this=0xe84d9d0, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1511
[debug]#11 0x005ec788 in wxEvtHandler::ProcessEvent (this=0xe84d9d0, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1484
[debug]#12 0x00790bef in wxWindowBase::TryAfter (this=0xe84e2c0, event=...) at F:\wx\wxWidgets_trunk\src\common\wincmn.cpp:3468
[debug]#13 0x005ec7b3 in wxEvtHandler::ProcessEvent (this=0xe84e2c0, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1497
[debug]#14 0x005eca27 in wxEvtHandler::SafelyProcessEvent (this=0xe84e2c0, event=...) at F:\wx\wxWidgets_trunk\src\common\event.cpp:1602
[debug]#15 0x0078bc3c in wxWindowBase::HandleWindowEvent (this=0xe84e2c0, event=...) at F:\wx\wxWidgets_trunk\src\common\wincmn.cpp:1542
[debug]#16 0x007517c1 in wxMenuBase::DoProcessEvent (menu=0xe83f520, event=..., win=0xe84d9d0) at F:\wx\wxWidgets_trunk\src\common\menucmn.cpp:676
[debug]#17 0x0075170a in wxMenuBase::SendEvent (this=0xe83f520, itemid=5014, checked=-1) at F:\wx\wxWidgets_trunk\src\common\menucmn.cpp:646
[debug]#18 0x00714bed in wxFrameBase::ProcessCommand (this=0xe84d9d0, item=0xe84e130) at F:\wx\wxWidgets_trunk\src\common\framecmn.cpp:294
[debug]#19 0x00685ae6 in wxFrame::HandleCommand (this=0xe84d9d0, id=5014, cmd=0, control=0x0) at F:\wx\wxWidgets_trunk\src\msw\frame.cpp:799
[debug]#20 0x00685ce0 in wxFrame::MSWWindowProc (this=0xe84d9d0, message=273, wParam=5014, lParam=0) at F:\wx\wxWidgets_trunk\src\msw\frame.cpp:849
[debug]#21 0x0065aa03 in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 (hWnd=0x60462, message=273, wParam=5014, lParam=0) at F:\wx\wxWidgets_trunk\src\msw\window.cpp:2649
[debug]#22 0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#23 0x00060462 in ?? ()
[debug]#24 0x00000111 in ?? ()
[debug]#25 0x00001396 in ?? ()
[debug]#26 0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:



Looked at the code, I see the list pointer is 0 in the following function:

void wxListbook::SetImageList(wxImageList *imageList)
{
const long flagsOld = GetListCtrlFlags();

wxBookCtrlBase::SetImageList(imageList);

const long flagsNew = GetListCtrlFlags();

wxListView * const list = GetListView();

// We may need to change the list control mode if the image list presence
// has changed.
if ( flagsNew != flagsOld )
{
// Preserve the selection which is lost when changing the mode
const int oldSel = GetSelection();

list->SetWindowStyleFlag(flagsNew);
if ( list->InReportView() )
list->InsertColumn(0, wxS("Pages"));

// Restore selection
if ( oldSel != wxNOT_FOUND )
SetSelection(oldSel);
}

list->SetImageList(imageList, wxIMAGE_LIST_NORMAL);
}

So, the crash happens when I call the function:
listbook1->AssignImageList(listbook1Images);

From what I'm debugging, It looks like the wxListctrl is not constructed yet when I try to assign the image list.
(It looks like the wxListctrl(inside the wxListbook) is initially created in non-icon mode, and once some images were added, it just change some MSW windows styles, so that it becomes the icon mode, no re-creation happens about such mode change)

But the strange thing is that the quite similar code works OK inside the MyFrame's constructor.
Any hint about this?
Thanks.

Asmwarrior

[asmwarrior]

On 2016-2-9 22:32, asmwarrior wrote:
> On 2016-2-7 21:15, Vadim Zeitlin wrote:
>> On Sun, 07 Feb 2016 10:08:19 +0800 asmwarrior wrote:
>>
>> a> The main issue is that the "text label" under the icon is wrapped, this
>> a> is not the expect behaviour.
>>
>> Sorry, I really don't know what to do about this. If it worked fine in
>> 2.8, your best bet is to try to find the differences between listctrl.cpp
>> in that version and 3.0 and see if you can find the change which broke
>> this.
>>
>> Regards,
>> VZ
>>
> Hi, VZ, the text label wrapped issue happens in both wx 3.0 and wx 2.8 on my Windows XP.
> I have find some reasons that why the text label get wrapped(I will post it in another email post), but before that, I would like to report an minimal sample code to reproduce a crash issue of wxListbook on my system.

Now, in this post, I will give some reasons about why the text label get wrapped in the wxListbook.
The point is that the position of the function call "AssignImageList".

I did this test inside our C::B's menu event handler, it at least does not crash here, as you see in my previous post, it just crashed when I try to create a wxDialog which contains a wxListbook.

Now, if I have such code in the constructor of the wxDialog:

this->SetSizeHints( wxDefaultSize, wxDefaultSize );

wxBoxSizer* bSizer1;
bSizer1 = new wxBoxSizer( wxVERTICAL );

m_listbook1 = new wxListbook( this, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxLB_DEFAULT );
wxSize m_listbook1ImageSize = wxSize( 80,80 );
int m_listbook1Index = 0;
wxImageList* m_listbook1Images = new wxImageList( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() );

wxBitmap m_listbook1Bitmap;
wxImage m_listbook1Image;
m_panel6 = new wxPanel( m_listbook1, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxTAB_TRAVERSAL );
m_listbook1->AddPage( m_panel6, wxT("test11111 1111111111"), false );

m_listbook1Bitmap = wxBitmap( wxT("compiler.png"), wxBITMAP_TYPE_ANY );
if ( m_listbook1Bitmap.Ok() )
{
m_listbook1Image = m_listbook1Bitmap.ConvertToImage();
m_listbook1Images->Add( m_listbook1Image.Scale( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() ) );

m_listbook1->SetPageImage( m_listbook1Index, m_listbook1Index );
m_listbook1Index++;
}
m_listbook1->AssignImageList( m_listbook1Images );// ********************************************

bSizer1->Add( m_listbook1, 1, wxEXPAND | wxALL, 5 );


this->SetSizer( bSizer1 );
this->Layout();

this->Centre( wxBOTH );

Then, I get a wrapped text label, see image shot 1 in attachment.

But if I have such code:

this->SetSizeHints( wxDefaultSize, wxDefaultSize );

wxBoxSizer* bSizer1;
bSizer1 = new wxBoxSizer( wxVERTICAL );

m_listbook1 = new wxListbook( this, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxLB_DEFAULT );
wxSize m_listbook1ImageSize = wxSize( 80,80 );
int m_listbook1Index = 0;
wxImageList* m_listbook1Images = new wxImageList( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() );

m_listbook1->AssignImageList( m_listbook1Images );//***********************************************

wxBitmap m_listbook1Bitmap;
wxImage m_listbook1Image;
m_panel6 = new wxPanel( m_listbook1, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxTAB_TRAVERSAL );
m_listbook1->AddPage( m_panel6, wxT("test11111 1111111111"), false );

m_listbook1Bitmap = wxBitmap( wxT("compiler.png"), wxBITMAP_TYPE_ANY );
if ( m_listbook1Bitmap.Ok() )
{
m_listbook1Image = m_listbook1Bitmap.ConvertToImage();
m_listbook1Images->Add( m_listbook1Image.Scale( m_listbook1ImageSize.GetWidth(), m_listbook1ImageSize.GetHeight() ) );

m_listbook1->SetPageImage( m_listbook1Index, m_listbook1Index );
m_listbook1Index++;

}

bSizer1->Add( m_listbook1, 1, wxEXPAND | wxALL, 5 );


this->SetSizer( bSizer1 );
this->Layout();

this->Centre( wxBOTH );

You see a quite good text label, see image shot 2 in attachment.

Any ideas?

Asmwarrior

[Vadim Zeitlin]

On Tue, 09 Feb 2016 22:32:02 +0800 asmwarrior wrote:

a> In my test, I get a crash if I want to create the wxListbook inside the
a> constructor of wxDialog.

You don't create your dialog correctly (or at all), so creating all
windows using it as parent fails. IOW this is just a bug in your testing
code, add ": wxDialog(parent)" to TestDialog ctor to fix it.

[Vadim Zeitlin]

On Tue, 09 Feb 2016 22:43:51 +0800 asmwarrior wrote:

a> Now, in this post, I will give some reasons about why the text label get
a> wrapped in the wxListbook. The point is that the position of the
a> function call "AssignImageList".

So it looks like it's a bad idea to use images before defining them. This
seems pretty logical to me, doesn't it? I.e. it's not really surprising
that the control can't compute the proper size of its images (which it
clearly uses to decide whether to wrap the text or not) if you don't give
the images to it until it's too late.

a> Any ideas?

I'm really not sure I understand the question. You've found that misusing
the API by using the not yet defined image indices exposes a bug. This is
good to know and we should add checks for this, e.g. assert that we have a
valid image list if any image indices are different from -1. But for your
purpose all you need to do is to use the API correctly and set the image
list first.

Is there something I'm missing here?

[asmwarrior]

On 2016-2-9 22:34, Vadim Zeitlin wrote:
> On Tue, 09 Feb 2016 22:32:02 +0800 asmwarrior wrote:
>
> a> In my test, I get a crash if I want to create the wxListbook inside the
> a> constructor of wxDialog.
>
> You don't create your dialog correctly (or at all), so creating all
> windows using it as parent fails. IOW this is just a bug in your testing
> code, add ": wxDialog(parent)" to TestDialog ctor to fix it.
>
> Regards,
> VZ
>

Hi, VZ, thanks for the quick reply. Indeed, I have make a mistake here.

But when I add ": wxDialog(parent)" to the ctor, I still see the build errors.

-------------- Build: win_gcc in minimal (compiler: GNU GCC Compiler)---------------

[ 50.0%] g++.exe -g -mthreads -DHAVE_W32API_H -D__WXMSW__ -D__WXDEBUG__ -D_UNICODE -IF:/wx/wxWidgets_trunk/lib/gcc_dll/mswud -IF:/wx/wxWidgets_trunk/include -DWXUSINGDLL -Wno-ctor-dtor-privacy -pipe -fmessage-length=0 -c minimal.cpp -o .objs\win_gcc\minimal.o
minimal.cpp: In constructor 'TestDialog::TestDialog(wxWindow*)':
minimal.cpp:50:58: error: no matching function for call to 'wxDialog::wxDialog(wxWindow*)'
TestDialog(wxWindow* parent): wxDialog(&(*parent))
^
In file included from F:/wx/wxWidgets_trunk/include/wx/wxprec.h:12:0,
from minimal.cpp:20:
F:/wx/wxWidgets_trunk/include/wx/msw/dialog.h:91:29: note: candidate: wxDialog::wxDialog(const wxDialog&)
wxDECLARE_NO_COPY_CLASS(wxDialog);
^
F:/wx/wxWidgets_trunk/include/wx/defs.h:3387:9: note: in definition of macro 'wxDECLARE_NO_COPY_CLASS'
classname(const classname&); \
^
F:/wx/wxWidgets_trunk/include/wx/msw/dialog.h:91:29: note: no known conversion for argument 1 from 'wxWindow*' to 'const wxDialog&'
wxDECLARE_NO_COPY_CLASS(wxDialog);
^
F:/wx/wxWidgets_trunk/include/wx/defs.h:3387:9: note: in definition of macro 'wxDECLARE_NO_COPY_CLASS'
classname(const classname&); \
^
In file included from F:/wx/wxWidgets_trunk/include/wx/dialog.h:350:0,
from F:/wx/wxWidgets_trunk/include/wx/wx.h:63,
from minimal.cpp:29:
F:/wx/wxWidgets_trunk/include/wx/msw/dialog.h:27:5: note: candidate: wxDialog::wxDialog(wxWindow*, wxWindowID, const wxString&, const wxPoint&, const wxSize&, long int, const wxString&)
wxDialog(wxWindow *parent, wxWindowID id,
^
F:/wx/wxWidgets_trunk/include/wx/msw/dialog.h:27:5: note: candidate expects 7 arguments, 1 provided
F:/wx/wxWidgets_trunk/include/wx/msw/dialog.h:24:5: note: candidate: wxDialog::wxDialog()
wxDialog() { Init(); }
^
F:/wx/wxWidgets_trunk/include/wx/msw/dialog.h:24:5: note: candidate expects 0 arguments, 1 provided
Process terminated with status 1 (0 minute(s), 3 second(s))
1 error(s), 0 warning(s) (0 minute(s), 3 second(s))

The correct fix is just adding "wxDialog(parent, -1, "Test")" to the constructor.

Now, the sample code works fine here, sorry about the noise.

Asmwarrior

[asmwarrior]

On 2016-2-9 22:38, Vadim Zeitlin wrote:
> On Tue, 09 Feb 2016 22:43:51 +0800 asmwarrior wrote:
>
> a> Now, in this post, I will give some reasons about why the text label get
> a> wrapped in the wxListbook. The point is that the position of the
> a> function call "AssignImageList".
>
> So it looks like it's a bad idea to use images before defining them. This
> seems pretty logical to me, doesn't it? I.e. it's not really surprising
> that the control can't compute the proper size of its images (which it
> clearly uses to decide whether to wrap the text or not) if you don't give
> the images to it until it's too late.

Yes, you are 100% right here!

> a> Any ideas?
>
> I'm really not sure I understand the question. You've found that misusing
> the API by using the not yet defined image indices exposes a bug. This is
> good to know and we should add checks for this, e.g. assert that we have a
> valid image list if any image indices are different from -1. But for your
> purpose all you need to do is to use the API correctly and set the image
> list first.
>
> Is there something I'm missing here?
> VZ
>

No, everything is clear now.
I think it is a good idea to add an assert here.

I see our C::B's construction of wxListbook is not correct, and I will try to fix them.

Thanks for your time and help.

Happy Chinese New Year!

Asmwarrior

[asmwarrior]

On 2016-2-9 22:38, Vadim Zeitlin wrote:

Hi, VZ, I'm grad to tell you that the issue can now be totally solved.
The actual reason is quite simple, several months ago, one of our C::B developers changed the embedded manifest file to support Windows 10, and this change breaks the using of version 6 of comctrl32.dll under Windows XP.

Today, I just find the reason, fix the manifest file solves all the issue I reported in this thread.
In-fact, all the issues comes from the version 5 of the comctrl32.dll, but since windows XP have already support the version 6 of comctrl32.dll(in its SxS fonder), we can simply enable it by specify the manifest file
I even don't need to change any wxListbook related code in either C::B or the wxWidgets library.

For a minimal sample code which use wxListbook and transparent png under Windows XP, we should also use manifest file, other wise, the alpha channel will be removed, and the version 5 of the comctrl32.dll does not works quite well(such as the wrapped text label issue).

The related discussion were put here in:
C::B discussion forum: http://forums.codeblocks.org/index.php/topic,20871.msg143031.html#msg143031
C::B Tickets: https://sourceforge.net/p/codeblocks/tickets/234/?limit=25&page=1#e1e4

Thanks for your help!

Asmwarrior

[Vadim Zeitlin]

On Fri, 12 Feb 2016 19:08:02 +0800 asmwarrior wrote:

a> In-fact, all the issues comes from the version 5 of the comctrl32.dll,

This is actually not that great, while very few people use XP nowadays,
some people/organizations still run Windows without themes (i.e. in classic
themes) and so use comtl32.dll v5. Obviously we can't do much about lack of
alpha support in that old version, but I'd still be more interested in the
rest working with v5 than under XP.

Anyhow, I'm glad that it could at least be fixed for C::B. I do wonder how
did nobody notice this for several months, the GUI appearance is quite
different with v5...

Regards,

[Artur Wieczorek]

> In-fact, all the issues comes from the version 5 of the comctrl32.dll, but since windows XP have already support the version 6 of comctrl32.dll(in its SxS fonder), we can simply enable it by specify the manifest file
> I even don't need to change any wxListbook related code in either C::B or the wxWidgets library.
>
> For a minimal sample code which use wxListbook and transparent png under Windows XP, we should also use manifest file, other wise, the alpha channel will be removed, and the version 5 of the comctrl32.dll does not works quite well(such as the wrapped text label issue).
>

I could take a look at this issue on XP machine but this discussion was
quite long, regarding several issues and I am not sure what is this real
issue with comtl32 v5 and wxListbook.
Could you please summarize it briefly?

And sample code reproducing the issue is at
https://gist.github.com/asmwarrior/3d1e618a32789476fd59, right?

Regards,
AW

[Igor Korot]

Hi,

I also wonder why enabling Windows 10 manifest can cause such a disaster?

It should just pull in the proper version of the library(-ies)...
Unless, of course (s)he made a mistake with such inclusion.

Thank you.

>
> Regards,
> AW

[Vadim Zeitlin]

On Fri, 12 Feb 2016 20:23:18 +0100 Artur Wieczorek wrote:

AW> I could take a look at this issue on XP machine

It turns out it's not really XP-specific but appears when using
comctl32.dll v5, i.e. with themes disabled. It should behave the same under
all Windows versions as this old DLL presumably doesn't change any more
anyhow.

AW> but this discussion was quite long, regarding several issues and I am
AW> not sure what is this real issue with comtl32 v5 and wxListbook.
AW> Could you please summarize it briefly?

The original problem was that the control was too wide as it reserved
space for the vertical scrollbar that it didn't really have. But I'm not
sure myself any more...

Regards,

[asmwarrior]

On 2016-2-13 3:27, Igor Korot wrote:
> Hi,
>
> On Fri, Feb 12, 2016 at 2:23 PM, Artur Wieczorek <art...@wp.pl> wrote:
>>> In-fact, all the issues comes from the version 5 of the comctrl32.dll, but
>>> since windows XP have already support the version 6 of comctrl32.dll(in its
>>> SxS fonder), we can simply enable it by specify the manifest file
>>> I even don't need to change any wxListbook related code in either C::B or
>>> the wxWidgets library.
>>>
>>> For a minimal sample code which use wxListbook and transparent png under
>>> Windows XP, we should also use manifest file, other wise, the alpha channel
>>> will be removed, and the version 5 of the comctrl32.dll does not works quite
>>> well(such as the wrapped text label issue).
>>>
>>
>> I could take a look at this issue on XP machine but this discussion was
>> quite long, regarding several issues and I am not sure what is this real
>> issue with comtl32 v5 and wxListbook.
>> Could you please summarize it briefly?
>>
>> And sample code reproducing the issue is at
>> https://gist.github.com/asmwarrior/3d1e618a32789476fd59, right?
>
> I also wonder why enabling Windows 10 manifest can cause such a disaster?
>
> It should just pull in the proper version of the library(-ies)...
> Unless, of course (s)he made a mistake with such inclusion.
>
> Thank you.
>

Hi, Igor Korot, the commit in C::B which change the manifest file is in this commit, see the link below:

Code::Blocks / SVN Repo / Commit [r10409] - https://sourceforge.net/p/codeblocks/code/10409/

You can see the code changes there, but I have no experience at manifest grammar.

Thanks.

Asmwarrior

[asmwarrior]

OK, I will give a summary with a minimal samples.
In the attachment, I have three to build the minimal samples:
1, minimal.cpp (this is slightly modified version from wx-git-master's sample minimal.cpp)
2, compiler.png, this is a png file which have transparent channels.
3, minimal.exe.manifest, which you can put it along your generated minimal.exe.

Now, you can build the minimal.cpp, and please note that you can call listbook1->AssignImageList(listbook1Images); in two places.
I have add some comments after the statement.

//listbook1->AssignImageList(listbook1Images); // ***** set image list before
...
...
listbook1->AssignImageList(listbook1Images); // ***** set image list after

And I have three result screen shots(you can open the dialog by click the menu "Help->About".

1, use-manifest.png, screen shot when you put the minimal.exe.manifest along with minimal.exe, whether you call AssignImageList before or after does not have much difference. This means the version 6 of comctl32.dll works quite well. (But there is a small issue that the button covers the bookctrl view)

2, no-manifest-set-image-list-before.png, screen shot when you do not use manifest file(this means you use the version 5 of comctl32.dll), and you call AssignImageList before add the panels to the wxListbook, and this looks better, but you see the alpha is removed.

3, no-manifest-set-image-list-later.png, this screen shot shows much similar like the previous one, but since calling AssignImageList later will cause the text label get wrapped, that's too bad issue here.

Hope the above summary words and tests are clean.

Asmwarrior

[Vadim Zeitlin]

On Sat, 13 Feb 2016 14:13:16 +0800 asmwarrior wrote:

a> the commit in C::B which change the manifest file is in this commit, see
a> the link below:
a>
a> Code::Blocks / SVN Repo / Commit [r10409] - https://sourceforge.net/p/codeblocks/code/10409/

Has this been actually tested at all? wxWidgets doesn't support per
monitor DPI (yet), so I think that in addition to the breakage you found,
this must have also broken C::B appearance in high DPI modes as it won't be
upscaled automatically any more (unless it has MSW-specific code for
handling WM_DPICHANGED itself, but this would be very surprising).

Regards,

[Vadim Zeitlin]

On Sat, 13 Feb 2016 14:51:15 +0800 asmwarrior wrote:

a> On 2016-2-13 3:23, Artur Wieczorek wrote:
a> >> In-fact, all the issues comes from the version 5 of the
a> >> comctrl32.dll,

Please retest with Artur's fixes in 43fe885eb756dd721cd4e06825e054ec89baf170
and the previous commit 53b6806b50f8c60d25b4e58bed45105c52566c44, they
should fix these issues even if themes disabled.

Regards,

[asmwarrior]

On 2016-2-19 6:31, Vadim Zeitlin wrote:
> On Sat, 13 Feb 2016 14:51:15 +0800 asmwarrior wrote:
>
> a> On 2016-2-13 3:23, Artur Wieczorek wrote:
> a> >> In-fact, all the issues comes from the version 5 of the
> a> >> comctrl32.dll,
>
> Please retest with Artur's fixes in 43fe885eb756dd721cd4e06825e054ec89baf170
> and the previous commit 53b6806b50f8c60d25b4e58bed45105c52566c44, they
> should fix these issues even if themes disabled.
>
> Regards,
> VZ
>

Hi, VZ, thanks, I just did the tests. (I'm running the test on Windows XP which have theme serviced disabled)

I also do not use the manifest, so version 5 of comctl32.dll is used.
Compared with my previous post, I see there are two fixes

1, There is no "black background" in the icons. (You can see the black background in screen shot in no-manifest-set-image-list-before.png or no-manifest-set-image-list-later.png in my previous post)

2, wrapped label issue shown in no-manifest-set-image-list-later.png is fixed.

That's great! I think all my reported issues are fixed now.

Thanks.

Asmwarrior