[resolved] No targets in New Project wizard

[MasterAlexei]

Hello everyone,
what could be the problem of that in New Project Wizard there is no selectable project types.
I did build yesterday last SVN Repo, Rev 9402 and since that moment not able to make a new project



The Plugin Scripted Wizard is enabled and it's Version is 0.9

The CB is builded against wxWidgets 2.8.12

Would be great, if some one help me to find out the reason.
Tanks,
Alexei

[ollydbg]

Hi, thanks for the report, I just build the C::B rev Rev 9402 (Codeblocks.cbp), and I see the same issue even after I run the update.bat.

[Jenna]

Hi, thanks for the report, I just build the C::B rev Rev 9402 (Codeblocks.cbp), and I see the same issue even after I run the update.bat.

Works fine on linux with projectfiles (whole workspace) and autotools, with wx2.8 and wxtrunk.

I will test on win7 now.

[Jenna]

Hi, thanks for the report, I just build the C::B rev Rev 9402 (Codeblocks.cbp), and I see the same issue even after I run the update.bat.

Works fine on linux with projectfiles (whole workspace) and autotools, with wx2.8 and wxtrunk.

I will test on win7 now.

No issues on win7 (neither wx2.8 nor wxtrunk).
I removed the devel* and output* folder before the build.
If you did not do that, you might have stumbled over a pch-issue (again).

[MasterAlexei]

Hello together,

I did removed the devel* and output* folders, did RE-build CB and Contrib Plugins (in CB self, using the .workspace files). It took a little bit more time, as before, but the problem is still there, as on the picture above - there are no Proj. targets at all.
And, I have WinXP on my work place.

Thanks in advance for a quick solution ;-)

Alexey

[Jenna]

Can you start from commandline with -v parameter, to see if you get a meaningful message ?
Where do you have pch's (*.gch) ?
Only below output and devel or also in src/include ?
If the second is true, please remove them and try again.
Another  (more time-consuming) way would be to remove the .objs folder also or do a clean checkout and build C::B there.

[ollydbg]

I'm building C::B now, I have deleted the folder: cb_trunk\src\.objs, where the gch files locates.
Let me wait for the result.

[ollydbg]

I'm building C::B now, I have deleted the folder: cb_trunk\src\.objs, where the gch files locates.
Let me wait for the result.

Bad news: the result is that I still have this issue.
I'm using wxWidgets 2.8.12, WinXP, MinGW-build-dwarf2-4.8.1-compiler-suite.

[MasterAlexei]

Can you start from commandline with -v parameter, to see if you get a meaningful message ?

Does not happen any thing (CB is still starts, of course ). With /d or /v or with both of them there is no output to console. I did started also from the devel folder, where the debug info not yet stripped, but there also no output at all. (may be it is windows version behavior?)

[stahta01]

I'm building C::B now, I have deleted the folder: cb_trunk\src\.objs, where the gch files locates.
Let me wait for the result.

Bad news: the result is that I still have this issue.
I'm using wxWidgets 2.8.12, WinXP, MinGW-build-dwarf2-4.8.1-compiler-suite.

I had the issue using wx 2.8 branch, Win7 SP1 32-bit, TDM SJLJ 4.8.1 compiler.

Now trying 4.7.1 compiler.

Special steps taken:
Deleted objects folder before build
Deleted devel/share Folder before build
Deleted output Folder after build before update.bat

Tim S.

[Alpha]

Works with GCC 4.8.1 on Linux (Ubuntu 13.10).  Does anyone know what the last revision that worked for Windows was?  9398?  (9399 was the most recent touch to ScriptedWizard code, but that change should be completely unrelated to this problem...)

[ollydbg]

...(9399 was the most recent touch to ScriptedWizard code, but that change should be completely unrelated to this problem...)

I can confirm that rev 9398 has this issue.

[Jenna]

Did you try it with a real clean (fresh checkout) build tree ?

Did you try it with gcc 4.7 ?

Is it XP only or does this also happen on other windows revisions ?

[ollydbg]

Did you try it with a real clean (fresh checkout) build tree ?

Yes, I just finish a real clean checkout and build, but still have the issue.

Did you try it with gcc 4.7 ?

I will do it right now using PCX's GCC 4.6.3 and report back soon.

[ollydbg]

Did you try it with gcc 4.7 ?

I will do it right now using PCX's GCC 4.6.3 and report back soon.

I can confirm that when using PCX's MinGW GCC4.6.3 (which was the compiler I use for last two years), building rev 9402 still has this issue on WinXP.

Sorry, I only have WinXP system.

[stahta01]

I'm building C::B now, I have deleted the folder: cb_trunk\src\.objs, where the gch files locates.
Let me wait for the result.

