The 21 July 2012 build (8150) is out.

[stefanos_]

WIth svn-8163, Windows XP (SP3), TDM's GCC 4.6.1 [32-bit], a few issues remain the same.

• The tooltip popup issue remains as is. Original report is here http://forums.codeblocks.org/index.php/topic,16560.msg112659.html#msg112659
• When you double click on any GUI particle that can generate an event, and you decide to undo, the generated code remains whereas the GUI particle from wxSmith it gets deleted as it should.
• The entire generated code became dark blue italic and it's very confusing to work with it. Is it the same issue people have with syntax highlighting maybe?
• Another thing that does not seem right, is when you have two wxSmith files and you want to move elements from one to the other; it does not support DnD, very annoying and counter productive!

[ollydbg]

Another thing that does not seem right, is when you have two wxSmith files and you want to move elements from one to the other; it does not support DnD, very annoying and counter productive![/li][/list]

wxSmith even does not support multiply selected feature. E.g. drag the mouse to select some items.

The code base of wxSmith is quite complex for me . It was not maintained for a long time.

[Alpha]

• The entire generated code became dark blue italic and it's very confusing to work with it. Is it the same issue people have with syntax highlighting maybe?

That was an added feature (with the idea that code generated by wxSmith should normally not be edited, so coloring it can be a reminder).  It can be turned off through Settings->Editor...->C/C++ Editor options (tab)->Highlight wxSmith sections differently.

[stefanos_]

wxSmith even does not support multiply selected feature. E.g. drag the mouse to select some items.

The code base of wxSmith is quite complex for me . It was not maintained for a long time.

Indeed I have seen some C::B code myself and got lost. Also the generated code needs clean up...a lot.

For example, the generated code for 2.9.x should be totally different than the 2.8.x. e.g. wxT() / _T() is unnecessary if you don't care about backward compatibility; it has got replaced with actual double quotes which is very cool i would say. Also, wxNewId() got deprecated in favor of wxID_ANY to avoid conflicts with user define IDs.

That's all i can remember right now. If i find anything else, i will update my message here.

[oBFusCATed]

stefanos_:
1. 2.9 is not released yet, so they can change their mind
2. we don't support it in wxsmith officially as far as I know

[stefanos_]

Guys, can someone tell me if line 29 from include\cbplugin.h is correct? Should not be named PLUGIN_IMPORT?

As it is right now makes no sense to me I'm afraid...

Code

#ifdef __WXMSW__
    #ifndef PLUGIN_EXPORT
        #ifdef EXPORT_LIB
            #define PLUGIN_EXPORT __declspec (dllexport)
        #else // !EXPORT_LIB
            #ifdef BUILDING_PLUGIN
                #define PLUGIN_EXPORT __declspec (dllexport)
            #else // !BUILDING_PLUGIN
                #define PLUGIN_EXPORT __declspec (dllimport)
            #endif // BUILDING_PLUGIN
        #endif // EXPORT_LIB
    #endif // PLUGIN_EXPORT
#else
    #define PLUGIN_EXPORT
#endif

Also, this link clear things up a bit about what is dllimport and what is dllexport. http://msdn.microsoft.com/en-us/library/81h27t8c(v=vs.80).aspx

[ptDev]

Guys, can someone tell me if line 29 from include\cbplugin.h is correct? Should not be named PLUGIN_IMPORT?

As it is right now makes no sense to me I'm afraid...

Code

#ifdef __WXMSW__
    #ifndef PLUGIN_EXPORT
        #ifdef EXPORT_LIB
            #define PLUGIN_EXPORT __declspec (dllexport)
        #else // !EXPORT_LIB
            #ifdef BUILDING_PLUGIN
                #define PLUGIN_EXPORT __declspec (dllexport)
            #else // !BUILDING_PLUGIN
                #define PLUGIN_EXPORT __declspec (dllimport)
            #endif // BUILDING_PLUGIN
        #endif // EXPORT_LIB
    #endif // PLUGIN_EXPORT
#else
    #define PLUGIN_EXPORT
#endif

Also, this link clear things up a bit about what is dllimport and what is dllexport. http://msdn.microsoft.com/en-us/library/81h27t8c(v=vs.80).aspx

It looks like the intention was to define PLUGIN_EXPORT as dllexport if either of EXPORT_LIB or BUILDING_PLUGIN is defined.
PLUGIN_EXPORT was a poor choice of macro name (something like CB_PLUGIN_API would have been better imho).
That arrowhead certainly could be simplified.

[MortenMacFly]

Guys, can someone tell me if line 29 from include\cbplugin.h is correct? Should not be named PLUGIN_IMPORT?

It is correct. You control basically if the plugin (or declared methods) export their signature. Notice the difference in both lines:
__declspec (dllexport)
and
__declspec (dllimport)
We want to have one macro to achieve both: exporting and importing. If it would have two different names this would not work.

[chice]

in rev8150 windows version, many resources (eg: icons) are broken and can not be displayed correctly.

rev8086 is ok.

[Alpha]

This change in lexer_cpp.xml:

Code

                <Style name="Comment (normal)"
                        index="1,23"
                        fg="160,160,160"/>

is causing problems. When i changed it back to the previous form:

Code

                <Style name="Comment (normal)"
                        index="1"
                        fg="160,160,160"/>

the highlighter works correctly. The added ",23" part borks the highlighter and causes it to select colors from wrong entries.

I think that this is probably the cause of the issue that some users are experiencing (the new wxSmith generated code highlighting is the only other lexer related change, and it can be disabled).  My guess is that even though the new index is correct (for the most recent Scintilla update), Code::Blocks cannot correctly load previously saved user customized color schemes (likely because of the added index).

A possible solution would be for the affected users to manually search default.conf for the lexer related entries, modifying what seems appropriate,
or deleting/moving default.conf, and recreating the preferred color scheme.

[elettronica67]

Hi, I still have problems with syntax highlight.
I have noted that in Settings->Editor->Syntax highlighting from the choice "Number" (included) in ahead everything is shifted by one position.
Hope that this will help you, For now I solved the problem by installing the previous nightly version.

[stefanos_]

Wow...I have compiled the latest svn revision and I just noticed this new application named Addr2LineUI.exe. I have tried to use it but it depends on addr2line.exe. Should not be available as part of Code::Blocks since we are offering it's UI or should I install it separately?

Specs:

OS: Windows XP SP3
Compiler: TDM's GCC 4.5.2 (GCC 4.6.1)
wxWidgets: 2.8.10 / 2.9.4

[ollydbg]

Wow...I have compiled the latest svn revision and I just noticed this new application named Addr2LineUI.exe. I have tried to use it but it depends on addr2line.exe. Should not be available as part of Code::Blocks since we are offering it's UI or should I install it separately?

Specs:

OS: Windows XP SP3
Compiler: TDM's GCC 4.5.2 (GCC 4.6.1)
wxWidgets: 2.8.10 / 2.9.4

Addr2line.exe is mainly distributed in your MinGW, it is mostly located under MinGW/bin folder.

[stefanos_]

Yeah...of course...I knew it NOT! hahahah thanks a lot ollydbg for letting me know

[stefanos_]

The tooltip issue http://forums.codeblocks.org/index.php/topic,16560.msg112659.html#msg112659 remains the same on Debian wheezy too. Also tab button does not work on Properties when I use .wxs files.

UPDATE: I opened two projects, opened their wxSmith files to compare them and upon closing one of the two, it crashed but the generated report located in /tmp/ directory got immediately deleted. How silly is that?! How am I supposed to let you know if it does not keep the report file somewhere? Is this behavior normal?