Version: 3.4.1 (using KDE 4.0.1KDE 3.5.5) Installed from: Gentoo PackagesGentoo Packages OS: Linux When you create new project from the C++->wxWidgets, standard wxWidgets macros are not predefined, which gives a parsing errors on the source code in the editor. The macro list (not complete) is as follows: #define DECLARE_EVENT_TABLE() #define BEGIN_EVENT_TABLE(theClass,baseClass) #define END_EVENT_TABLE() #define IMPLEMENT_APP(theClass) #define IMPLEMENT_APP_NO_MAIN(theClass) #define DECLARE_APP(theClass) #define DECLARE_DYNAMIC_CLASS(theClass) #define IMPLEMENT_DYNAMIC_CLASS(theClass,baseClass) #define EVT_MENU(id,func) #define EVT_INIT_DIALOG(func) #define EVT_BUTTON(id,func) #define EVT_TEXT(id,func) #define EVT_LISTBOX(id,func) #define EVT_CHECKBOX(id,func) #define EVT_RADIOBOX(id,func) #define EVT_MENU(id,func) #define EVT_CONTEXT_MENU(func) #define EVT_SIZE(func) #define WX_DEFINE_OBJARRAY(classid,arrayid) Please update so that those macros will be predefined when creating the project.
This won't be fixed. That list of macros is only a workaround for an incomplete language support and that will be much improved in kdevelop4. (or rather, is already)
Andreas, Are you saying that when I upgrade to KDevelop 4, all those macros will be resolved and won't produce parsing errors? Thank you.
Thats the plan, however I suggest you don't upgrade right away, Kdevelop4 is not yet usable for public audience.
This is great news. However, do you know the timeframe for this release? Will it be this year? Thank you.
Sorry, hit "Commit" too early... ;-) Also, do you need the complete list of macros for wxWidgets? And why it still calls "wxWidgets"? Shouldn't it be called "wxWidgets/wxGTK"? Thank you.
There's no definite timeframe, but so far it looks as we won't make KDE 4.1. Which means we're either going for a release between 4.1 and 4.2 or will go with KDE 4.2. re complete list: I'm not sure what you mean here. If its about kdevelop3, you only need the list of macros that you use and are not defined in the same file as you use them. re naming: Why should it be called wxWidget/wxGtk? Is there a different implementation with a different toolkit? Apart from that the app templates are mostly unmaintained (except for a few qt/kde ones), so don't expect such minor fixes there ;)
Andreas, I, for one, work with wxWidgets, so I can only speak for the wxWidgets. ;-) The library itself called wxWidgets (I mean if you go to the www.wxwidgets.org), however, being cross-platform it has different ports: wxMSW, wxGTK, wxMac, wxOS/2, wxX11, etc. On *nix there are 2 main ports: wxX11 and wxGTK. The most useful and currently most maintainable port is wxGTK. So whenever people are talk about wxWidgets on *nix 99.99999% they talk about wxGTK. That's in regaqrds to the naming. It's just for my taste it's confusing and wxWidgets/wxGTK will be more clear. Besides even when the people will work with wxX11, libraries will be installed in the same place as with wxGTK, so no harm here. When I initially filed a bug, I put a list of macros that is missing and has to be set up when the person creates a wxWidgets project. However, this list is not complete. Again if you go to the wxWidgets.org site, click on Documentation link, and select the latest documentation link, browsing the docs of the project will reveal much more macros than I put when the bug was opened. I put only the macros I was/am using, but other people, especially wx devs/users use more than from this list. So here my question still stands: do you want a complete list of macros, or you can go and retrieve the list yourself? Hope this clarifies everything. Thank you.
re wxGTK: If you want to write up a patch for renaming it'll probably be applied, however I doubt any of use devs want to work on that for kdev3. re macros: I think you misunderstood, in KDevelop4 we have a much better C++ parser framework which actually reads the wxGTK headers and understands the macros. So there's no need to put the list anywhere, any macro reachable from a #include-file will be available and known to the parser and problem reporter in KDevelop4.
Andreas, No, I have enough on my plate to do. About macros: the keyword here is "from #include-file". What if it will be a source code (cpp-file) macro. Also how do you guys break correctly spelled and incorrectly-spelled macros? Thank you.
you can't use a macro from a file that you don't inlcude, the C preprocessor will choke on that (except defines done on the gcc commandline). So either the file with the macro definition is #included or its visible via the buildsystem (for which there needs to be support then of course). Not sure what you mean with "break correctly spelled macros", but if you make a mistake in typing a macro's name then that'll be an error reported via the problem reporter.
Andreas, what I'm talking about is this: Correct macro: DECLARE_EVENT_TABLE() Incorrect macro: DECLARE_EVENT_TABLES() Whenever you will do parsing, how do you decide, which one is a parsing error in the editor? This is not the build system I'm talking about which refers on your first comments, but the problem with the editor parsing. Thank you.
The parser will know that the second macro name doesn't exist and hence tell you that this is wrong. The editor has nothing to do with it, except that it carries the markers for errors on its side. The first macro will also be highlighted as error, if the C++ parser can't find the header files that your source file #include's. Usually that won't happen as most people use some kind of buildsystem which the parser asks for the include directories that are active during the build for this source file. Then it can find all header files you include, parse them and hence know the proper macro.