Bad news: the result is that I still have this issue.
I'm using wxWidgets 2.8.12, WinXP, MinGW-build-dwarf2-4.8.1-compiler-suite.

I had the issue using wx 2.8 branch, Win7 SP1 32-bit, TDM SJLJ 4.8.1 compiler.

Now trying 4.7.1 compiler.

Special steps taken:
Deleted objects folder before build
Deleted devel/share Folder before build
Deleted output Folder after build before update.bat

Tim S.

Repeated steps except using 4.7.1 compiler; and, I did NOT see the problem.

Edit: Changed back to using 4.8.1 Compiler (but added the compiler option -Wno-unused-local-typedefs to reduce warnings)
The problem did NOT show back up.

Edit2: I realized I built the bad version using CB svn 9156; trying again using that CB version to see if problem happens again.
Edit3: Found no problem using CB svn 9156 to build; no idea why the first time had a problem.

Tim S.

[ollydbg]

I debugged this bug for a while, and I found a strange problem:
In the function:

Code

NewFromTemplateDlg::NewFromTemplateDlg(TemplateOutputType initial, const wxArrayString& user_templates)
    : m_Template(0L),
    m_pWizard(0L),
    m_WizardIndex(-1)
{
    //ctor
    wxXmlResource::Get()->LoadObject(this, 0L, _T("dlgNewFromTemplate"),_T("wxScrollingDialog"));
    m_Wizards = Manager::Get()->GetPluginManager()->GetOffersFor(ptWizard);

    wxListbook* lb = XRCCTRL(*this, "nbMain", wxListbook);
    SetSettingsIconsStyle(lb->GetListView(), sisNoIcons);
/*
    // create image lists
    XRCCTRL(*this, "listProjects", wxListCtrl)->SetImageList(new wxImageList(32, 32), wxIMAGE_LIST_NORMAL);
    XRCCTRL(*this, "listProjects", wxListCtrl)->SetImageList(new wxImageList(32, 32), wxIMAGE_LIST_SMALL);
    XRCCTRL(*this, "listTargets", wxListCtrl)->SetImageList(new wxImageList(32, 32), wxIMAGE_LIST_NORMAL);
    XRCCTRL(*this, "listTargets", wxListCtrl)->SetImageList(new wxImageList(32, 32), wxIMAGE_LIST_SMALL);
    XRCCTRL(*this, "listFiles", wxListCtrl)->SetImageList(new wxImageList(32, 32), wxIMAGE_LIST_NORMAL);
    XRCCTRL(*this, "listFiles", wxListCtrl)->SetImageList(new wxImageList(32, 32), wxIMAGE_LIST_SMALL);
    XRCCTRL(*this, "listCustoms", wxListCtrl)->SetImageList(new wxImageList(32, 32), wxIMAGE_LIST_NORMAL);
    XRCCTRL(*this, "listCustoms", wxListCtrl)->SetImageList(new wxImageList(32, 32), wxIMAGE_LIST_SMALL);

    // load view prefs
    XRCCTRL(*this, "rbView", wxRadioBox)->SetSelection(Manager::Get()->GetConfigManager(_T("new_from_template"))->ReadInt(_T("/view"), 0));
    ChangeView();

    BuildCategories();
    BuildList();

    // fill user templates list
    XRCCTRL(*this, "lstUser", wxListBox)->Clear();
    for (unsigned int i = 0; i < user_templates.GetCount(); ++i)
    {
        XRCCTRL(*this, "lstUser", wxListBox)->Append(user_templates[i]);
    }

    lb->SetSelection((int)initial);*/
}

You see, I have comment out all the operations on the dialog, but the wxListBook control still not shown correctly.

When I open the xrc in the wxsmith editor, I can see the default dialog should be like this (see the image shot below)


EDIT:
It looks like the option: Resize border should be enabled compared with other xrc, but when I enabled this, I still have this issue.

EDIT2
I can easily add a new button, but the wxListBook still not shown, I'm no idea how to fix it. (see the screen shot below)

[Jenna]

I will try to get a deeper look into it, but I need to install C::B, C::B sources, wxWidgets and MinGW to test.
This will probably need some time.

[ollydbg]

I think it is better we can have a Codeblocks_debugwx.cbp file which link to the debug version of wx library, so that catch bugs in wx is quite easy.

[Jenna]

It looks like wxLC_LIST is broken on WinXP, so my changes in svn r9390 to SetSettingsIconStyle break the NewFromTemplateDllg on Windows XP (not win7 !).
Using wxLC_SMALL_ICON instead of wxLC_LIST work non XP. If it does work on win7 (wx2.8 and wx2.9+) I commit this fix, otherwise, I will find another solution.

