Note: 2.8.0 has been released see http://sourceforge.net/project/showfiles.php?group_id=9863
Note: 2.8.1 was put on hold/canceled for wxMSW.
killerbot's Summary of this thread "CB and wx28 state"
http://forums.next.codeblocks.org/index.php?topic=4816.msg37734#msg37734
Note: These patches are useful ONLY to developers who can compile C::B from SVN
Note: These patches have yet to be approved by the Code::Blocks team.
Note: AS-IS No warranty, use with caution.
Note: This research stated in thread http://forums.next.codeblocks.org/index.php?topic=4344.0
Editing: I am starting work on patches to reduce warning on compiling against wxWidgets 2.8
Patches to get Code::Blocks to compile and link against wxWidgets 2.8.x
Patches to Code::Blocks projects files (Needed by windows Users ONLY):
[ Patch #1733 ] wxmsw28 patch for wxWidgets 2.8
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1733&group_id=5358
Please see this post for a new solution
http://forums.next.codeblocks.org/index.php?topic=5199.msg40619#msg40619
Patches to Code::Blocks scripted wizard
[ Patch #1880 ] Truncated new project scripted wizard fix for wxW28 Author: Not Known
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1880&group_id=5358
[ Patch #1893 ] wxCheckListBox patch for wxWidgets 2.8 Submitted By: stahta01 found by wxLearner
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1893&group_id=5358
Known Issues:
Recently Solved Issues:
The patch for the current wxSmith is here.
[ Patch #1903 ] wxSmith patch for wxW28 and wxPropertyGrid 1.2.x Submitted By: stahta01
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1903&group_id=5358
Patches applied to C::B SVN
[ Patch #1731 ] scripting patch for wxWidgets 2.8
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1731&group_id=5358
[ Patch #1661 ] wxCheckListBox patch for wxWidgets 2.7 Submitted By: stahta01
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1661&group_id=5358
[ Patch #1628 ] compilergcc patch for wxWidgets 2.7 Submitted By: afb
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1628&group_id=5358
[ Patch #1738 ] wxHIDE_READONLY patch for wxWidgets 2.8 Submitted By: stahta01
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1738&group_id=5358
[ Patch #1734 ] ScintillaWX patch for wxWidgets 2.8 Submitted By: stahta01
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1734&group_id=5358
[ Patch #1739 ] wxPropertyGrid patch for wxWidgets 2.8 Submitted By: stahta01
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1739&group_id=5358
[ Patch #1736 ] compilergcc patch for wxWidgets 2.8 Submitted By: stahta01
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1736&group_id=5358
[ Patch #1735 ] pipedprocess patch for wxWidgets 2.8 Submitted By: stahta01
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1735&group_id=5358
[ Patch #1762 ] CentreOnScreen patch for wxWidgets 2.8 Submitted By: stahta01
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1762&group_id=5358
[ Patch #1730 ] wxaui patch for wxWidgets 2.8 Submitted By: stahta01 based on afb work.
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1730&group_id=5358
[ Patch #1767 ] Old wxSmith patch for wxWidgets 2.8 Submitted By: stahta01
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1767&group_id=5358
[ Patch #1732 ] keybinder plugin patches for wxWidgets 2.8 Submitted By: stahta01 based on afb work.
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1732&group_id=5358
Patches obsoleted because other fix was found
[ Patch #1737 ] selecttargetdlg patch for wxWidgets 2.8 Submitted By: stahta01
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1737&group_id=5358
[ Patch #1766 ] NEW (experimental) wxSmith patch for wxWidgets 2.8 Submitted By: stahta01
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1766&group_id=5358
The patch for the OLD wxSmith for wxWidgets 2.8.0 bug; this is supposed to be fixed in 2.8.1
[ Patch #1771 ] Old wxSmith patch for wxListbook::HitTest protected wxW2.8
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1771&group_id=5358
wxWidgets Bug report
https://sourceforge.net/tracker/?func=detail&atid=109863&aid=1626543&group_id=9863
Tim S
thanks for the nice overview :-)
I hope this will be addressed by the wx guys, otherwise they can keep their wx2.8 ;-)
QuotePatches to wxWidgets 2.8.0rc1:
Fix to Bitmaps are not loading in toolbars.
Upgrade /src/common/fs_arc.cpp to CVS version 1.5 [Needed by Window Users]
Apply patch xrs_images.patch from
http://sourceforge.net/tracker/index.php?func=detail&aid=1598839&group_id=9863&atid=109863
Quote from: killerbot on November 19, 2006, 09:35:44 AM
thanks for the nice overview :-)
I hope this will be addressed by the wx guys, otherwise they can keep their wx2.8 ;-)
QuotePatches to wxWidgets 2.8.0rc1:
Fix to Bitmaps are not loading in toolbars.
Upgrade /src/common/fs_arc.cpp to CVS version 1.5 [Needed by Window Users]
Apply patch xrs_images.patch from
http://sourceforge.net/tracker/index.php?func=detail&aid=1598839&group_id=9863&atid=109863
They are working on it; CVS Head even has been fixed for this issue (I have not confirmed the fix really fixes the problem), but CVS Head has several errors for C::B relating to wxAui changes.
Edit: The changes were renaming constants, I fixed them and C::B worked with icons OK.
Tim S
Deleted
Works OK on Mac OS X 10.4 with Code::Blocks 1.0 SVN + above patches with wxWidgets 2.8 CVS:
(http://www.algonet.se/~afb/wx/codeblocks-wxmac280.png)
The only things that you additionally need is to patch the known Mac issues and the splash screen...
Nice. 8)
Hmm, might have spoken a bit too soon... :)
Start application, open project, compile = OK.
Open up the preferences dialog = Crash. Die.
Anyway, it's on the "right path" so we can probably
support both wxWidgets 2.6 and 2.8 with C::B 1.0 ?
Quote from: afb on November 23, 2006, 10:51:16 AM
Hmm, might have spoken a bit too soon... :)
Start application, open project, compile = OK.
Open up the preferences dialog = Crash. Die.
Anyway, it's on the "right path" so we can probably
support both wxWidgets 2.6 and 2.8 with C::B 1.0 ?
It crashed the last time I tried CVS-Head.
I was thinking that C::B 1.5 could support
both wxWidgets 2.6 and 2.8 with WXWIN_COMPATIBILITY_2_4 turned off for
both.
I would NOT try to get wxWidgets 2.8 support into C::B 1.0, I wxWidgets 2.8 does not look good right now, till the final 2.8.0 is done we can't really say if C::B will work with it.
Tim S
You are probably right. While we could integrate some of the minor improvement patches, we should probably wait with the pure "ABI compatibility" ones until after 1.0 has been released (like for 1.5 or something). Otherwise we'd just end up with people assuming that it is supported.
Better get it working solidly with wxWidgets 2.6 (patched!) first, and then do a wxWidgets 2.8 version.
Quote from: stahta01 on November 23, 2006, 09:45:16 PM
wxWidgets 2.8 does not look good right now, till the final 2.8.0 is done we can't really say if C::B will work with it.
Then again, that's just one week to wait... :lol:
Quote from: stahta01 on November 23, 2006, 09:45:16 PM
I was thinking that C::B 1.5 could support both wxWidgets 2.6 and 2.8 with WXWIN_COMPATIBILITY_2_4 turned off for both.
This might be a problem for 2.6, which has it "on" by default. (can't we work around it ?)
first of all, let's see what wx 2.8 brings . Will it fix some of the bugs we are suffering from the 2.6, if yes, then it light be interesting to use 2.8. If not, then might be best to wait.
I think it is possible to get wx2.8 support in 1.0 we are even still waiting for RC3....
on linux wxwidgets2.8 has a few bug fixes and i already use it successfully with code::blocks (except for a bug concerning debugging).
the most important fix: the drag and drop xserver freeze bug has been fixed.
selections in tree or list views don't look ugly on ubuntu anymore (before they had a saturated ugly orange colour)
wxaui also looks better - the mouse cursor changes now when it's above the sash.
Quote from: afb on November 23, 2006, 10:14:10 PM
Quote from: stahta01 on November 23, 2006, 09:45:16 PM
I was thinking that C::B 1.5 could support both wxWidgets 2.6 and 2.8 with WXWIN_COMPATIBILITY_2_4 turned off for both.
This might be a problem for 2.6, which has it "on" by default. (can't we work around it ?)
We can just turn it on for just 2.6; 2.8 has it off by default. I think it will require more work if we don't turn it off for 2.6 but the amount of work won't be that much. Just some #ifdef blocks in codeblocks.
From a user point of view having it on for 2.6 and off for 2.8 will be the simplest way. I will work on a patch to fix code::blocks so it works both with WXWIN_COMPATIBILITY_2_4 on or off.
From a coder point of view having WXWIN_COMPATIBILITY_2_4 set the same, either 1 or 0, would be the simplest way.
Note: I tried just defining WXWIN_COMPATIBILITY_2_4 as 0 and wxHIDE_READONLY as 0,but C::B crashed too much.
Tim S
Why do we need WXWIN_COMPATIBILITY_2_4? C::B won't even compile with that version of wx........
Quote from: sethjackson on November 24, 2006, 03:11:59 AM
Why do we need WXWIN_COMPATIBILITY_2_4? C::B won't even compile with that version of wx........
By default wxWidgets sets a flag for compatibility to the last version in setup.h.
wx26 has WXWIN_COMPATIBILITY_2_4 set to 1
wx28 has WXWIN_COMPATIBILITY_2_4 set to 0 and WXWIN_COMPATIBILITY_2_6 set to 1
So code::blocks current dll is compiled with WXWIN_COMPATIBILITY_2_4 set to 1.
Tim S
Oh ok. Thanks. :)
Quote from: stahta01 on November 24, 2006, 03:08:57 AM
We can just turn it on for just 2.6; 2.8 has it off by default. I think it will require more work if we don't turn it off for 2.6 but the amount of work won't be that much. Just some #ifdef blocks in codeblocks.
From a user point of view having it on for 2.6 and off for 2.8 will be the simplest way. I will work on a patch to fix code::blocks so it works both with WXWIN_COMPATIBILITY_2_4 on or off.
This would the best solution, since it would mean that Code::Blocks would work with both default wxWidgets 2.6 and default wxWidgets 2.8 without any modifications.
Of course, if we have any of our own code that still uses wxWidgets 2.4 methods then we should strive to update those to 2.6. We should survive 2.4 compat, but not require it...
Quote from: killerbot on November 23, 2006, 11:06:42 PM
first of all, let's see what wx 2.8 brings . Will it fix some of the bugs we are suffering from the 2.6, if yes, then it light be interesting to use 2.8. If not, then might be best to wait.
wxWidgets 2.6 already has some showstopper bugs, but those can be fixed with patches (or with wxWidgets 2.6.4) so that in itself is not reason enough I think.
FYI:
The only thing that seems to need WXWIN_COMPATIBILITY_2_4 set to 1 is the use of wxHIDE_READONLY. I have submitted a patch to guard all the locations that it is used in.
Tim S
Patches to core Code::Blocks project and contrib Code::Blocks workspace:
[ Patch #1655 ] wxHIDE_READONLY patch for wxWidgets 2.7 Submitted By: stahta01
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1655&group_id=5358
Just a note: discussions to switch C::B development to wx2.8 are pointless. wx2.8 will take quite a while to enter the major linux distros repositories. Until then, wx2.6 will be used for C::B development.
Of course, patches that allow building with wx2.8 too are fine (assuming they don't break existing functionality).
Quote from: mandrav on November 24, 2006, 11:56:07 AM
... Until then, wx2.6 will be used for C::B development.
Of course, patches that allow building with wx2.8 too are fine ...
That is what we are discussing, yes :-)
Quote from: stahta01 on November 24, 2006, 11:08:51 AM
FYI:
The only thing that seems to need WXWIN_COMPATIBILITY_2_4 set to 1 is the use of wxHIDE_READONLY. I have submitted a patch to guard all the locations that it is used in.
Isn't it easier to just #define it to 0 for newer wxWidgets, instead of guarding it everywhere ?
#if !WXWIN_COMPATIBILITY_2_4
#define wxHIDE_READONLY 0
#endif
Quote from: afb on November 24, 2006, 12:27:32 PM
Quote from: stahta01 on November 24, 2006, 11:08:51 AM
FYI:
The only thing that seems to need WXWIN_COMPATIBILITY_2_4 set to 1 is the use of wxHIDE_READONLY. I have submitted a patch to guard all the locations that it is used in.
Isn't it easier to just #define it to 0 for newer wxWidgets, instead of guarding it everywhere ?
#if !WXWIN_COMPATIBILITY_2_4
#define wxHIDE_READONLY 0
#endif
IIRC we use that flag in the file dialogs somewhere........
Quote from: afb on November 24, 2006, 12:27:32 PM
Isn't it easier to just #define it to 0 for newer wxWidgets, instead of guarding it everywhere ?
#if !WXWIN_COMPATIBILITY_2_4
#define wxHIDE_READONLY 0
#endif
Yes, it is much easier, but it seemed to make C::B unstable. I have done some more testing and C::B is unstable when WXWIN_COMPATIBILITY_2_4 is set to 0. Why, I don't know yet. I added guards around the wxHIDE_READONLY so setting it to zero was not the cause. But, setting WXWIN_COMPATIBILITY_2_4 to zero was.
Tim S
Quote from: stahta01 on November 24, 2006, 04:36:44 PM
C::B is unstable when WXWIN_COMPATIBILITY_2_4 is set to 0.
The one I set to zero was wxHIDE_READONLY constant, not WXWIN_COMPATIBILITY_2_4...
#if !WXWIN_COMPATIBILITY_2_4
#define wxHIDE_READONLY 0
#endif
This implies that wxHIDE_READONLY is 0 when WXWIN_COMPATIBILITY_2_4 is 0.
And, the code above ONLY makes sense when WXWIN_COMPATIBILITY_2_4 is 0; otherwise the code is not needed. So, are you testing with WXWIN_COMPATIBILITY_2_4 = 1 or = 0?
Tim S
Quote from: stahta01 on November 24, 2006, 06:31:30 PM
And, the code above ONLY makes sense when WXWIN_COMPATIBILITY_2_4 is 0; otherwise the code is not needed.
Right, I was only using it in the wxWidgets 2.8 builds. What I meant was that I didn't change the 2.4 compat.
Quote
So, are you testing with WXWIN_COMPATIBILITY_2_4 = 1 or = 0?
On for 2.6, Off for 2.8. This was just discussing your patch, but it's interesting that you mention that using wxWidgets 2.6 with WXWIN_COMPATIBILITY_2_4=0 is also unstable (I knew that wxWidgets 2.8 was, but...) Guess I need to build another debugging version of wx26 then, with the 2.4 compat disabled.
Quote from: afb on November 25, 2006, 11:09:01 AM
On for 2.6, Off for 2.8. This was just discussing your patch, but it's interesting that you mention that using wxWidgets 2.6 with WXWIN_COMPATIBILITY_2_4=0 is also unstable (I knew that wxWidgets 2.8 was, but...) Guess I need to build another debugging version of wx26 then, with the 2.4 compat disabled.
Yes, wxWidgets 2.8 with WXWIN_COMPATIBILITY_2_4=1, works much better than with WXWIN_COMPATIBILITY_2_4=0.
I am going to work on this issue using wxWidgets 2.6 with WXWIN_COMPATIBILITY_2_4=0 in order to remove the whole set of wxWidgets 2.8 changes from the picture.
Do you think I should start a new thread on wxWidgets 2.6 with WXWIN_COMPATIBILITY_2_4=0 issues?
Tim S
Quote from: stahta01 on November 26, 2006, 02:06:01 AM
I am going to work on this issue using wxWidgets 2.6 with WXWIN_COMPATIBILITY_2_4=0 in order to remove the whole set of wxWidgets 2.8 changes from the picture.
Do you think I should start a new thread on wxWidgets 2.6 with WXWIN_COMPATIBILITY_2_4=0 issues?
Sounds like a good plan, and it should probably go in a separate thread.
(Building a wxMac 2.6 with
--enable-debug --disable-compat24 now...)
You were right, it seems that the crashes with wxWidgets 2.8.0 are in fact general crashes when compat24 is turned off... I'm seeing the same ones in wxWidgets 2.6.3p2 now, that I did with wxWidgets 2.8.0rc1 earlier:
Settings > Environments *crash*
../src/generic/listctrl.cpp(3699): assert "wxAssertFailure" failed: invalid item index in SetItem
Settings > Editor *crash*
../src/generic/listctrl.cpp(3699): assert "wxAssertFailure" failed: invalid item index in SetItem
Settings > Compiler and Debugger *crash*
../src/common/list.cpp(326): assert "wxAssertFailure" failed: invalid index in wxListBase::Item
Settings > Global variables *crash*
../src/mac/carbon/choice.cpp(217): assert "wxAssertFailure" failed: wxChoice::GetString(): invalid index
So it seems that debugging/fixing Code::Blocks with this compat setting turned off in wxWidgets 2.6 is a good idea to start with, as it is both good now and will also help running with wxWidgets 2.8 later ?
Started new thread C::B runtime errors when WXWIN_COMPATIBILITY_2_4=0
http://forums.next.codeblocks.org/index.php?topic=4573
Tim S
Note: wxSmith is NOT in this report;
waiting on the new wxSmith before trying to port to wxW2.8
Number of Warnings is from Windows XP Unicode wxW2.8 CVS Head;
compiled with minGW GCC 3.4.2 API 3.7
Number Area
87 Core
16 Contrib
103 Total
Number Section
7 scintilla
13 wxPropertyGrid
6 wxFlatNotebook
24 sdk
8 src
14 Compiler
4 Debugger
3 Code-completion
2 Class wizard
4 Scripted wizard
2 To-do
3 EnvVars Plug-In
5 C::B KeyBinder
8 wxPdfDocument
Number warning
51 comparison between signed and unsigned integer expressions
5 BeginDrawing is deprecated
5 EndDrawing is deprecated
2 __comp_ctor is deprecated
8 Inside is deprecated
1 SetFrame is deprecated
7 SetBestFittingSize is deprecated
1 GetBestFittingSize is deprecated
3 Member is deprecated
4 wxStartTimer is deprecated
4 wxGetElapsedTime is deprecated
2 wxGetWorkingDirectory is deprecated
2 wxGetAccelFromString is deprecated
2 converting to int from double
5 enumeration value ... not handled in switch
?? I missed some since count is off.
That is quite a lot I get about 6 in the core with GCC 4.1 and wxGTK 2.6.3 on Ubuntu Edgy.
Quote from: Game_Ender on December 03, 2006, 01:09:22 AM
That is quite a lot I get about 6 in the core with GCC 4.1 and wxGTK 2.6.3 on Ubuntu Edgy.
But, you just changed the compiler, I changed the wxWidgets library. There is no comparison between the two.
Note: when I did my changes with a prerelease minGW GCC 4.1.1 I got over 4000 warning. So, I am not sure how you got only 6.
Tim S
FYI:
2.8.0 has been released see http://sourceforge.net/project/showfiles.php?group_id=9863
Tim S
Unless I am very mistaken, this is not correct, it is the RC3, not the 2.8.0 release.
Both the news section on Sourceforge and the wxWidgets site say so.
No it is the final release or maybe RC4; RC3 was last week. They just started updating the web page a few hours ago. The download link is the first thing they changed it no longer has rc in it.
Some sub group put out an RC2 so they skipped it and went to RC3 last week, and this release is supposed to be the final release or RC4 according to the dev list. The people saying final release seems to be winning in the dev list.
Tim S
From http://sourceforge.net/forum/forum.php?forum_id=644606
QuotePosted By: juliansmart
Date: 2006-12-12 12:45
Summary: wxWidgets 2.8.0 released
December 12th, 2006: the wxWidgets team is pleased to announce a major new release. Compared with the last stable series (2.6), 2.8.0 adds wxAUI (an advanced user interface library for docking and other functionality), wxRichTextCtrl, wxComboCtrl, wxOwnerDrawnComboBox, wxTreebook, various picker controls such as wxColourPickerCtrl, wxHyperlinkCtrl, partial right-to-left language support, support for Core Graphics on Mac OS X, tar archive support, and more. Get wxWidgets from http://www.wxwidgets.org/downloads/.
Download links at http://sourceforge.net/project/showfiles.php?group_id=9863
Is it possible to build current C::B with wxWidgets 2.8, any patches required? Fedora Extras Development moved to WX 2.8 today, so I would like to be able to rebuild C::B with it in the near future.
It is not yet possible without a bunch of patches. As far as I know there are not much patches submitted, so you have to do it yourself.
Quote from: SharkCZ on December 15, 2006, 11:10:59 PM
Is it possible to build current C::B with wxWidgets 2.8, any patches required? Fedora Extras Development moved to WX 2.8 today, so I would like to be able to rebuild C::B with it in the near future.
Just the ones mentioned in the first message in this thread, note none of these have been tested under Linux, but some were tested under Mac by afb. These patches need testing, so if you have problems reply in this thread on it. And, I will look into it.
Tim S
I have looked at the first page and there are only patches for C::B, no patching of wxGTK is required. That´s good.
But without the patches, codeblocks will not compile, that's no good...
Quote from: mispunt on December 16, 2006, 10:59:08 PM
But without the patches, codeblocks will not compile, that's no good...
Correct, the patches are to get codeblocks to compile and link against wxWidgets 2.8. It runs and compiles itself, I can't say it does more than that. I have fixed the issues I found except for the fact it gives about 75 to 110 warnings.
Tim S
Hello all you wx 2.7.x and 2.8.x folks.
I am going to apply patches (one at a time) to get it to build for wx, only if they meet the following conditions (if those are acceptable conditions) :
1) all wx 2.7.x patches should be considered not existing [2.7.x are development series, not official release series]
-> so please adjust all your patches for 2.8 and remove all references to 2.7.x, I'd prefer not to look at any 2.7 patch at berlios and like to close it without looking at it. I'd prefer not tp spend time on them and then in the end find out that a little thing might have changed in the official 2.8
2) as a result of 1), I'd like to see all ifdef constructs referring to 2.7.x removed, I think we should not ifdef polute our code on unofficial versions, and certainly not versions we won't support, don't take this as an insult, I am very thankful for all the hard work, but in the end all that research will pay back in the "official 2.8 patches" ;-)
3) all patches should describe what they are doing :
a) how comes it does not work without the patch (so what did 2.8 break) [== the why]
b) a little explanation how wx 2.8 now does it
c) whatever information you can give to make our life easier to understand and apply the patches without doing the research ourself from scratch
4) OPEN QUESTION : I guess most linux distros are now already somewhere in the 2.6.x line [x can still be 1 or 2 or 3 !!!], can we kick out 2.4.x specific things ?
5) unfortunately we can't use anything yet of the new functionalities of wx 2.8 since probably it will take 6 months to 1 year until the major linux distros come with a newer version [some example : I think they have new about boxes or so ...]
Let me stress one thing : many many thanks to all of you who already sorted things out on what happened with wx ;-) , now it's just a little documentation step and cleaning.
Quote from: killerbot on December 18, 2006, 09:13:17 PM
Hello all you wx 2.7.x and 2.8.x folks.
I am going to apply patches (one at a time) to get it to build for wx, only if they meet the following conditions (if those are acceptable conditions) :
1) all wx 2.7.x patches should be considered not existing [2.7.x are development series, not official release series]
-> so please adjust all your patches for 2.8 and remove all references to 2.7.x, I'd prefer not to look at any 2.7 patch at berlios and like to close it without looking at it. I'd prefer not tp spend time on them and then in the end find out that a little thing might have changed in the official 2.8
2) as a result of 1), I'd like to see all ifdef constructs referring to 2.7.x removed, I think we should not ifdef polute our code on unofficial versions, and certainly not versions we won't support, don't take this as an insult, I am very thankful for all the hard work, but in the end all that research will pay back in the "official 2.8 patches" ;-)
I understand the above info and will change all the 2.7.x values to 2.8.0; and I will redo all the 2.7 patches as 2.8 patches. Therefore you can close the 2.7 ones from me. And, afb patches 1630 and 1627.
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1630&group_id=5358
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1627&group_id=5358
Quote from: killerbot on December 18, 2006, 09:13:17 PM
3) all patches should describe what they are doing :
a) how comes it does not work without the patch (so what did 2.8 break) [== the why]
b) a little explanation how wx 2.8 now does it
c) whatever information you can give to make our life easier to understand and apply the patches without doing the research ourself from scratch
I will add explanations to the patches.
Quote from: killerbot on December 18, 2006, 09:13:17 PM
4) OPEN QUESTION : I guess most linux distros are now already somewhere in the 2.6.x line [x can still be 1 or 2 or 3 !!!], can we kick out 2.4.x specific things ?
The values WXWIN_COMPATIBILITY_2_4 is actually a 2.6 item, so it can NOT be removed. But, WXWIN_COMPATIBILITY_2_2 can be if it exists somewhere.
Quote from: killerbot on December 18, 2006, 09:13:17 PM
5) unfortunately we can't use anything yet of the new functionalities of wx 2.8 since probably it will take 6 months to 1 year until the major linux distros come with a newer version [some example : I think they have new about boxes or so ...]
I understand this.
Quote from: killerbot on December 18, 2006, 09:13:17 PM
Let me stress one thing : many many thanks to all of you who already sorted things out on what happened with wx ;-) , now it's just a little documentation step and cleaning.
Thanks for the thank you.
Tim S
I am finished with the 2.8 changes and added reasons etc. If you want more info just ask.
Could you start on Patch #1732; it is causing a lot of work because the file has line ending issues so it is hard to do the diffs on it.
Thanks, Tim S
[ Patch #1732 ] keybinder plugin patches for wxWidgets 2.8 Submitted By: stahta01 based on afb work.
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1732&group_id=5358
Quote from: stahta01 on December 19, 2006, 01:00:32 PM
I am finished with the 2.8 changes and added reasons etc. If you want more info just ask.
Could you start on Patch #1732; it is causing a lot of work because the file has line ending issues so it is hard to do the diffs on it.
Thanks, Tim S
[ Patch #1732 ] keybinder plugin patches for wxWidgets 2.8 Submitted By: stahta01 based on afb work.
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1732&group_id=5358
I would rather not make any 2.7.x or 2.8.x changes to keyBinder until CB supports it, and certainly not until RC3 is out.
pecan
Quote from: Pecan on December 19, 2006, 03:48:42 PM
I would rather not make any 2.7.x or 2.8.x changes to keyBinder until CB supports it, and certainly not until RC3 is out.
pecan
Could you then fix the line ending issues with this file then. I have to convert from DOS to Mac line ending and then from Mac to DOS line endings to get good diffs on this file. File: src/plugins/contrib/keybinder/keybinder.cpp
Thanks for the good work on Code::Blocks, and waiting till RC3 is out is fine with me; and you only need to fix the line ending issue the next time you update the file.
Tim S
Quote from: stahta01 on December 19, 2006, 04:24:58 PM
Could you then fix the line ending issues with this file then. I have to convert from DOS to Mac line ending and then from Mac to DOS line endings to get good diffs on this file. File: src/plugins/contrib/keybinder/keybinder.cpp
Tim S
I don't understand. Do you mean that I should change keyBinder to Mac line endings? What about the Linux and Windows users?
Quote from: Pecan on December 19, 2006, 04:57:01 PM
Quote from: stahta01 on December 19, 2006, 04:24:58 PM
Could you then fix the line ending issues with this file then. I have to convert from DOS to Mac line ending and then from Mac to DOS line endings to get good diffs on this file. File: src/plugins/contrib/keybinder/keybinder.cpp
Tim S
I don't understand. Do you mean that I should change keyBinder to Mac line endings? What about the Linux and Windows users?
The file has two types of line endings in it; it makes doing diffs in Windows very hard to do.
Tim S
Quote from: stahta01 on December 19, 2006, 05:04:57 PM
The file has two types of line endings in it; it makes doing diffs in Windows very hard to do.
Tim S
Oh, I'll take a look. Thanks
Can anyone suggest a windows program to convert *.h *.cpp files like:
"unix2dos *.h" ?
As seen below, I can't seem to find a program that works.
thanks
C:\Usr\Proj\cbKeyBinder\RC3>unix2dos -h
unix2dos 2.2 Copyright (c) 1994-1995 Benjamin Lin. (1995.03.31)
Usage: unix2dos [-hkqV] [-o file ...] [-c convmode] [-n infile outfile ..
-h --help give this help
-k --keepdate keep output file date
-q --quiet quiet mode, suppress all warnings
always on in stdin->stdout mode
-V --version display version number
-c --convmode conversion mode
convmode ASCII, 7bit, ISO, default to ASCII
-o --oldfile write to old file
file ... files to convert in old file mode
-n --newfile write to new file
infile original file in new file mode
outfile output file in new file mode
C:\Usr\Proj\cbKeyBinder\RC3>unix2dos -o cbkeybinder.h
unix2dos: converting file cbkeybinder.h to DOS format ...
unix2dos: can not write to output file
unix2dos: problems converting file cbkeybinder.h
C:\Usr\Proj\cbKeyBinder\RC3>unix2dos cbkeybinder.h
unix2dos: converting file cbkeybinder.h to DOS format ...
unix2dos: can not write to output file
unix2dos: problems converting file cbkeybinder.h
C:\Usr\Proj\cbKeyBinder\RC3>unix2dos cbkeybinder.h cbkeybinder.h2
unix2dos: converting file cbkeybinder.h to DOS format ...
unix2dos: can not write to output file
unix2dos: problems converting file cbkeybinder.h
C:\Usr\Proj\cbKeyBinder\RC3>unix2dos -n cbkeybinder.h cbkeybinder.h2
unix2dos: converting file cbkeybinder.h to file cbkeybinder.h2 in DOS for
unix2dos: can not write to output file
unix2dos: problems converting file cbkeybinder.h to file cbkeybinder.h2
I tried to use unix2dos and dos2unix and failed.
I am doing it with UltraEdit; They have a 30 day trial. http://www.ultraedit.com/
http://www.ultraedit.com/index.php?name=Downloads&d_op=getit&lid=1
While it is good doing one file, it is NOT a good solution for many files at once.
Tim S
I do this on the bad file to fix it.
"File" -> "Conversions" -> "DOS to Mac"
"File" -> "Conversions" -> "Unix/Mac to DOS"
Edit: Looking for the SED script I used 3 or 4 months ago, could NOT find it. I ended up using Ultra-edit because it worked better for me.
This gives me the best result on the file keybinder.cpp
dos2unix *.cpp
unix2dos --convmode Mac *.cpp
unix2dos *.cpp
Edit: I am going to keep trying the results are NOT great looking
Tim S
I seem to be having lots of luck with this
http://www.gammon.com.au/downloads/dlutilities.htm
Download utilities
(http://www.gammon.com.au/downloads/dlutilities.htm%3Cbr%20/%3EDownload%20utilities)
It allows use of wildcards, like: *.h and *.cpp
unix2dos Version 1.01 (Gammon Software Solutions) 13-Mar-98
Processing wildcard "*.h"
cbkeybinder.h
debugging.h
keybinder.h
keybinderdef.h
menuutils.h
5 files converted.
2542 total lines converted.
0 errors.
0 warnings.
C:\Usr\Proj\cbKeyBinder\RC3>E:\User\Downloads\_Pending\Unix2Dos\unix2dos.exe *.c
pp
unix2dos Version 1.01 (Gammon Software Solutions) 13-Mar-98
Processing wildcard "*.cpp"
cbkeybinder.cpp
keybinder.cpp
menuutils.cpp
3 files converted.
4251 total lines converted.
0 errors.
0 warnings.
It also contains the a source code link.
Converting text files to/from Unix/Dos/Mac
* http://www.gammon.com.au/files/pennmush/unix2dos.zip - 19K - program to convert unix text files to DOS format
* http://www.gammon.com.au/files/pennmush/dos2unix.zip - 19K - program to convert DOS text files to Unix format
* http://www.gammon.com.au/files/pennmush/mac2unix.zip - 19K - program to convert Macintosh text files to Unix format
* http://www.gammon.com.au/files/pennmush/unix2mac.zip - 19K - program to convert Unix text files to Macintosh format
* http://www.gammon.com.au/files/pennmush/unix2dos.c - 7K - source code used to compile above 4 conversion programs
Quote from: stahta01 link=topic=4495.msg37214#msg37214
The file has two types of line endings in it; it makes doing diffs in Windows very hard to do.
Tim S
See if svn 3399 fixed the line ending situation in keyBinder.
Quote from: Pecan on December 19, 2006, 10:22:43 PM
Quote from: stahta01 link=topic=4495.msg37214#msg37214
The file has two types of line endings in it; it makes doing diffs in Windows very hard to do.
Tim S
See if svn 3399 fixed the line ending situation in keyBinder.
No, look at this method void wxKeyConfigPanel::OnProfileEditing(wxCommandEvent &) around line 2289.
It still has Mac line Endings there.
Tim S
Quote from: stahta01 on December 19, 2006, 10:39:29 PM
Quote from: Pecan on December 19, 2006, 10:22:43 PM
Quote from: stahta01 link=topic=4495.msg37214#msg37214
The file has two types of line endings in it; it makes doing diffs in Windows very hard to do.
Tim S
See if svn 3399 fixed the line ending situation in keyBinder.
No, look at this method void wxKeyConfigPanel::OnProfileEditing(wxCommandEvent &) around line 2289.
It still has Mac line Endings there.
Tim S
Well.. I'm sorry. I've done all I know how to do. I've run all those files through unix2dos and it says it converted them. I'm stumped..
I edited the source you liked to in order to make an dos2mac command
I then ran the below commands and it looks to fix the problem.
dos2mac *.cpp
mac2unix *.cpp
unix2dos *.cpp
svn propset eol-style native *.cpp
Tim S
Uploaded the changed source to http://www.savefile.com/projects/1039215
pick DOS2UNIX.zip
Have you tried setting svn:eol-style property (http://svnbook.red-bean.com/en/1.2/svn.advanced.props.html#svn.advanced.props.special.eol-style) to native? You should really have your SVN client set to automatically set that property (along with the mime type) on every file you add. When the property is set, subversion will make sure the eol style markers are just right.
Offtopic:
Many helpful little SVN tidbits are buried in that book. Code::Blocks would probably be helped by using the vendor branches (http://svnbook.red-bean.com/en/1.2/svn.advanced.vendorbr.html). Which would allow us to easily maintain custom versions of projects we depend on.
Quote from: Game_Ender on December 19, 2006, 11:01:34 PM
Have you tried setting svn:eol-style property (http://svnbook.red-bean.com/en/1.2/svn.advanced.props.html#svn.advanced.props.special.eol-style) to native? You should really have your SVN client set to automatically set that property (along with the mime type) on every file you add. When the property is set, subversion will make sure the eol style markers are just right.
Offtopic:
Many helpful little SVN tidbits are baried in that book. Code::Blocks would probably be helped by using the vendor branches (http://svnbook.red-bean.com/en/1.2/svn.advanced.vendorbr.html). Which would allow us to easily maintain custom versions of projects we depend on.
That types of things only help if the file has only one type of line endings this file has Mac and Native endings. I can fix only if I have write access. Tim S
Edit: I know how to fix this in CVS when I have write access, but since it is SVN and no write access. I can only fix the file each time myself. This means each time the file is edited I have to do manual work on the diff/patch file.
Note: I do agree svn:eol-style property to native is the correct thing to do, but I can NOT do it on the server. I can only do it on my machine which does NOT fix the issue of the server copy being damaged because svn:eol-style property was not set to native when someone edited in an old Mac setup.
Just did a little research, its odd that it fails on mixed line endings. Probably a pretection to keep you from setting it for binary files.
Quote from: stahta01 on December 19, 2006, 10:59:52 PM
I edited the source you liked to in order to make an dos2mac command
I then ran the below commands and it looks to fix the problem.
dos2mac *.cpp
mac2unix *.cpp
unix2dos *.cpp
svn propset eol-style native *.cpp
Tim S
Uploaded the changed source to http://www.savefile.com/projects/1039215
pick DOS2UNIX.zip
where do you put
svn propset eol-style native *.cpp
Quote from: Game_Ender on December 19, 2006, 11:13:15 PM
Just did a little research, its odd that it fails on mixed line endings. Probably a pretection to keep you from setting it for binary files.
SVN diff works it just produces garbage that I have to hand edit each time.
This is with this command.
svn.exe diff --extensions --unified=1 --extensions --ignore-eol-style > filename-unix.patch
The following command what's to remove nearly all the lines and then readd them with new line endings
svn.exe diff > filename-unix2.patch
Tim S
Quote from: Pecan on December 19, 2006, 11:29:09 PM
Quote from: stahta01 on December 19, 2006, 10:59:52 PM
I edited the source you liked to in order to make an dos2mac command
I then ran the below commands and it looks to fix the problem.
dos2mac *.cpp
mac2unix *.cpp
unix2dos *.cpp
svn propset eol-style native *.cpp
Tim S
Uploaded the changed source to http://www.savefile.com/projects/1039215
pick DOS2UNIX.zip
where do you put svn propset eol-style native *.cpp
I just run it on the command line in the directory with the problem.
You can leave it out, but using it should prevent this problem from happening again on this file.
As long as you commit the changes it should fix my issue, svn propset eol-style native *.cpp just sets the file to native line endings so the next Mac person or DOS person can't damage the line ending without a lot of work.
The above command my require the new version of SVN to work. I am using 1.4.2 I never noticed it till 1.4 version was installed.
Quote from: stahta01 on December 19, 2006, 10:59:52 PM
I edited the source you liked to in order to make an dos2mac command
I then ran the below commands and it looks to fix the problem.
dos2mac *.cpp
mac2unix *.cpp
unix2dos *.cpp
svn propset eol-style native *.cpp
Tim S
Uploaded the changed source to http://www.savefile.com/projects/1039215
pick DOS2UNIX.zip
SVN 3401:
-KeyBinder 1.0.9 2006/12/19
-Set all EOL to dos ala TimS instructions & svn propset eol-style native *.h and *.cpp (Thanks Tim)
Quote from: Pecan on December 19, 2006, 11:59:00 PM
SVN 3401:
-KeyBinder 1.0.9 2006/12/19
-Set all EOL to dos ala TimS instructions & svn propset eol-style native *.h and *.cpp (Thanks Tim)
Thanks, The following command no longer outputs garbage where it used to before.
svn.exe diff --extensions --unified=1 --extensions --ignore-eol-style > filename-unix.patch
Tim S
Quote from: killerbot on November 23, 2006, 11:06:42 PM
first of all, let's see what wx 2.8 brings . Will it fix some of the bugs we are suffering from the 2.6, if yes, then it light be interesting to use 2.8. If not, then might be best to wait.
That's great. It seems that we can do with TinyXML, wxScintilla, wxPropertyGrid and wxFlatNotebook etc. in the same way.
Using wx 2.8, we may remove wxAui from CB SVN :lol:
No we may not (yet) :P. We have to support wx 2.6 for some time, until we don't support it anymore we have to use the version in svn.
Hmm, can it be updated to the one currently in 2.8, the 2.8 wxAUI has the wxAUI notebook which gives you some level of tearable tabs.
It is possible to try it... ;) Those tabs are really amazing.
Aren't the toolbars new as well?
Quote from: Game_Ender on December 20, 2006, 07:38:34 AM
Hmm, can it be updated to the one currently in 2.8, the 2.8 wxAUI has the wxAUI notebook which gives you some level of tearable tabs.
[ Patch #1730 ] wxaui patch for wxWidgets 2.8 Submitted By: stahta01 based on afb work.
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1730&group_id=5358
The above patch changes it to using the wxaui in wxWidgets 2.8, if I understand it correctly afb wrote it and I just modified it for the release version of 2.8.0.
Tim S
Quote from: Game_Ender on December 20, 2006, 07:38:34 AM
Hmm, can it be updated to the one currently in 2.8, the 2.8 wxAUI has the wxAUI notebook which gives you some level of tearable tabs.
Tearable tabs? How?
Quote from: mispunt on December 20, 2006, 07:40:05 AM
It is possible to try it... ;) Those tabs are really amazing.
Aren't the toolbars new as well?
Yeah the tabs are kewl. :)
New toolbars? Hmm didn't see that......... It would be kewl if we had a wxAuiToolbar or something..
The quickest way to see it is to download wxPython 2.8 and its demos. There is a new wxAUI class called wxAUINotebook (wxWidgets needs to learn namespaces). Basically every frame becomes a notebook and you can move them between panes, or "tear" one out and create its own pane. The only thing they don't do currently is become floating windows. That for later releases.
Quote from: Game_Ender on December 20, 2006, 03:46:38 PM
The quickest way to see it is to download wxPython 2.8 and its demos. There is a new wxAUI class called wxAUINotebook (wxWidgets needs to learn namespaces). Basically every frame becomes a notebook and you can move them between panes, or "tear" one out and create its own pane. The only thing they don't do currently is become floating windows. That for later releases.
Yeah I use wxAuiNotebook, but I'm not sure how to make the tabs undock.... Or can they?
Just click and drag and you be able to place it some where else. There is no way to make them float.
Quote from: sethjackson on December 20, 2006, 02:33:24 PM
Tearable tabs? How?
You can drag tabs from one window to another, as long as you tell wxAUI where it could be placed...
Quote from: Game_Ender on December 20, 2006, 07:58:41 PM
Just click and drag and you be able to place it some where else. There is no way to make them float.
Oh ok. Yeah mine do that. I thought you meant you could make the tabs float.... :)
Quote from: sethjackson on December 20, 2006, 09:53:32 PM
Quote from: Game_Ender on December 20, 2006, 07:58:41 PM
Just click and drag and you be able to place it some where else. There is no way to make them float.
Oh ok. Yeah mine do that. I thought you meant you could make the tabs float.... :)
On the other hand, for floating tabs: http://www.eistware.com/aui_dock/wxFlatNotebookTest.zip
- Edit->Enable Drag And Drop of Tabs
- Edit->Enable Drag And Drop of Tabs to foreign notebooks[/tt]
so guess that'll made its way to wxAuiNotebook.
I am trying to compile C::B on Fedora Development with wxGTK 2.8.0 (all patches from the first post in this thread are applied) and I am getting an error when compiling PropertyGrid. Any idea?
/bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../src/sdk -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../src/sdk/propgrid/include -O2 -ffast-math -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -MT propgrid.lo -MD -MP -MF .deps/propgrid.Tpo -c -o propgrid.lo `test -f './src/propgrid/propgrid.cpp' || echo './'`./src/propgrid/propgrid.cpp
g++ -DHAVE_CONFIG_H -I. -I../../../src/sdk -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../src/sdk/propgrid/include -O2 -ffast-math -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -MT propgrid.lo -MD -MP -MF .deps/propgrid.Tpo -c ./src/propgrid/propgrid.cpp -fPIC -DPIC -o .libs/propgrid.o
/usr/include/wx-2.8/wx/hashmap.h: In member function 'wxLongToLongHashMap_wxImplementation_HashTable::Node** wxLongToLongHashMap_wxImplementation_HashTable::GetNodePtr(const long int&) const':
/usr/include/wx-2.8/wx/hashmap.h:714: warning: dereferencing type-punned pointer will break strict-aliasing rules
/usr/include/wx-2.8/wx/clntdata.h: In member function 'wxShadowObjectMethods_wxImplementation_HashTable::Node** wxShadowObjectMethods_wxImplementation_HashTable::GetNodePtr(const wxString&) const':
/usr/include/wx-2.8/wx/clntdata.h:20: warning: dereferencing type-punned pointer will break strict-aliasing rules
/usr/include/wx-2.8/wx/clntdata.h: In member function 'wxShadowObjectFields_wxImplementation_HashTable::Node** wxShadowObjectFields_wxImplementation_HashTable::GetNodePtr(const wxString&) const':
/usr/include/wx-2.8/wx/clntdata.h:25: warning: dereferencing type-punned pointer will break strict-aliasing rules
/usr/include/wx-2.8/wx/gdicmn.h: In member function 'wxStringToColourHashMap_wxImplementation_HashTable::Node** wxStringToColourHashMap_wxImplementation_HashTable::GetNodePtr(const wxString&) const':
/usr/include/wx-2.8/wx/gdicmn.h:540: warning: dereferencing type-punned pointer will break strict-aliasing rules
../../../src/sdk/propgrid/include/wx/propgrid/propgrid.h: In member function 'wxPGHashMapS2P_wxImplementation_HashTable::Node** wxPGHashMapS2P_wxImplementation_HashTable::GetNodePtr(const wxString&) const':
../../../src/sdk/propgrid/include/wx/propgrid/propgrid.h:1644: warning: dereferencing type-punned pointer will break strict-aliasing rules
../../../src/sdk/propgrid/include/wx/propgrid/propgrid.h: In member function 'wxPGHashMapI2I_wxImplementation_HashTable::Node** wxPGHashMapI2I_wxImplementation_HashTable::GetNodePtr(const size_t&) const':
../../../src/sdk/propgrid/include/wx/propgrid/propgrid.h:1668: warning: dereferencing type-punned pointer will break strict-aliasing rules
./src/propgrid/propgrid.cpp: In member function 'wxPGHashMapConstants_wxImplementation_HashTable::Node** wxPGHashMapConstants_wxImplementation_HashTable::GetNodePtr(const size_t&) const':
./src/propgrid/propgrid.cpp:988: warning: dereferencing type-punned pointer will break strict-aliasing rules
./src/propgrid/propgrid.cpp: In member function 'void wxArrayEditorDialog::OnDownClick(wxCommandEvent&)':
./src/propgrid/propgrid.cpp:2414: warning: comparison between signed and unsigned integer expressions
./src/propgrid/propgrid.cpp: In member function 'void wxPGProperty::ShowError(const wxString&)':
./src/propgrid/propgrid.cpp:2942: error: invalid static_cast from type 'wxWindow*' to type 'const wxFrame*'
./src/propgrid/propgrid.cpp:2942: error: incomplete type 'wxFrame' used in nested name specifier
./src/propgrid/propgrid.cpp:2945: error: invalid use of undefined type 'struct wxFrame'
/usr/include/wx-2.8/wx/log.h:74: error: forward declaration of 'struct wxFrame'
./src/propgrid/propgrid.cpp: In member function 'void wxPropertyGrid::DrawItems(wxDC&, unsigned int, unsigned int, const wxRect*)':
./src/propgrid/propgrid.cpp:7568: warning: 'BeginDrawing' is deprecated (declared at /usr/include/wx-2.8/wx/dc.h:392)
./src/propgrid/propgrid.cpp:7576: warning: 'EndDrawing' is deprecated (declared at /usr/include/wx-2.8/wx/dc.h:393)
./src/propgrid/propgrid.cpp: In member function 'void wxPropertyGrid::DoDrawItems(wxDC&, wxPGProperty*, wxPGProperty*, const wxRect*)':
./src/propgrid/propgrid.cpp:7781: warning: 'BeginDrawing' is deprecated (declared at /usr/include/wx-2.8/wx/dc.h:392)
./src/propgrid/propgrid.cpp:8518: warning: 'EndDrawing' is deprecated (declared at /usr/include/wx-2.8/wx/dc.h:393)
./src/propgrid/propgrid.cpp:8522: warning: 'BeginDrawing' is deprecated (declared at /usr/include/wx-2.8/wx/dc.h:392)
./src/propgrid/propgrid.cpp:8528: warning: 'EndDrawing' is deprecated (declared at /usr/include/wx-2.8/wx/dc.h:393)
./src/propgrid/propgrid.cpp: In member function 'void wxPropertyGrid::DrawItems(wxPGProperty*, wxPGProperty*)':
./src/propgrid/propgrid.cpp:8570: warning: 'BeginDrawing' is deprecated (declared at /usr/include/wx-2.8/wx/dc.h:392)
./src/propgrid/propgrid.cpp:8575: warning: 'EndDrawing' is deprecated (declared at /usr/include/wx-2.8/wx/dc.h:393)
./src/propgrid/propgrid.cpp: In member function 'void wxPropertyGrid::SelectProperty(wxPGProperty*, bool, bool, bool)':
./src/propgrid/propgrid.cpp:9900: error: invalid static_cast from type 'wxWindow*' to type 'const wxFrame*'
./src/propgrid/propgrid.cpp:9900: error: incomplete type 'wxFrame' used in nested name specifier
./src/propgrid/propgrid.cpp:9902: error: invalid use of undefined type 'struct wxFrame'
/usr/include/wx-2.8/wx/log.h:74: error: forward declaration of 'struct wxFrame'
make[4]: *** [propgrid.lo] Error 1
make[4]: Leaving directory `/builddir/build/BUILD/codeblocks/src/sdk/propgrid'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/builddir/build/BUILD/codeblocks/src/sdk'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/builddir/build/BUILD/codeblocks/src/sdk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/builddir/build/BUILD/codeblocks/src'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.59823 (%build)
You might try the newest wxPropertyGrid version 1.2.5
http://sourceforge.net/project/showfiles.php?group_id=133406
I looked up the line that errored out on you and it is the same code in version 1.2.5, so it is NOT likely to fix the problem.
I will try to see what the issue is with the patch to PropertyGrid under Linux.
I use andLinux Ubuntu; are you building it using code::blocks or the auto tools?
If you do use wxPropertyGrid 1.2.5; I have a patch for the new wxSmith that fixes compile and link errors under windows.
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1702&group_id=5358
Tim S
Quote from: stahta01 on December 23, 2006, 03:09:44 PM
You might try the newest wxPropertyGrid version 1.2.5
http://sourceforge.net/project/showfiles.php?group_id=133406
I looked up the line that errored out on you and it is the same code in version 1.2.5, so it is NOT likely to fix the problem.
I will try to see what the issue is with the patch to PropertyGrid under Linux.
I use andLinux Ubuntu; are you building it using code::blocks or the auto tools?
I am using autotools. The version 1.2.5 looks better as there are not any other warnings only the casting errors and I suspect the problem to be some incompatibility with GCC 4.1.1
Now I have tried to include the development snapshot of wxPropertyGrid and it compiles OK. Their changelog contains some "compatibilty fixes for WX 2.8.0" :-)
Quote from: SharkCZ on December 25, 2006, 05:37:00 PM
Now I have tried to include the development snapshot of wxPropertyGrid and it compiles OK. Their changelog contains some "compatibilty fixes for WX 2.8.0" :-)
Thanks for the feedback, I have NOT yet had time to test under andLinux. Will look at their patches.
Tim S
The wxPropertyGrid need this one-liner :-)
--- src/sdk/propgrid/src/propgrid/propgrid.cpp.orig 2006-12-25 17:41:15.000000000 +0100
+++ src/sdk/propgrid/src/propgrid/propgrid.cpp 2006-12-25 17:41:26.000000000 +0100
@@ -50,6 +50,7 @@
#include "wx/filedlg.h"
#include "wx/statusbr.h"
#include "wx/intl.h"
+ #include "wx/frame.h"
#endif
#include <wx/filename.h>
Another problem is in sdk/globals.cpp (it is platform dependent) - CentreOnScreen() doesn't exist for wxWindow, patch is here:
--- src/sdk/globals.cpp.orig 2006-12-25 17:54:36.000000000 +0100
+++ src/sdk/globals.cpp 2006-12-25 17:55:41.000000000 +0100
@@ -759,12 +759,16 @@
if(the_mode == pdlCentre || the_mode == pdlHead)
{
+#if wxCHECK_VERSION(2, 8, 0)
+ w->CentreOnParent();
+#else
if(w->GetParent())
w->CentreOnParent(); // poo!
else
w->CentreOnScreen();
return;
+#endif
}
else
{
And now I am stuck on wxSmith
g++ -DHAVE_CONFIG_H -I. -I../../../../../src/sdk -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../src/sdk -I../../../../../src/sdk/wxscintilla/include -I../../../../../src/sdk/propgrid/include -O2 -ffast-math -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -MT wxsstdmanager.lo -MD -MP -MF .deps/wxsstdmanager.Tpo -c wxsstdmanager.cpp -fPIC -DPIC -o .libs/wxsstdmanager.o
../properties/wxsstringlistcheckproperty.h: In member function 'void wxsArrayBool::resize(size_t, _wxArraywxsArrayBool)':
../properties/wxsstringlistcheckproperty.h:13: error: no matching function for call to 'wxsArrayBool::resize(size_t&, _wxArraywxsArrayBool&)'
/usr/include/wx-2.8/wx/dynarray.h:809: note: candidates are: void wxBaseArrayPtrVoid::resize(size_t, const void*)
Quote from: SharkCZ on December 25, 2006, 06:32:47 PM
And now I am stuck on wxSmith
g++ -DHAVE_CONFIG_H -I. -I../../../../../src/sdk -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../src/sdk -I../../../../../src/sdk/wxscintilla/include -I../../../../../src/sdk/propgrid/include -O2 -ffast-math -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -MT wxsstdmanager.lo -MD -MP -MF .deps/wxsstdmanager.Tpo -c wxsstdmanager.cpp -fPIC -DPIC -o .libs/wxsstdmanager.o
../properties/wxsstringlistcheckproperty.h: In member function 'void wxsArrayBool::resize(size_t, _wxArraywxsArrayBool)':
../properties/wxsstringlistcheckproperty.h:13: error: no matching function for call to 'wxsArrayBool::resize(size_t&, _wxArraywxsArrayBool&)'
/usr/include/wx-2.8/wx/dynarray.h:809: note: candidates are: void wxBaseArrayPtrVoid::resize(size_t, const void*)
The error looks easy but I could NOT figure it out in two hours, so I gave up. I have the New wxSmith working under wxW 2.8, I don't use wxSmith so it could have issues.
Tim S
Quote from: SharkCZ on December 25, 2006, 06:32:47 PM
The wxPropertyGrid need this one-liner :-)
--- src/sdk/propgrid/src/propgrid/propgrid.cpp.orig 2006-12-25 17:41:15.000000000 +0100
+++ src/sdk/propgrid/src/propgrid/propgrid.cpp 2006-12-25 17:41:26.000000000 +0100
@@ -50,6 +50,7 @@
#include "wx/filedlg.h"
#include "wx/statusbr.h"
#include "wx/intl.h"
+ #include "wx/frame.h"
#endif
#include <wx/filename.h>
I updated by patch [ Patch #1739 ] wxPropertyGrid patch for wxWidgets 2.8 for this issue, needs tested.
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1739&group_id=5358
Quote from: SharkCZ on December 25, 2006, 06:32:47 PM
Another problem is in sdk/globals.cpp (it is platform dependent) - CentreOnScreen() doesn't exist for wxWindow, patch is here:
--- src/sdk/globals.cpp.orig 2006-12-25 17:54:36.000000000 +0100
+++ src/sdk/globals.cpp 2006-12-25 17:55:41.000000000 +0100
@@ -759,12 +759,16 @@
if(the_mode == pdlCentre || the_mode == pdlHead)
{
+#if wxCHECK_VERSION(2, 8, 0)
+ w->CentreOnParent();
+#else
if(w->GetParent())
w->CentreOnParent(); // poo!
else
w->CentreOnScreen();
return;
+#endif
}
else
{
Created new patch for this using different solution, needs tested.
[ Patch #1762 ] CentreOnScreen patch for wxWidgets 2.8 Submitted By: stahta01
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1762&group_id=5358
Tim S
I have disabled building of wxSmith plugin and now I am able to successfully compile C::B svn3406 (nightly build from 20/12/2006) on Fedora Development with WX 2.8. Now other patches were required.
I applied most of the patches in svn, some I did local on my machine [the scripting one and the cbp's and for selecttarget I have disabled the event handler mapping to the old OnOK for the moment ] => I can build except wxSmith. Any news on that one ?
I even was able to run it, and at first glance very disappointed !!
In wx263 they introduced (apparently only on windows, since on linux it looks ok) the 'misalignment' of menus [entries with and without icons], were that was ok in wx 262. But breaking interfaces in wx 2.8 and deprecating stuff, plenty, but fixing the bugs they have introduced, hell no :-( :-( :-(
Quote from: killerbot on December 27, 2006, 05:28:04 PM
I applied most of the patches in svn, some I did local on my machine [the scripting one and the cbp's and for selecttarget I have disabled the event handler mapping to the old OnOK for the moment ] => I can build except wxSmith. Any news on that one ?
I have a patch for the new wxSmith, I have decided the old one is not worth the effort to fix. Also, I spent several hours and failed to find a fix for it. EDIT: An experienced wxWidgets and C++ person could maybe see a solution for it quickly, but it stumped me.
The patch for the new wxSmith is here.
[ Patch #1702 ] patch to the (correction in title) [NEW] wxSmith to use wxPropertyGrid version 1.2.x
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1702&group_id=5358
Note: the above patch patches for wxWidgets 2.8.0 and for use with wxPropertyGrid version 1.2.x; it still works with the old wxPropertyGrid 1.0.6 that C::B is currently using.
EDIT: I just reviewed my solution for the new wxSmith and it gave me idea on fixing the old wxSmith, so I am going to try again.
EDIT: created new patch for new wxSmith for wxWidgets 2.8 issues.
[ Patch #1766 ] NEW (experimental) wxSmith patch for wxWidgets 2.8 Submitted By: stahta01
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1766&group_id=5358
Tim S
Are the sources for the new wxSmith available somewhere? I cannot find them :-)
Quote from: SharkCZ on December 27, 2006, 08:23:36 PM
Are the sources for the new wxSmith available somewhere? I cannot find them :-)
How to get the new wxSmith is here
http://forums.next.codeblocks.org/index.php?topic=3765.msg33855#msg33855
Here's the last window checkout command I used.
SET PATH=C:\Program Files\Subversion\bin
CD codeblocks\src\plugins\contrib
svn checkout svn://svn.berlios.de/codeblocks/branches/New_wxSmith New_wxSmith
Tim S
Quote from: killerbot on December 27, 2006, 05:28:04 PM
I applied most of the patches in svn, some I did local on my machine [the scripting one and the cbp's and for selecttarget I have disabled the event handler mapping to the old OnOK for the moment ] => I can build except wxSmith. Any news on that one ?
The patch for the OLD wxSmith, note I don't use wxSmith so needs testing.
[ Patch #1767 ] Old wxSmith patch for wxWidgets 2.8
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1767&group_id=5358
Tim S
I am using the latest svn version now, but I still can't compile against 2.8. There seems to be a problem with the wxStartTime() and wxGetElapsedTime() (or something like that) in wxScintella. Those functions are deprecated (according to the documentation) but do not exist in the header files of wx.
Quote from: mispunt on December 28, 2006, 12:30:20 PM
I am using the latest svn version now, but I still can't compile against 2.8. There seems to be a problem with the wxStartTime() and wxGetElapsedTime() (or something like that) in wxScintella. Those functions are deprecated (according to the documentation) but do not exist in the header files of wx.
Have you applied the patches in the first message in this thread?
http://forums.next.codeblocks.org/index.php?topic=4495.msg35563#msg35563
Added patches needed below.
Patches to Code::Blocks projects files (Needed by windows Users ONLY):
[ Patch #1733 ] wxmsw28 patch for wxWidgets 2.8
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1733&group_id=5358
Patches to core Code::Blocks project:
[ Patch #1737 ] selecttargetdlg patch for wxWidgets 2.8 Submitted By: stahta01
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1737&group_id=5358
[ Patch #1731 ] scripting patch for wxWidgets 2.8
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1731&group_id=5358
Patches to contrib Code::Blocks projects:
[ Patch #1732 ] keybinder plugin patches for wxWidgets 2.8 Submitted By: stahta01 based on afb work.
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1732&group_id=5358
I am assuming Win XP and unicode is this correct?
How did you get wxWidgets 2.8.0? They had some issues packaging it, I downloaded the file wxMSW-2.8.0.tar.bz2.
Tim S
Quote from: mispunt on December 28, 2006, 12:30:20 PM
I am using the latest svn version now, but I still can't compile against 2.8. There seems to be a problem with the wxStartTime() and wxGetElapsedTime() (or something like that) in wxScintella. Those functions are deprecated (according to the documentation) but do not exist in the header files of wx.
Please verify the following is set to 1 in lib\gcc_dll\mswu\wx\setup.h
wxUSE_LONGLONG
WXWIN_COMPATIBILITY_2_6
They guard the code in wx/stopwatch.h
Tim S
I didn't apply those patches, the first one, I didn't see :P so I did it by hand ;)
The other two are not relevant to the problem (I think)
I use XP and wx unicode build. I got the wxALL-2.8.0.something (don't know exactly).
I will look to the WXWIN_COMPATIBILITY_2_6. Most likely that is the problem :)
*Edit* That was the problem. I had compiled it without 2.6 compatibility...
The patch for the OLD wxSmith for wxWidgets 2.8.0 bug
[ Patch #1771 ] Old wxSmith patch for wxListbook::HitTest protected wxW2.8
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1771&group_id=5358
I just found out today that I was NOT testing with the final release of wxWidgets 2.8.0; when I changed I got an new error in the old wxSmith fix above.
Tim S
RE: patch1732 to keybinder.
Looking at defs.h for 2.8.0,
WXK_PAGEUP,
WXK_PAGEDOWN,
#if WXWIN_COMPATIBILITY_2_6
WXK_PRIOR = WXK_PAGEUP,
WXK_NEXT = WXK_PAGEDOWN,
#endif
I don't get the purpose of the patch unless the intent is to run without 2.6 compatibilty.
Even if that were true, the patch hacks the problem and causes others (since new code will have to be written to avoid current dependency on wxk_prior/next).
Any explanation?
Quote from: Pecan on December 29, 2006, 07:16:05 PM
RE: patch1732 to keybinder.
Looking at defs.h for 2.8.0,
WXK_PAGEUP,
WXK_PAGEDOWN,
#if WXWIN_COMPATIBILITY_2_6
WXK_PRIOR = WXK_PAGEUP,
WXK_NEXT = WXK_PAGEDOWN,
#endif
I don't get the purpose of the patch unless the intent is to run without 2.6 compatibilty.
Even if that were true, the patch hacks the problem and causes others (since new code will have to be written to avoid current dependency on wxk_prior/next).
Any explanation?
The values need to be gated by WXWIN_COMPATIBILITY_2_6 because they are being used in a switch statement, if NOT done you get a compile error on duplicate CASE values.
Tim S
Quote from: stahta01 on December 29, 2006, 08:59:14 PM
The values need to be gated by WXWIN_COMPATIBILITY_2_6 because they are being used in a switch statement, if NOT done you get a compile error on duplicate CASE values.
Tim S
Yes, I finally get it. Commit 3440.
This does not mean that keyBinder will work properly with 2.8.
It just means no compiler errs.
We know, the most of the patches are to avoid compiler errors.
In fact, is it true that icons on the toolbar that should be grey, are invisible (well they are grey, but most of the time the whole area of the icon is dark grey)
Number of Warnings is from Windows XP Unicode wxW2.8 CVS Label WX_2_8_MICROFIX_BRANCH;
compiled with minGW GCC 3.4.2 API 3.8
Terms:
Main: the code compiled by project file CodeBlocks.cbp
Contrib: the code compiled by workspace file ContribPlugins.workspace
SDK: the code under folder src/sdk
Main Plugins:the code under src/plugins, but NOT under src/plugins/contrib
Contrib Plugins:the code under src/plugins/contrib
Core: the code under src/src
Number Area
87 Main
22 Contrib
109 Total
Number Section
7 SDK/wxscintilla
13 SDK/wxPropertyGrid
6 SDK/wxFlatNotebook
24 SDK other
8 Core
14 MainPlugins/Compiler
4 MainPlugins/Debugger
3 MainPlugins/Code-completion
2 MainPlugins/Class wizard
4 MainPlugins/Scripted wizard
2 MainPlugins/To-do
3 ContribPlugins/EnvVars Plug-In
5 ContribPlugins/C::B KeyBinder
8 ContribPlugins/Exporter/wxPdfDocument
6 ContribPlugins/wxSmith
Sections NOT worth patching because section is maintained by external group
SDK/wxscintilla
SDK/wxPropertyGrid
SDK/wxFlatNotebook
ContribPlugins/Exporter/wxPdfDocument
Note: I am working on a patch to upgrade wxPropertyGrid to a newer version 1.2.x
Deprecated methods NOT worth patching as long as C::B uses wxWidgets 2.6.x
wxWindow::SetBestFittingSize
wxWindow::GetBestFittingSize
wxPathList::Member
wxRect::Inside
::wxGetAccelFromString
Note: I plan to patch the MainPlugin/Compiler use of deprecated methods wxStartTimer & wxGetElapsedTime in a separate patch.
Totals after warning reduction patches and module upgrade patches applied
[Totals being ran at current time, will update totals after run is done.]
Number Area
29 Main
22 Contrib
51 Total
Number Section
7 SDK/wxscintilla
0 SDK/wxPropertyGrid
6 SDK/wxFlatNotebook
1 SDK other
4 Core
7 MainPlugins/Compiler
3 MainPlugins/Debugger
1 MainPlugins/Code-completion
0 MainPlugins/Class wizard
0 MainPlugins/Scripted wizard
0 MainPlugins/To-do
3 ContribPlugins/EnvVars Plug-In
5 ContribPlugins/C::B KeyBinder
8 ContribPlugins/Exporter/wxPdfDocument
6 ContribPlugins/wxSmith
Tim S
wxPropertyGrid update would be nice, as far as I have seen, only wxSmith uses this one. We should check with Byo if he's up to it. He will be back somewhere coming week I think.
I have uploaded my first patch to reduce warning when compiling Code::Blocks with wxWidgets 2.8.0
Please look at it and OK the use of the global typedef name of cbItemCount so I can work on the later patches that will use it.
Thank you
Tim S
[ Patch #1788 ] SDK patch to reduce warning for wxWidgets 2.8
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1788&group_id=5358
Quote from: killerbot on January 01, 2007, 10:54:23 AM
wxPropertyGrid update would be nice, as far as I have seen, only wxSmith uses this one. We should check with Byo if he's up to it. He will be back somewhere coming week I think.
Here's the thread I am working on the patch to upgrade wxPropertyGrid to version 1.2.6.
http://forums.next.codeblocks.org/index.php?topic=4638.0
Note: The patch will be about 2.6 megs or more in size is this a problem on the Berlios Server end?
It was a problem when I tried to upload it last time, but it was an issue on my end, that I think I have fixed.
Note, Firefox was having issues uploading a file that large, but IE7 had no issue to a different server.
(I am on a dialup connection which is causing a time out issue.)
Tim S
What patches should I use to compile C::B under Linux with New_wxSmith ?
Have you been able to compile the NEW wxSmith using wxWidgets 2.6?
If not, please try that first.
After you can compile the NEW wxSmith using wxWidgets 2.6.
Apply patch [ Patch #1766 ] NEW (experimental) wxSmith patch for wxWidgets 2.8
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1766&group_id=5358
Then compile the patched NEW wxSmith using wxWidgets 2.6.
After that works, compile the patched NEW wxSmith using wxWidgets 2.8.
Tim S
g++ -DHAVE_CONFIG_H -I. -I../../../../../src/sdk -I/usr/lib/wx/include/gtk2-unicode-release-2.8
-I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__
-pthread -I../../../../../src/sdk -I../../../../../src/sdk/wxscintilla/include -I../../../../../src/sdk/propgrid/include -O2
-ffast-math -g -O2 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -MT wxsarraystringeditordlg.lo
-MD -MP -MF .deps/wxsarraystringeditordlg.Tpo -c
./wxsarraystringeditordlg.cpp -fPIC -DPIC -o .libs/wxsarraystringeditordlg.o
./wxsarraystringeditordlg.h:31: error: extra qualification 'wxsArrayStringEditorDlg::' on member 'OnCancel'
That's the problem =/.. almost working.. =D
However, it's already working with wx2.8 :D, just need to compile the last plugins when this problem get solved.
EDIT: Strange.. I recompiled everything and I didn't get this error anymore o.O
Hey, everybody, ¡¡ GOOD NEW YEAR!! :lol:
Now, I have the revision 3474 and I trying to compile with the new wxWidgets with the last wxGridProperty but from a few revisons to it I always have this error:
g++ -DHAVE_CONFIG_H -I. -I. -I. -I/opt/wx/2.8//lib/wx/include/gtk2-unicode-release-2.8 -I/opt/wx/2.8//include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_LARGEFILE_SOURCE=1 -D__WXGTK__ -pthread -I../../src/sdk/wxscintilla/include -I../../src/sdk/tinyxml -I../../src/sdk/scripting/include -I../../src/sdk/scripting/sqplus -I../../src/sdk/wxFlatNotebook/include -I../../src/sdk/propgrid/include -O2 -ffast-math -O3 -mmmx -march=pentium4 -funroll-loops -fexpensive-optimizations -fPIC -DPIC -MT editorconfigurationdlg.lo -MD -MP -MF .deps/editorconfigurationdlg.Tpo -c editorconfigurationdlg.cpp -fPIC -DPIC -o .libs/editorconfigurationdlg.o
editorconfigurationdlg.cpp: In constructor `
EditorConfigurationDlg::EditorConfigurationDlg(wxWindow*)':
editorconfigurationdlg.cpp:235: error: invalid use of undefined type `struct
wxImageList'
/opt/wx/2.8/include/wx-2.8/wx/generic/listctrl.h:16: error: forward declaration
of `struct wxImageList'
editorconfigurationdlg.cpp:240: error: `Add' undeclared (first use this
function)
editorconfigurationdlg.cpp:240: error: (Each undeclared identifier is reported
only once for each function it appears in.)
editorconfigurationdlg.cpp: In member function `void
EditorConfigurationDlg::AddPluginPanels()':
editorconfigurationdlg.cpp:281: error: `Add' undeclared (first use this
function)
editorconfigurationdlg.cpp:283: error: `GetImageCount' undeclared (first use
this function)
editorconfigurationdlg.cpp: In member function `void
EditorConfigurationDlg::UpdateSampleFont(bool)':
editorconfigurationdlg.cpp:488: warning: `__comp_ctor' is deprecated (declared
at /opt/wx/2.8/include/wx-2.8/wx/gtk/fontdlg.h:48)
make[4]: *** [editorconfigurationdlg.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
So,someone can help me. :?
PD: I don't know if this post can be done here.
Please excuse me if that is the case.
Quote from: Ryu on January 10, 2007, 07:00:31 PM
Hey, everybody, ¡¡ GOOD NEW YEAR!! :lol:
Now, I have the revision 3474 and I trying to compile with the new wxWidgets with the last wxGridProperty but from a few revisons to it I always have this error:
What version of wxWidgets 2.8? 2.8.0? 2.8.1? 2.8-cvs?
What version of wxPropertyGrid ? 1.2.5? 1.2.6prelease?
What OS? Linux? Windows?
Note: I have not tested it today or yesterday, the changes they did could have broken it.
Will try it right now.
The changes broke some of the patches, will work on them tomorrow.
Tim S
Hey, stahta01
I'm sorry, the information is:
wxWidgets 2.8.0 (oficial release)
wxPropertyGrid 1.2.5
SO: Linux
Quote from: Ryu on January 10, 2007, 07:25:23 PM
Hey, stahta01
I'm sorry, the information is:
wxWidgets 2.8.0 (oficial release)
wxPropertyGrid 1.2.5
SO: Linux
wxPropertyGrid 1.2.5 had Linux issue in it.
Please try the snapshot at
http://wxpropgrid.sourceforge.net/cgi-bin/index?page=download#snapshots
Or Try my C::B patch 1.2.6Prerelease at
Quote from: stahta01 on December 04, 2006, 02:53:25 PM
http://www.savefile.com/projects/1039215
wxpropgrid_1_2_6_prerelease-unix.patch
Tim S
Build error on Ubuntu 6.10 (Edgy Eft) with wxWidgets 2.8.1 and all of the most recent patches applied:
Quote
g++ -DHAVE_CONFIG_H -I. -I../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems -I../../../../../../src/sdk -I/usr/local/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../../../src/sdk -I../../../../../../../src/sdk/wxFlatNotebook/include -I../../../../../../../src/sdk/wxscintilla/include -I../../../../../../../src/sdk/wxFlatNotebook -I../../../../../../../src/sdk/propgrid/include -O2 -ffast-math -g -O2 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -MT wxsdatepickerctrl.lo -MD -MP -MF .deps/wxsdatepickerctrl.Tpo -c ../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./wxsdatepickerctrl.cpp -fPIC -DPIC -o .libs/wxsdatepickerctrl.o
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h:114: error: 'wxArrayString' does not name a type
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h: In member function 'const wxString& wxsEvents::GetHandler(int)':
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h:80: error: 'm_Functions' was not declared in this scope
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h: In member function 'void wxsEvents::SetHandler(int, const wxString&)':
../../../../../../../src/plugins/contrib/New_wxSmith/wxwidgets/defitems/./../wxsevents.h:83: error: 'm_Functions' was not declared in this scope
make[2]: *** [wxsdatepickerctrl.lo] Error 1
make[2]: Leaving directory `/home/bjorn/dev/apps/codeblocks/build/src/plugins/contrib/New_wxSmith/wxwidgets/defitems'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/bjorn/dev/apps/codeblocks/build/src/plugins/contrib/New_wxSmith/wxwidgets'
make: *** [all-recursive] Error 1
Oh, and I'm using the new wxSmith (probably obvious by reading the error output).
Thanks :)
I am retesting my patch under windows and seeing if it works still.
I am having problems compiling under windows linking against wxWidgets 2.8.1.
Will work on a fix and post more info when I find cause/solution.
Tim S
nottin:
Did you apply the patch #1766
[ Patch #1766 ] NEW (experimental) wxSmith patch for wxWidgets 2.8 Submitted By: stahta01
https://developer.berlios.de/patch/?func=detailpatch&patch_id=1766&group_id=5358
How to get the new wxSmith is here
http://forums.next.codeblocks.org/index.php?topic=3765.msg33855#msg33855
Tim S
Edit: From the errors you got I suggest trying this patch; I have updated my patch with the code show below.
Index: wxwidgets/defitems/wxsnotebook.cpp
===================================================================
--- wxwidgets/defitems/wxsnotebook.cpp (revision 3483)
+++ wxwidgets/defitems/wxsnotebook.cpp (working copy)
@@ -21,6 +21,10 @@
* $HeadURL$
*/
+#ifndef CB_PRECOMP
+ #include <wx/notebook.h>
+#endif
+
#include "wxsnotebook.h"
#include "../../wxsadvqppchild.h"
Index: wxwidgets/wxsevents.h
===================================================================
--- wxwidgets/wxsevents.h (revision 3483)
+++ wxwidgets/wxsevents.h (working copy)
@@ -1,6 +1,10 @@
#ifndef WXSEVENTS_H
#define WXSEVENTS_H
+#ifndef WX_PRECOMP
+ #include <wx/arrstr.h>
+#endif
+
#include <tinyxml/tinyxml.h>
#include "../wxscodinglang.h"
Index: wxwidgets/wxsstyle.h
===================================================================
--- wxwidgets/wxsstyle.h (revision 3483)
+++ wxwidgets/wxsstyle.h (working copy)
@@ -1,6 +1,10 @@
#ifndef __WXSSTYLE_H
#define __WXSSTYLE_H
+#ifndef WX_PRECOMP
+ #include <wx/arrstr.h>
+#endif
+
#include "../wxscodinglang.h"
#include <wx/dynarray.h>
Builds now.
Thanks for your help :)
I have started a new thread to start work on wxWidgets 2.9 patches
Tim S
Patches to compile and link C::B against wxWidgets 2.9
http://forums.next.codeblocks.org/index.php?topic=4982.msg39004#msg39004
Quote from: Ryu on February 02, 2007, 08:38:38 PM
Hey, everybody, good times for all
Now i have the last subversion revision: 3562 and I trying to compile it aganist the last oficial release of wxWidgets 2.8.0
I'm following the respectives directives (patchs) of the post about the fact, but i can't get it, i always get this:
g++ -DHAVE_CONFIG_H -I. -I. -I. -I/opt/wx/2.8//lib/wx/include/gtk2-unicode-release-2.8 -I/opt/wx/2.8//include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_LARGEFILE_SOURCE=1 -D__WXGTK__ -pthread -I../../src/sdk/wxscintilla/include -I../../src/sdk/tinyxml -I../../src/sdk/scripting/include -I../../src/sdk/scripting/sqplus -I../../src/sdk/wxFlatNotebook/include -I../../src/sdk/propgrid/include -O2 -ffast-math -O3 -mmmx -march=pentium4 -funroll-loops -fexpensive-optimizations -fPIC -DPIC -MT editorconfigurationdlg.lo -MD -MP -MF .deps/editorconfigurationdlg.Tpo -c editorconfigurationdlg.cpp -fPIC -DPIC -o .libs/editorconfigurationdlg.o
editorconfigurationdlg.cpp: In constructor `
EditorConfigurationDlg::EditorConfigurationDlg(wxWindow*)':
editorconfigurationdlg.cpp:235: error: invalid use of undefined type `struct
wxImageList'
/opt/wx/2.8/include/wx-2.8/wx/generic/listctrl.h:16: error: forward declaration
of `struct wxImageList'
editorconfigurationdlg.cpp:240: error: `Add' undeclared (first use this
function)
editorconfigurationdlg.cpp:240: error: (Each undeclared identifier is reported
only once for each function it appears in.)
editorconfigurationdlg.cpp: In member function `void
EditorConfigurationDlg::AddPluginPanels()':
editorconfigurationdlg.cpp:281: error: `Add' undeclared (first use this
function)
editorconfigurationdlg.cpp:283: error: `GetImageCount' undeclared (first use
this function)
editorconfigurationdlg.cpp: In member function `void
EditorConfigurationDlg::UpdateSampleFont(bool)':
editorconfigurationdlg.cpp:488: warning: `__comp_ctor' is deprecated (declared
at /opt/wx/2.8/include/wx-2.8/wx/gtk/fontdlg.h:48)
Please help, i read that other people can do it, so i want too.
Note: If you read the first part of the error you see that is a problem with wxWidgets itself, but how can the others
to compile ?
OS: Linux
This appears to be an pre compile of headers issue. I am working on issues with getting ready to compile codeblocks against wxW29 and also working on precomp issues. I will update this message when I find a patch for this issue. The other Linux users most likely patched it themselves by adding an include of <wx/imaglist.h>
Try my CB_PRECOMP-unix.patch patch on http://www.savefile.com/projects/1039215
Tim S
I am working on a patch for C::B to fix the following issues for disable compat26 under wxWidgets 2.8.
From wx/toplevel.h (wxWidgets 2.6.1)
// deprecated versions defined for compatibility reasons
#define wxRESIZE_BOX wxMAXIMIZE_BOX
#define wxTHICK_FRAME wxRESIZE_BORDER
// obsolete styles, unused any more
#define wxDIALOG_MODAL 0
#define wxDIALOG_MODELESS 0
#define wxNO_3D 0
#define wxUSER_COLOURS 0
From wx/toplevel.h (wxWidgets cvs head)
#if WXWIN_COMPATIBILITY_2_6
// deprecated versions defined for compatibility reasons
#define wxRESIZE_BOX wxMAXIMIZE_BOX
#define wxTHICK_FRAME wxRESIZE_BORDER
// obsolete styles, unused any more
#define wxDIALOG_MODAL 0
#define wxDIALOG_MODELESS 0
#define wxNO_3D 0
#define wxUSER_COLOURS 0
#endif // WXWIN_COMPATIBILITY_2_6