The 22 January 2007 build is out.

[killerbot]

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw26u_gcc_cb_wx2.6.3p2.7z

To fix the menu alignment bug introduced in wx 2.6.3 [windows only bug] we have patched wx ourselves, and that results in the following alternative dll : http://prdownload.berlios.de/codeblocks/wxmsw26u_gcc_cb_wx2.6.3p2AndCbPatch_version3.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10.7z

For support of ansi builds, a link to the ansi windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw26_gcc_cb_wx2.6.3p2.7z

The 22 January 2007 build is out.
  - Windows : http://prdownload.berlios.de/codeblocks/CB_20070122_rev3527_win32.7z
  - Linux :
         http://prdownload.berlios.de/codeblocks/CB_20070122_rev3527_Ubuntu6.xx.deb
         http://prdownload.berlios.de/codeblocks/CB_20070122_rev3527_suse100+101.i586.rpm (not yet)
         http://prdownload.berlios.de/codeblocks/CB_20070122_rev3527_fc4+5.i586.rpm (not yet)


Resolved Fixed:

• wxSmith : Added missing or misplaced "event.Skip()" in wxSmith event handlers (caused code-completion - among others - to *not* run)

Regressions/Confirmed/Annoying/Common bugs:

• toolbar-images-not-changing-state (is a wx problem/Win XP problem)
• menu items with icon not correctly aligned (since wx263) (is fixed with our special wx263/wx28 dll)

[byo]

• wxSmith : Added missing or misplaced "event.Skip()" in wxSmith event handlers (caused code-completion - among others - to *not* run)

:oops: Forgot about it, again :shock:
Same bug was in old wxSmith right after adding wxSmith's code into C::B
Thx Mandrav for fixing that

[jiao]

I get the invalid compiler [YOUR ANSWER IS ALREADY THERE. SEARCH THE FORUMS!] message.

It's because my MingW folder is inside my codeblocks folder so I setup the paths like $(codeblocks)\MinGW\include
If I put it back to normal paths, c:\etc... then it works. Any way to fix this?

[killerbot]

I get the invalid compiler [YOUR ANSWER IS ALREADY THERE. SEARCH THE FORUMS!] message.

It's because my MingW folder is inside my codeblocks folder so I setup the paths like $(codeblocks)\MinGW\include
If I put it back to normal paths, c:\etc... then it works. Any way to fix this?

see here : http://forums.next.codeblocks.org/index.php?topic=4985.msg39081#msg39081 (and some replies to it, and some pre-replies ;-) )

Yours is even more special, during the check the $() are not being replaced, where they are (probably) when the build command is constructed.

[drrngrvy]

On the ubuntu (6.10) build of code::blocks, there is a spare bit of whitespace at:  File -> Save a ll files.

Apart from that it's excellent!

[marfi]

At the first, I must to say that the progress of wxSmith is great! However, I played with it today and I found out that the design area doesn't refresh correctly (see attached picture).

Another problem (maybe feature  ) is, that event handlers are connected to controls by Connect() function even if an Event table is declared and used (but it is empty)... Is possible to change (specify) this behaviour by a user?

And the last (but not least ) suggestion: I would be very nice to have visual menu (toolbar, status bar) editor ...


[attachment deleted by admin]

[Pecan]

On the ubuntu (6.10) build of code::blocks, there is a spare bit of whitespace at:  File -> Save a ll files.

Apart from that it's excellent!

Yes, there is a patch (1851) for this already submitted.

[tretton]

Excellent work as always, everyone!