[Jenna]

Could you please check, whether the issue is fixed in svn r9405 ?

[ollydbg]

Could you please check, whether the issue is fixed in svn r9405 ?

Thanks. It works fine now! Great work.

[cacb]

I have just installed Kubuntu 13.10 and compiled C::B using Jens' tarball codeblocks_12.11svn9393.orig.tar.gz against wx 2.8.12 as provided by Kubuntu 13.10. The C::B start screen shows

Code

svn build rev 9393 (2013-10-08 09:17:30) gcc 4.8.1 Linux/unicode - 32 bit 

If I try the project wizard, there are no targets as mentioned in this thread.

Another issue that I noticed, was that the compilation was unusually slow. I didn't time it or watch it, but it seemed to take forever.

For my own projects, I also use wx 2.8.12, but compile and link it statically. As I compiled wx, I noticed there was a huge number of warnings being issued about "unused local typedefs" in wx/defs.h and perhaps other places. Writing all these warnings took a loooong time. This appears to be a side effect of gcc 4.8.1, but so far I have not found any way to switch those warnings off. Suggestions welcome.

[ollydbg]

For my own projects, I also use wx 2.8.12, but compile and link it statically. As I compiled wx, I noticed there was a huge number of warnings being issued about "unused local typedefs" in wx/defs.h and perhaps other places. Writing all these warnings took a loooong time. This appears to be a side effect of gcc 4.8.1, but so far I have not found any way to switch those warnings off. Suggestions welcome.

add the compiler option -Wno-unused-local-typedefs to reduce warnings. Or manually remove this dummy typedef in the wx source.

[Jenna]

Before running the configure-script just do a

Code

export CXXFLAGS="-Wno-unused-local-typedefs"

in the console.
The other issue is fixed later and there are more fixes to the settings-dialogs I am working on.
I will commit them most likely this afternoon/evening/night, but it's always much to test (WinXP, Win7, Liinux and wx2.8 and wxtrunk).

[cacb]

Before running the configure-script just do a

Code

export CXXFLAGS="-Wno-unused-local-typedefs"

in the console.
The other issue is fixed later and there are more fixes to the settings-dialogs I am working on.
I will commit them most likely this afternoon/evening/night, but it's always much to test (WinXP, Win7, Liinux and wx2.8 and wxtrunk).

Thanks a lot, but I believe that option (-Wno-unused-local-typedefs) is removed in gcc 4.8.1. I tried, and it doesn't work. I believe the opposite (-Wunused-local-typedef) is now implicit in -Wall, without any way of turning it off. A last resort solution is to start fiddling with wx 2.8.12 source, but it isn't ideal.

I shall watch your C::B folder and try again when I see the update. Your work is much appreciated!

[Jenna]

I use it here and it works with gcc4.8 on Fedora.

[cacb]

I use it here and it works with gcc4.8 on Fedora.

Ok, i will double check. Thanks again.

[cacb]

I use it here and it works with gcc4.8 on Fedora.

Ok, i will double check. Thanks again.

I have double checked now, and you are correct again  Somehow, I messed up the first time.

To suppress all wx 2.8 warnings (rightly or wrongly), I found I had to use these two options:

Code

-Wno-unused-local-typedefs
-Wno-literal-suffix

As I have many code::blocks projects with several targets in each, it isn't straghtforward to update them all. As a temporary solution I have therefore enabled the two options above as global C::B compiler settings for gcc. A better solution would be to use some tool to add them to my project files, I guess.

[Jenna]

If you just build C::B, you can add them to the  cb_release_type global-variable. That covers most (not all) C::B projects.

[cacb]

If you just build C::B, you can add them to the  cb_release_type global-variable. That covers most (not all) C::B projects.

I am not using C::B projects to build C::B, I simply use the dpkg-buildpackage procedure explained here
http://forums.codeblocks.org/index.php/topic,16740.msg122695.html#msg122695
using the export option mentioned above solves the issue with building C::B as far as I am concerned.

Basically, I was referring to using wxWidgets under Code::Blocks with gcc 4.8.1, where the same problem returns. The idea of using a global variable to control compiler options is nevertheless a good idea that could perhaps be re-used here. I already have a "wx" global variable, so presumably I could just add the new compiler options in the cfield area for the "wx" variable. I will try.

[MasterAlexei]

Hello everyone,

I did try the last rev 9413 right now, and the issue is fixed!
Great job!
Thanks a lot!

Now only one old issue is still there - large files in large projects hangs CB or it crushes some times. I think - the parser and Thread Search are making some multitasking troubles here. But it is a story for other thread (there is one somewhere there) .

Regards,

Alexey