parsertest project, Window refresh issue, rev 7788

[ollydbg]

See the screen shot, it looks like we need to force the main window to refresh when the progress dialog dismissed.


PS: The build-log panel should be refreshed too in some cases (I sometimes see this panel does not refreshed when C::B activated)

[MortenMacFly]

See the screen shot, it looks like we need to force the main window to refresh when the progress dialog dismissed.

Hmmm... you shouldn't actually see the main window when thee progress dialog is shown as it is hidden (in frame.cpp by calling Hide()). How did you manage to do that? (Doesn't happen here).

[ollydbg]

Hmmm... you shouldn't actually see the main window when thee progress dialog is shown as it is hidden (in frame.cpp by calling Hide()). How did you manage to do that? (Doesn't happen here).

The screen shot shows that the progress dialog is already closed. but I need to scroll on the textctrl to let the mainframe show its content correctly. This is the same issue when sometimes I see in build-log panel under c::b.

I'm using XP, wx2.8.12.

[ollydbg]

It looks like there is a fatal bug in wxWidgets 2.8.12 (windows).

I even add code like below:

Code

    Show();

    m_LogCtrl->Refresh();
    m_LogCtrl->Update();

But the logCtrl still not refreshed. This is the same behavior as the build-log.

Any one have meet this kind of problem?

[ollydbg]

Ok, I find the reason:

In the wxsmith, the textctrl style has wxTE_RICH2(enabled), if I disable this option, then it refreshes FINE.

I have tried another option which I enable wxTE_RICH, the bug happens again.

I'm not sure what's the exact meaning of those options. See the documents:

wxTE_RICH  Use rich text control under Win32, this allows to have more than 64KB of text in the control even under Win9x. This style is ignored under other platforms. 
wxTE_RICH2  Use rich text control version 2.0 or 3.0 under Win32, this style is ignored under other platforms 

[MortenMacFly]

In the wxsmith, the textctrl style has wxTE_RICH2(enabled), if I disable this option, then it refreshes FINE.

There have been bug reports on this style and many improvements recently in the wx trunk version (a.k.a. 2.9.x) for rich text controls. If its a wx issue I'd say try with wx 2.9.x - if the error is gone, ignore it. In the end it's just a test project.

[ollydbg]

In the wxsmith, the textctrl style has wxTE_RICH2(enabled), if I disable this option, then it refreshes FINE.

There have been bug reports on this style and many improvements recently in the wx trunk version (a.k.a. 2.9.x) for rich text controls. If its a wx issue I'd say try with wx 2.9.x - if the error is gone, ignore it. In the end it's just a test project.

Thanks, but the issue also affect the current c::b's source code, see here

Code

wxWindow* TextCtrlLogger::CreateControl(wxWindow* parent)
{
    if (!control)
        control = new wxTextCtrl(parent, -1, wxEmptyString, wxDefaultPosition, wxDefaultSize, wxTE_MULTILINE | wxTE_READONLY | wxTE_RICH | wxTE_NOHIDESEL | wxTE_AUTO_URL);
    return control;
}

Can we remove the "wxTE_RICH" ??  This issue happens for a very long time.

[oBFusCATed]

Can we remove the "wxTE_RICH" ??  This issue happens for a very long time.

I doubt, because we will use the formatting, also it works as expected on linux

[ollydbg]

Can we remove the "wxTE_RICH" ??  This issue happens for a very long time.

I doubt, because we will use the formatting, also it works as expected on linux

The refresh issue is very annoying under windows. 

It looks like wxTE_RICH and wxTE_RICH2 only affect the win32 platform.

[oBFusCATed]

The only thing you could do is to test it with wx2.9 from wx's trunk and then report to wx's guys if the problem is still there.

[ollydbg]

The only thing you could do is to test it with wx2.9 from wx's trunk and then report to wx's guys if the problem is still there.

OK, I have just create a very simple test project against wx2.8 and wx trunk(2.9.x).