Just one thing: Can you not use a global variable (like $(#mingw)) when setting the MinGW Compiler's installation directory under Compiler and debugger?

[byo]

At the first, I must to say that the progress of wxSmith is great! However, I played with it today and I found out that the design area doesn't refresh correctly (see attached picture).

Problem known for me :?. Unfortunately I don't have any idea on how to easily fix that because of some wxSmith internals. So I'll probably provide Refresh button till I find better solution.

Another problem (maybe feature  ) is, that event handlers are connected to controls by Connect() function even if an Event table is declared and used (but it is empty)... Is possible to change (specify) this behaviour by a user?

I've decided to stiwch into this scheme since it has few nice features:

   
• Doesn't trigger events during create time (that could produce some errors since event handler is called before all items are craeted - f.ex. event triggereed on text change in text ctrl may read data from widget not yet created)
• It will allow connecting all events like wxPaintEvent, wxMouseEvent etc. to ALL widgets (just like in builder )
• In fact this approach is preffered over old event tables in many new guis (AFAIK VS 2005 connected events in this way)

Connecting events through Connect() method has all adventages of event tables and allow much more. Can you exactly say why you prefer event tables ? Maybe there's some feature I don't know about in such case some switch between methosd should be enough.

And the last (but not least ) suggestion: I would be very nice to have visual menu (toolbar, status bar) editor ...

It's on the way. I can't exactly say when but it's one of most important features to add in near future .

Regards
   BYO

[marfi]

To Byo:

Can you exactly say why you prefer event tables ? Maybe there's some feature I don't know about Smile in such case some switch between methosd should be enough.

It is probably force of habit   I agree that an usage of Connect() function is elegant and this approach is "modern", but in my opinion, Connect() functions together with empty event table in one source file is quite confusing for a user ("Do I something wrong? The event table is still empty..."). Moreover, some users may prefer event tables for their personal reasons, so I vote for an abbility to choose which way of event processing will be used in my project. But for a now, removing of unused event tables will be good enought

[mandrav]

It is probably force of habit   I agree that an usage of Connect() function is elegant and this approach is "modern", but in my opinion, Connect() functions together with empty event table in one source file is quite confusing for a user ("Do I something wrong? The event table is still empty...").

As a sidenote, the event table must be declared, even if empty, so that wxWidgets setup event handling for this particular widget.

[byo]

As a sidenote, the event table must be declared, even if empty, so that wxWidgets setup event handling for this particular widget.

Not exactly - When there's no DECLARE_EVENT_TABLE() in class declaration, no event table is needed. So the code could be created without a bit of event tables

I've left empty event table for two reasons. First: just in case of my mistake, if Connect didn't worked, there is easy switch to old scheme. But as long as it's not needed I don't plan any use of event tables (need extra work since there may be some side effects). I'll remove //(*EventTable //*) block soon but I think that empty event table maybe left as it is since one may want to add it's own events which is easier using event tables (and this is the second reason ).

Just to prove that Connect is better, today's nightly will have support for most standard events: paint, mouse and keyboard That could NOT be done using event tables (there are few problems with some widgets but unfortunately this is wxWidgets problem )

Regards
   BYO

[mandrav]

As a sidenote, the event table must be declared, even if empty, so that wxWidgets setup event handling for this particular widget.

Not exactly - When there's no DECLARE_EVENT_TABLE() in class declaration, no event table is needed. So the code could be created without a bit of event tables

Hmm, I remember that without an event table declared I couldn't use Connect()...
Anyway, since you 're the GUI guru, I 'll take your word for it .

[byo]

Hmm, I remember that without an event table declared I couldn't use Connect()...
Anyway, since you 're the GUI guru, I 'll take your word for it .

Just checked it, works perfectly without tables .
BTW I've had some problems with connecting events through event table in one situation... sounds like buggy event dipatching system in wx :/

[MortenMacFly]

I didn't know really where to post bug report for the wxSmith plugin but I am sure Byo is reading this and anyway - it's somehow related to this nightly. ;-)

But first of all: GREAT WORK! Really! It is really good to have you working on that. I have converted my projects that use wxsmith to the new format and working with the *new* version from today on.

So far all was working smoothly until I opened the C::B workspace. This includes plugins that use the (old) wxSmith format. wxSmith asked me whether it should convert this project but I said "no". The result: Crash Boom Bang! ;-)

The stacktrace (SVN revision 3535) is:

Code Select Expand


src/sdk/tinyxml/tinyxml.h:516
src/plugins/contrib/wxSmith/wxsproject.cpp:85
src/plugins/contrib/wxSmith/wxsmith.cpp:166
src/sdk/projectloader_hooks.h:49

...and so on...

For your reference:

Code Select Expand


src/plugins/contrib/wxSmith/wxsproject.cpp:85

points to

Code Select Expand


for ( TiXmlNode* Node = SmithNode->FirstChild(); Node; Node=Node->NextSibling() )

in the wxSmith code. Seems like "Node" is a NULL pointer or something... but actually this cannot be (on second thoughts)?!

Anyway - there is no reason for me to keep the old format, so I converted them all (as I said before). But, Byo, you may want to take a look at this. It should be reproducible if you open the C::B workspace (and/or the contrib plugin workspace) just as it is in SVN now.

Many thanks again for your hard work!

With regards,

Morten.