The result is: This issue does NOT happen in the wx trunk. 

[oBFusCATed]

Now you can try to find the correct commit and then produce a backport patch (if possible).

[MortenMacFly]

Now you can try to find the correct commit and then produce a backport patch (if possible).

I wouldn't do it. We will move to wx 2.9 anyways sooner or later and I'd rather not make C::B depend on a self-patched version of wxWidgets.

Instead, you may ask the wxWidgets guys if it is possible to backport this specific stuff to the 2.8 branch (maybe it is already... who knows...).

[oBFusCATed]

Instead, you may ask the wxWidgets guys if it is possible to backport this specific stuff to the 2.8 branch (maybe it is already... who knows...).

I doubt, they'll bother with another version of 2.8.

[MortenMacFly]

I doubt, they'll bother with another version of 2.8.

Are you really sure? Because there are plenty of commits on the wx28 branch since v2.8.12, including back-ports from v2.9.x ...

[oBFusCATed]

Of course, I'm not, I don't follow their development.

[ollydbg]

Looks like 2.8 branch still have this issue(I test a wx 2.8 dll build from 2.8 branch 2011-12-01 in xunxun's c::b release).

So, I will go direct to wx 2.9.3 release. Are there any tips, it looks like the wiki is not quite up to date: Compiling wxWidgets 2.9.0 to develop Code::Blocks (MSW) - CodeBlocks

Search the forum reveals some discussion, as a summrary
1, install wx2.9.3 32bit windows installer
2, edit some setup.h/setup0.h files to disable: wxUSE_STC
3, use the command:

Code

mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 USE_STC=0 USE_PROPGRID=1 BUILD=release clean
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 USE_STC=0 USE_PROPGRID=1 BUILD=release

Any ideas?

PS: why USE_PROPGRID=1 ? we have a wxpropgrid target in codeblocks.cbp, do they conflict? 
Search the forum and it looks like "USE_PROPGRID=1" should be set to let us build wxsmith plugins, right?

[ollydbg]

It looks like building exchndl do not need libintl, see my fix below.

This was found when I try to build a c::b against wx2.9.3 with xunxun's gcc 4.6.3.
My bfd and iberty libraries are build from gdb, but I configured gdb with out international language support, so it does not build/install the libintl, this cause a build error in exchndl target, but tracking the build error message, I found that libintl is not necessory, instread the libz is need.

I just test the codeblocks.cbp, it should be fixed too.

Code

Index: CodeBlocks_wx29.cbp
===================================================================
--- CodeBlocks_wx29.cbp	(revision 7807)
+++ CodeBlocks_wx29.cbp	(working copy)
@@ -19,7 +19,7 @@
 				<Linker>
 					<Add library="bfd" />
 					<Add library="iberty" />
-					<Add library="intl" />
+					<Add library="z" />
 					<Add directory="base\exchndl\lib" />
 				</Linker>
 			</Target>

   

There are some other part in the file maybe should be fixed.

Code

Index: E:/code/cb/cb_trunk/src/base/exchndl/include/coff/internal.h
===================================================================
--- E:/code/cb/cb_trunk/src/base/exchndl/include/coff/internal.h	(revision 7807)
+++ E:/code/cb/cb_trunk/src/base/exchndl/include/coff/internal.h	(working copy)
@@ -98,13 +98,13 @@
 #define F_DLL           (0x2000)
 
 /* Extra structure which is used in the optional header.  */
-#ifndef _WINNT_H
-typedef struct _IMAGE_DATA_DIRECTORY 
-{
-  bfd_vma VirtualAddress;
-  long    Size;
-}  IMAGE_DATA_DIRECTORY;
-#endif
+//#ifndef _WINNT_H
+//typedef struct _IMAGE_DATA_DIRECTORY
+//{
+//  bfd_vma VirtualAddress;
+//  long    Size;
+//}  IMAGE_DATA_DIRECTORY;
+//#endif
 #define PE_EXPORT_TABLE			0
 #define PE_IMPORT_TABLE			1
 #define PE_RESOURCE_TABLE		2	

Because this was already defined in the xunxun's gcc 4.6.3 package(MinGW64).
 

[ollydbg]

It looks like building exchndl do not need libintl, see my fix below.

Ping, any body can have some comments?

[MortenMacFly]

Because this was already defined in the xunxun's gcc 4.6.3 package(MinGW64).

What about other (especially older) compilers?

[ollydbg]

Because this was already defined in the xunxun's gcc 4.6.3 package(MinGW64).

What about other (especially older) compilers?

Both tests: I use libz from mingw official sites zlib.
Test ONE:
I test the tdm gcc 4.6.1 sjlj, the compile stage passed, so it looks like those declaration does not need at least in tdm-gcc 4.6.1. As I know, tdm gcc use official Mingw API.  while xunxun's gcc 4.6.3 use mingw64 API.
but the link stage failed:

Code

-------------- Clean: exchndl in Code::Blocks wx2.8.x ---------------

Cleaned "Code::Blocks wx2.8.x - exchndl"

-------------- Build: exchndl in Code::Blocks wx2.8.x ---------------

[ 50.0%] gcc.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE     -iquote.objs\include -I.objs\include -I. -IE:\code\cb\wx\wxWidgets-2.8.12\include -IE:\code\cb\wx\wxWidgets-2.8.12\contrib\include -IE:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Ibase\exchndl\include  -c E:\code\cb\cb_trunk\src\base\exchndl\exchndl.c -o .objs\base\exchndl\exchndl.o
[100.0%] g++.exe -shared   -Wl,--dll -Lbase\tinyxml -LE:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll -Lbase\exchndl\lib  .objs\base\exchndl\exchndl.o   -o devel\exchndl.dll  -lwxmsw28u -lbfd -liberty -lz 
e:/code/gcc/tdmgcc461sjlj/bin/../lib/gcc/mingw32/4.6.1/../../../libbfd.a(bfd.o): In function `snprintf':
e:/code/gcc/pcxmingw4630209/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/stdio.h:559: undefined reference to `__ms_vsnprintf'
e:/code/gcc/tdmgcc461sjlj/bin/../lib/gcc/mingw32/4.6.1/../../../libbfd.a(pe-i386.o): In function `snprintf':
e:/code/gcc/pcxmingw4630209/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/stdio.h:559: undefined reference to `__ms_vsnprintf'
e:/code/gcc/tdmgcc461sjlj/bin/../lib/gcc/mingw32/4.6.1/../../../libbfd.a(pei-i386.o): In function `snprintf':
e:/code/gcc/pcxmingw4630209/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/stdio.h:559: undefined reference to `__ms_vsnprintf'
e:/code/gcc/tdmgcc461sjlj/bin/../lib/gcc/mingw32/4.6.1/../../../libbfd.a(archive.o): In function `snprintf':
e:/code/gcc/pcxmingw4630209/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/stdio.h:559: undefined reference to `__ms_vsnprintf'
e:/code/gcc/tdmgcc461sjlj/bin/../lib/gcc/mingw32/4.6.1/../../../libbfd.a(elf.o): In function `snprintf':
e:/code/gcc/pcxmingw4630209/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/include/stdio.h:559: undefined reference to `__ms_vsnprintf'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 1 seconds)
5 errors, 0 warnings (0 minutes, 1 seconds)

Here, my libiberty and libbfd is copied from gdb installation which is build from xunxun's 4.6.3. so it have some undefined reference in the link stage
As a conclusion, I guess it should be OK if the libbfd is build from tdm-gcc.

Test Two:
I test under loaden's gcc 4.4.5 release under 2010.10.12 (MinGW ALL 4.4.5 (binutils-2.20.1-2,make-3.82,mingwrt-3.18,w32api-3.15,pthreads2.8,iconv_1.13.1)), still failed in the link stage:

Code

------------- Clean: exchndl in Code::Blocks wx2.8.x ---------------

Cleaned "Code::Blocks wx2.8.x - exchndl"

-------------- Build: exchndl in Code::Blocks wx2.8.x ---------------

[ 50.0%] gcc.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE     -iquote.objs\include -I.objs\include -I. -IE:\code\cb\wx\wxWidgets-2.8.12\include -IE:\code\cb\wx\wxWidgets-2.8.12\contrib\include -IE:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Ibase\exchndl\include  -c E:\code\cb\cb_trunk\src\base\exchndl\exchndl.c -o .objs\base\exchndl\exchndl.o
[100.0%] g++.exe -shared   -Wl,--dll -Lbase\tinyxml -LE:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll -Lbase\exchndl\lib  .objs\base\exchndl\exchndl.o   -o devel\exchndl.dll  -lwxmsw28u -lbfd -liberty -lz 
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (18560) greater than or equal to .debug_abbrev size (1202).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(bfd.o):bfd.c:(.text+0x23): undefined reference to `__ms_vsnprintf'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (59072) greater than or equal to .debug_abbrev size (1388).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(pe-i386.o):pe-i386.c:(.text+0x10f3): undefined reference to `__ms_vsnprintf'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (164188) greater than or equal to .debug_abbrev size (1420).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(pei-i386.o):pei-i386.c:(.text+0x13c3): undefined reference to `__ms_vsnprintf'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (30800) greater than or equal to .debug_abbrev size (1265).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(archive.o):archive.c:(.text+0x313): undefined reference to `__ms_vsnprintf'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: found dwarf version '0', this reader only handles version 2 and 3 information.
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(archive.o):archive.c:(.text+0x2bba): undefined reference to `__chkstk_ms'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (242624) greater than or equal to .debug_abbrev size (1608).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(elf.o):elf.c:(.text+0x3e3): undefined reference to `__ms_vsnprintf'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (328996) greater than or equal to .debug_abbrev size (1596).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libbfd.a(elflink.o):elflink.c:(.text+0x1e77): undefined reference to `__chkstk_ms'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: Offset (68096) greater than or equal to .debug_abbrev size (1028).
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libiberty.a(cp-demangle.o):cp-demangle.c:(.text+0x6fab): undefined reference to `__chkstk_ms'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: found dwarf version '1', this reader only handles version 2 and 3 information.
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libiberty.a(cp-demangle.o):cp-demangle.c:(.text+0x6fc3): undefined reference to `__chkstk_ms'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: found dwarf version '20039', this reader only handles version 2 and 3 information.
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libiberty.a(cp-demangle.o):cp-demangle.c:(.text+0x75a3): undefined reference to `__chkstk_ms'
E:\code\cb\gcc\mingw-static-4.4.5-all\bin/ld.exe: Dwarf Error: found dwarf version '8259', this reader only handles version 2 and 3 information.
e:/code/cb/gcc/mingw-static-4.4.5-all/bin/../lib/gcc/i686-mingw32/4.4.5/../../../libiberty.a(cp-demangle.o):cp-demangle.c:(.text+0x75bb): undefined reference to `__chkstk_ms'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 1 seconds)
11 errors, 0 warnings (0 minutes, 1 seconds)

So, the reason is the same as tdm-gcc. The libbfd and libiberty should have the same gcc version used to build exchndl.dll.

The change in internal.h should be OK from my point.

Can some one test it? 

[ollydbg]

Now you can try to find the correct commit and then produce a backport patch (if possible).

FYI:
I really find that patch, and it can easily back port to wx2.8.12, so the refresh issue is gone.

See:
Re: wx2.8.12, windows wxTextCtrl does not refresh itself correctly

[xunxun]

Hope it can be backed port to wx2.8 branch