Hi Killerbot,
Thanks.
I should know later today. That should answer the 8.02 question, too. The CHM is currently only run under windows and, as of the version I'm about to post, can be controlled by preferences. There are options for running CHMs under Linux. wxCHM, for example, or you may be able to do it under WINE. The plug-in itself should work without issues. Other than the one conditional call to run the CHM it's all platform-independent. The only problem might be if there have been some incompatible changes in the SVN code. I'll let you know.
Cheers,
Cryo.
in linux version would be nice to try to incorporate the wxchm (i don't knwo it, but it sounds interesting) :-)
in linux version would be nice to try to incorporate the wxchm (i don't knwo it, but it sounds interesting) :-)
A *.chm file is compiled HTML; does linux have a way of reading those?
Ringo
Hi Codeur,
. . .
If you could provide the details and try upgrading your version and report your results that would be appreciated.
. . .
I've now uploaded a new version that adds quite a lot of new functionality:I gave it a try and it looks quite good. :P
22 February 2010
released version 0.2.172 of DoxyBlocks
sText += _T("DOT_PATH =\n");
codeblocks: relocation error: /usr/lib/libcodeblocks.so.0: symbol _Z18wxSafeConvertWX2MBPKw, version WXU_2.8.2 not defined in file libwx_baseu-2.8.so.0 with link time reference
Quotecodeblocks: relocation error: /usr/lib/libcodeblocks.so.0: symbol _Z18wxSafeConvertWX2MBPKw, version WXU_2.8.2 not defined in file libwx_baseu-2.8.so.0 with link time reference
Thanks for trying to guess why I am having this issue. I do not myself have time to investigate this, so I am not asking for help on this.
Just to answer your question, The error I get when installing the .cbplugin is:
...
One or more plugin were not loaded.
This usually happen when a plugin is built for a different version
of the Code::Block SDK. Check the application log for more info.
...
Obviously this does not tell us much new. (Except that it is an answer to your question: A plugin built from a recent svn is very unklikely to run in CB 8.02.)
It also tells me that upgrading my version would indeed probably fix the issue. I'll do that sometime, but don't hold your breath as this is an installation common to about 200 people. I do not change it just to install a new plugin, even one as useful as Doxygen.
I gave it a try and it looks quite good.
Hence I have some suggestions to make:
1.) It was hard to me to find out how I actually use this. Until I found the toolbar which gives access to the functions. An extra "doxygen" menu would be fine.
2.) In addition some of the options should go into the editors context menu, too (like "add doxygen comment at current editor position) for convenience.
3.) The "DOT_PATH" is written twice if you setup the DOT executable. You just need to remove the additional line:
Code:
4.) Having the possibility to view the HTML file in the internal HTML viewer of C::B would be really convenient, too. You can have a look how it's done in the build log.
5.) The project file needs some clean up as there are absolute path's included that make installation fail. You should consider to put all path's relative to the "contrib" plugin folder. That's what most people expect I'd say.
6.) The setup dialog is quite huge and although I personally don't really care I think users with small screen resolutions will complain sooner or later.
Besides this I just started using it and having fun.
Hello Cryo/Gary,
I am not surprised that you got frustrated. There is a lot to know about CB, wxWidgets and the various releases of the different platforms that is hard to come by as it is lost in a huge amount of discussion on the forums. Documentation is definitely not crash hot. We need Doxygen!
Only long-time developers can navigate through this maze with some ease, and they may not fully understand the frustrations of a newcomer.
However do not bang your head against the wall for 16 hours again. Ask for help here. Your project is really useful and as you can see from the replies from jens and MMF, those long-timers are very willing to help a worthwhile cause.
I, for one am very grateful to you for trying so hard. I'll try building your new version on my Windows system.
Many thanks for this and for publishing the docs.
This is a problem with the wxWidgets in Ubuntu 9.10, that is not binary compatible with the version of wxWidgets.org .
There are several posts about this, to fix the problem.
Nevertheless, I will see what I can do to build and run your plugin on linux .
Thanks, that would be wonderful. If you can suggest how I should proceed on Ubuntu Karmic that would also be great.Compiling on linux was no problem, I attach the project-file that works for me.
Fair comment. Funny what we assume, isn't it? Do you think that it would be best as a sub-menu in the Plugins menu or is it worthy of a new menu to itself?Do an own one. (That's just my opinion.)
I hadn't thought of that as I don't use it but it sounds useful. What do you mean by "in the build log"?If you write a HTML log file then in the build log a message (link) to the HTML log file appears which you can click. This opens the internal HMTL viewer of C::B. I meant have a look at the code how it's done.
I think that'll have to happen if I include any more default options, anyway.Mmmh... I was under the impression that the stand-alone config dialog was that big... probably it was the container - I'll have another look
Keep 'em coming. I want this to be useful to the community at large so I'm open to change.Hehe... I'll give you one more: When choosing to add a doxygen comment at the current cursor position you could parse the following code for a function signature and pre-process the lines added accordingly. Meaning: If I choose to add the comment before a line like:
int MyFunc(double par1, int par2);
/**
* \brief MyFunc
* \param par1
* \param par2
* \return
*/
void MyFunc();
/**
* \brief MyFunc
*/
If you write a HTML log file then in the build log a message (link) to the HTML log file appears which you can click. This opens the internal HMTL viewer of C::B. I meant have a look at the code how it's done.
Mmmh... I was under the impression that the stand-alone config dialog was that big... probably it was the container - I'll have another look
Hehe... I'll give you one more: When choosing to add a doxygen comment at the current cursor position you could parse the following code for a function signature and pre-process the lines added accordingly.
Thanks, that would be wonderful. If you can suggest how I should proceed on Ubuntu Karmic that would also be great.Compiling on linux was no problem, I attach the project-file that works for me.
I did not (yet) test the functionality.
To use C::B on Karmic, you have to either remove all wxwidgets 2.8.10 packages shipped with ubuntu and use the ones from apt.wxwidgets.org (in this case you can use my repo), or remove all packages from apt.wxwidgets.org and use the packages shipped with Karmic.
In the second case you have to build C::B yourself with automake system or use the repo provided by pasgui (he provides a special version for Karmic) : http://forums.codeblocks.org/index.php/topic,11875.msg80825.html#msg80825 (http://forums.codeblocks.org/index.php/topic,11875.msg80825.html#msg80825) .
QuoteTo use C::B on Karmic, you have to either remove all wxwidgets 2.8.10 packages shipped with ubuntu and use the ones from apt.wxwidgets.org (in this case you can use my repo), or remove all packages from apt.wxwidgets.org and use the packages shipped with Karmic.
Yes, I did that. Something may have been out of place so I'll give it another go and report progress.
gary@ubuntu:~/Projects/CodeBlocks/src/output$ ./run.sh
Initialize EditColourSet .....
Initialize EditColourSet: done.
Loading toolbar...
DoxyBlocks: loaded
AutoVersioning: loaded
BYOGames: loaded
cbDragScroll: loaded
DoxyBlocks plugin activated
AutoVersioning plugin activated
BYO Games plugin activated
DragScroll plugin activated
Initializing plugins...
Hence I have some suggestions to make:
1.) It was hard to me to find out how I actually use this. Until I found the toolbar which gives access to the functions. An extra "doxygen" menu would be fine.
2.) In addition some of the options should go into the editors context menu, too (like "add doxygen comment at current editor position) for convenience.
3.) The "DOT_PATH" is written twice if you setup the DOT executable. You just need to remove the additional line:
4.) Having the possibility to view the HTML file in the internal HTML viewer of C::B would be really convenient, too. You can have a look how it's done in the build log.
6.) The setup dialog is quite huge and although I personally don't really care I think users with small screen resolutions will complain sooner or later.
Hehe... I'll give you one more: When choosing to add a doxygen comment at the current cursor position you could parse the following code for a function signature and pre-process the lines added accordingly.
-Added: Inserted comments blocks are now indented to match the code that they're commenting.Can't wait testing... :-)
ret = wxExecute (cmd + wxT(" ") + fnDoxyfile.GetFullPath(), sOutput, sErrors);
if(ret == 0)
{}
Execution of 'C:\Program Files\doxygen\bin\doxygen.exe' failed.
Running doxywizard...
Process 3308 (C:\Program Files\doxygen\bin\doxywizard.exe C:\Program Files\CodeBlocks\workspace\Codeblocks-Nightly\src\plugins\contrib\doxyblocks\doxygen\doxyfile) launched.
DoxyBlocks builds in the trunk development environment, except that it attempts to link with -lwx_mswu-2.8.dll which is not in my system. I have to link with -lwxmsw28u (wxmsw28u.dll which I have) instead. Once I link it this way, it runs OK in the trunk version of CB (still cannot get it to load in our svn 6113 production system unfortunately, but I am getting closer).
I am totally unfamiliar with CB development so I have this newbie question for you Gary: is "libwx_mswu-2.8.dll.a" or "wx_mswu-2.8.dll" a file we are supposed to obtain from building the wxwidgets or during their installation?
BTW: I am impressed by the amount of work you have produced for this doxygen plugin in this short time... and you are a perfectionist, fixing details before they are mentioned to you. I am feeling quite awed really, thanks.
-Added: Inserted comments blocks are now indented to match the code that they're commenting.Can't wait testing... :-)
Looks REALLY good so far... Good work! :P
Bug: if tabs w. sourcecode isn't open and you trying push "Extract documentation..." button, CB will crash.
Bug: ExtractDocs.cpp:551Coderet = wxExecute (cmd + wxT(" ") + fnDoxyfile.GetFullPath(), sOutput, sErrors);
if(ret == 0)
{}QuoteExecution of 'C:\Program Files\doxygen\bin\doxygen.exe' failed.
It seems like "if(ret == 0)" isn't fully correct. Maybe better use "if(ret != -1)"
Probably Bug: doxywizard isn't run.QuoteRunning doxywizard...
Process 3308 (C:\Program Files\doxygen\bin\doxywizard.exe C:\Program Files\CodeBlocks\workspace\Codeblocks-Nightly\src\plugins\contrib\doxyblocks\doxygen\doxyfile) launched.
I'm using self builded CB and self builded Doxyblocks. Both from SVN trunk.
Thank you & keep working on it.
Hey Joker,
Thanks for taking the time to report your findings, I really appreciate it.
From the docs: "In the case of synchronous execution, the return value is the exit code of the process (which terminates by the moment the function returns) and will be -1 if the process couldn't be started and typically 0 if the process terminated successfully."
I take your point. != -1 does seem to be more correct. I've changed it, thanks. Are you seeing a problem? You don't say.
So you're seeing this message and then doxywizard doesn't appear? I'd say if a process number is returned then it ran. What happens after the process is spawned is not C::B's doing. I see, however, that you are using the notorious "Program Files" directory and I would guess that the space in the path is choking doxywizard. I would recommend never using Program Files for anything of your own and leaving it for Windows' use. Since doxygen is originally a Unix application I would think that it doesn't like spaces.
[Update:] I ran a check and, sure enough, doxywizard fails if I use a path to a doxyfile that contains spaces. DoxyBlocks should quote the path to avoid the problem. I'll fix that and upload it to SVN later today. Thanks.
if(sText.Length() > 0)
if(!sText.IsEmpty())
I'm hoping to get it into the contrib collection so please let me know if there is anything I need to do before that can happen e.g. setup, standards, build settings, etc.There is:
However, these are only minor things. Basically the lacking automake is currently the major show-stopper.
However, these are only minor things. Basically the lacking automake is currently the major show-stopper.
I hope I find the time to create it this evening and post the patch here (Just for the automake, nothing else, due to lack of time).
...
Now is working.
...
Yep. Now is working too.
I know it sounds a bit pedantic but:
ExtractDocs.cpp:565Codeif(sText.Length() > 0)
I thinkCodeis better :)if(!sText.IsEmpty())
I have the same problem as "codeur" in "Reply #12".
Unfortunately I can't install that plugin.
I use this CB version: Release 8.02 (2008-02-27 19:55:16) gcc 4.2.1 Windows/unicode on a Windows XP SP2
Now I'm not sure if this problem was solved, and if yes how ?
I'm hoping to get it into the contrib collection so please let me know if there is anything I need to do before that can happen e.g. setup, standards, build settings, etc.There is:
- The project files need some clean-up (I did this already and can provide you with a patch).
- The update files need some cleanup (do not create a "*.cbplugin" file as contrib plugin)
- It needs to be compilable under Linux using automake, so the "makefile.am's" are missing
- Do not include sdk_precomp.h directly, this is only correct for the core of C::B. Instead, include sdk.h
- I didn't verify the include statements of the plugin so far and whether they are correct in terms of PCH. However, here are the rules that need to apply:
http://wiki.codeblocks.org/index.php?title=Precompiled_headers
Bug: if tabs w. sourcecode isn't open and you trying push "Extract documentation..." button, CB will crash.
Whoa doctor! That's not good. I've looked into this. In fact, the only button that does not crash C::B when there are no tabs open is the config. dialogue button. My code is never executed i.e. C::B crashes before it gets to my code. I can't trap it. I think that the config button may work because it uses a default plug-in function. Execution doesn't reach the first line of the function called by connect() to respond to the event. Morten, can you shed any light on this?
In the meantime the workaround is to ensure that you have at least one editor window open when running DoxyBlocks functions.
Drop the .mo files into $SHARE/codeblocks/locale/lang_CODE and Code::Blocks will use them.
Today's excitement :D :
Released version 1.0.14 of DoxyBlocks
-...
Yes, that is correct. And yes: This directory does not exist in the nightlies.QuoteDrop the .mo files into $SHARE/codeblocks/locale/lang_CODE and Code::Blocks will use them.still correct?
Yes, that is correct. And yes: This directory does not exist in the nightlies.QuoteDrop the .mo files into $SHARE/codeblocks/locale/lang_CODE and Code::Blocks will use them.still correct?
Hi Guys,
... automating the documentation of a file and found that it was not practical as things stand. ...
...
-Added: The toolbar and menu are now disabled when all projects are closed and re-enabled when a project is opened.
I notice furious activity still going on SourceForge since, with version 15 in SVN.
Many thank.
Hi Guys,
... automating the documentation of a file and found that it was not practical as things stand. ...
Agreed. I use CB in an educational setting and would look pretty dimly at per-file documentation automation. It would mess up already written function banner comments and would encourage the poor practice of "commenting when all is done". I am glad you don't consider it anymore.
I think I have forgotten how to install a plugin. I cant install this plugin
...
-Added: The toolbar and menu are now disabled when all projects are closed and re-enabled when a project is opened.
There is something wrong with this (in my own Windows built that completes with 0 error 0 warning, I have not tried your .cbplugin). The menu and toolbar are disabled (greyed) when I close projects, but they are enabled when CB starts next on the "start here" screen (and no project loaded). CB then dies some time afterwards. I have to uninstall doxyblocks to retrieve normal behaviour. The previous version was not doing this even though it would somehow kill CB if you tried to configure doxyblocks with no project open.
Ok, I use NB 6181 for error please look at attachment thanx in advance
Ok, I use NB 6181 for error please look at attachment thanx in advance
Same here. I even built svn 6190 in order to see if it improved things. It does not.
However I have always had this very same error (same one as LordCB) with Gary's .cbplugins. I have to rebuild doxyblocks myself to get it to work.
The current svn update claims to be 1.1.79 (1.1.111 not committed?). It builds and loads OK when I build it myself with SVN 6190 (after some minor modifications to the project).
What I get though with version 1.1.79 still has the same problem that the menu and toolbar are active when CB is just started (and CB dies if you open the DoxyBlocks preferences without a project open and then click OK), so I'll wait until 1.1.111 or later is committed to svn to see if Gary's fix worked.
It's committed now. That should fix the toolbar issue.
BTW, did you check the application log as mentioned in the error? Please post the contents.
Cheers.
It does fix the toolbar issue, but not the menu which is still active when CB starts.
I'll keep my eyes open and tell you if I find a clue why I cannot load your plugin if I don't re-build it.
codeur: start C::B with "codeblocks.exe --debug-log" this option adds another log pane
I think Jens is the Linux man so we'll just have to wait for him to have the time, I guess. :evil:
My advice: take the rest of the week and the week-end off. Spring is coming (if you are in the Northern hemisphere), take your girl out for a great bushwalk and come back refreshed. The blasted code can wait.
codeur: start C::B with "codeblocks.exe --debug-log" this option adds another log pane
Thanks for the tip oBFusCATed. The message I get in the debug log when DoxyBlocks fails loading is... failed :shock: :? :lol:
I am confident this info will solve all of Gary's issues.
Another one for you Gary. I built 1.1.123, removed the old plugin, installed the new one. No luck.
Steps to see the issue:
1- Install doxyblocks from .cbplugin (with an open project). DoxyBlocks menu and toolbar come up enabled.
2- Close all projects. DoxyBlocks menu and toolbar are disabled (greyed out).
3- Close CB, Open CB. The toolbar is disabled, the menu is enabled.
My advice: take the rest of the week and the week-end off. Spring is coming (if you are in the Northern hemisphere), take your girl out for a great bushwalk and come back refreshed. The blasted code can wait.
Hurrah! :oMenu activation is working now (including the internal activation/deactivation of the comment functions), thanks.
I'm at work until friday (most likely late) evening, until 9 or 10 pm each day (I have internet just since half an hour here after fighting the whole week with german telecom and some ignorant builder who cut our phone cable multiple times).
I hope I will find the time to look into it at the weekend.
But it worked for me without problems (automake and build by C::B).
If you build with automake-system, devel directory is not used.
A great milestone!
BTW: With my builds the version of doxyblocks shown by the plugins manager has been 0.3.286 for as long as I remember. Why would that be?
That's what I thought, but the current manifest.xml says: <Value version="1.2.209" />
version.h is also correct with version "1.2.209.5894"
... strange.
I think Jens is the Linux man so we'll just have to wait for him to have the time, I guess. :evil:My advice: take the rest of the week and the week-end off. Spring is coming (if you are in the Northern hemisphere), take your girl out for a great bushwalk and come back refreshed. The blasted code can wait.
I'm at work until friday (most likely late) evening, until 9 or 10 pm each day (I have internet just since half an hour here after fighting the whole week with german telecom and some ignorant builder who cut our phone cable multiple times).
I hope I will find the time to look into it at the weekend.
But it worked for me without problems (automake and build by C::B).
If you build with automake-system, devel directory is not used.
... I thought you were going out with your girl this week-end..?
Since you are doing some cleanups, the history on the mainpage of DoxyBlocks docs at the bottom of the doxyblocks.h header needs updating.
Back at home, I created two patches, one against C::B's trunk and one against DoxyBlocks trunk.
By the way, you should remove the .depend and .layout files from svn and make sure, that the linux/unix specific files do not get dos line-endings (especially the update-script) and the update-script has to be executable.
Ah, and I fixed a bug, that can lead to a crash if no editor is opened in "DoxyBlocks.cpp"
Hi Jens,Back at home, I created two patches, one against C::B's trunk and one against DoxyBlocks trunk.
Thanks. I have done much of that on Linux but, since it fails, haven't incorporated it into SVN. I'll tinker with these later today.
As an example being able to enter something like $(CODEBLOCKS)\tool\Graphviz\bin\dot.exe@Cryogen: True, you can achieve that easily using a call to macros manager before applying the path's. It's a one-liner per path.
My system still had some issues but I finally got it running. It looks like you created your own directory and used lower case. For consistency with the package and my setup, I have changed the couple of instances where your patch used "doxyblocks" to "DoxyBlocks". If you could do the same that would be appreciated. There are:
This request is to make doxyblocks usable in portable versions of Code::Blocks.
In order to make DoxyBlocks portable, could the paths to the documentation executables in the general preferences screen be made to use Codeblocks variables? The paths to the tools could then be made relative to the CB installation.
As an example being able to enter something like $(CODEBLOCKS)\tool\Graphviz\bin\dot.exe
rather than E:\Program Files\codeblocks\tool\Graphviz\bin\dot.exe as the path would make doxyblocks usable in a portable CB installation.
Thanks.
As an example being able to enter something like $(CODEBLOCKS)\tool\Graphviz\bin\dot.exe@Cryogen: True, you can achieve that easily using a call to macros manager before applying the path's. It's a one-liner per path.
BTW: Really, really: Nice work! I've just upgraded from 0.4 to the SVN... well done!
I also had the DoxyBlocks-plugin in a CamelCase-named suubdirectory and only changed it to lower-case, because your svn-directory is in lower-case too.
The contrib-plugins not all use CamelCase (even if I prefer it as you can see at my "own" plugin IncrementalSearch).
In short: it's no problem to me (debian files have to be fixed accordingly, if debian build-scripts are used, of course).
Before anything else, thank you very much for making Doxygen so much easier to use! :D
I have a small feature request: is it possible to add the doxygen flags EXTRACT_PRIVATE and EXTRACT_STATIC explicitly to the "Doxygen Defaults" tab? Although I never check EXTRACT_ALL, the setting is overriden by them, and I would like to have control over the documentation of private class members.
Of course, I can easily edit the generated doxygen settings file to this end, but it would make a big difference for me if I could have it generated the way I need it from the get-go.
Hi Morten,
. . .
OK, cool. I will look at this because I like to build in as much flexibility as possible and, in general, it seems like a good idea.
I guess that having to add to system paths could be a bit of a nuisance and having another option is definitely a "good thing". :)
. . .
Setting | Purpose | Value |
FULL_PATH_NAMES | Prepend the full path before files name in the file list | NO |
GENERATE_TREEVIEW | Generate index tree view in side panel | YES |
CALL_GRAPH | Have dot generate a call dependency graph | YES |
...
Released version 1.3.236 of DoxyBlocks
I have added the features requested by ptDev and Codeur. Let me know how they go for you, guys. They worked well here.
I can´t still install ya plugin
and in sourceforge i see only version 1.2.209
could anybody illuminate me
Hi Guys,
Released version 1.3.236 of DoxyBlocks
-Added: Configuration of EXTRACT_PRIVATE and EXTRACT_STATIC. Requested by ptDev.
(...)
I have added the features requested by ptDev and Codeur. Let me know how they go for you, guys. They worked well here.
I can´t still install ya plugin
and in sourceforge i see only version 1.2.209
could anybody illuminate me
After a quick check, the executable paths using CB variables in "preferences" work well for me too. Many thanks.
I can place a portable CB based on BN 6190 onto a USB HDD and get DoxyBlocks to work immediately on any XP SP3 computer around (I cannot test on other systems).
Working fine here, too. Right now, your plugin is PERFECT for me. Thank you very much! :D
Gary is currently trying to get a CB install that will allow him to produce .cbplugin (s) that work for all of us. He is making good progress, but until he succeeds we build DoxyBlocks from subversion with modified projects on our own systems in order to test working plugins on our systems (the possibility of having the doxygen plugin on the next release is what motivates us to test it in these conditions despite the inconvenience). The SVN on SourceForge is at version 1.3.236.
Actually, I'm not. I'm of the opinion it's not worth the effort and, as Jens pointed out, too dependent on library versions and other factors. In other words, nice idea but it's broke. However, if you were to build it yourself in your C::B installation, the .cbplugin it generates might work for you. If not, you're back to building it with C::B.
I feel that there could be some confusion here between the concept of publishing an ideal .cbplugin that could work on any past and future builds of Code::Blocks (that obviously cannot work), and the concept of publishing source code and a project file producing a .cbplugin that would work on an official release and could be maintained for nightlies. One such official release is in preparation at this time. I may be mistaken, but I think LordCB is currently testing for that purpose.
However I am out of my depth here and will let the maintainers speak to us on that.
Creating a .cbplugin from the release code might work but that would be redundant, wouldn't it, as it would be in the contrib plug-ins (I hope)? :wink:Notice that a *.cbplugin for Linux would surely depend on the libraries / system you use. However, this concept works reliable under Windows and should work reliable at least for (some) major Linux distros.
Notice that a *.cbplugin for Linux would surely depend on the libraries / system you use. However, this concept works reliable under Windows and should work reliable at least for (some) major Linux distros.
Notice that a *.cbplugin for Linux would surely depend on the libraries / system you use. However, this concept works reliable under Windows and should work reliable at least for (some) major Linux distros.
As far as I am aware no-one has been able to install the Windows .cbplugins I've been making available. I'll put the latest on SourceForge. Please let me know if it works for you.
Thanks.
Not working on my PC with C::B build 6181 on WinXP.Notice that a *.cbplugin for Linux would surely depend on the libraries / system you use. However, this concept works reliable under Windows and should work reliable at least for (some) major Linux distros.
As far as I am aware no-one has been able to install the Windows .cbplugins I've been making available. I'll put the latest on SourceForge. Please let me know if it works for you.
Thanks.
Not working for me! (C::B 8.02 on WinXP)
Not working on my PC with C::B build 6181 on WinXP.
Not working for me! (C::B 8.02 on WinXP)Not working on my PC with C::B build 6181 on WinXP.
Thanks, guys. We're not expecting it to work in 8.02 but its' interesting that it fails in the SVN build as that's very recent.
Cheers.
Thanks, guys. We're not expecting it to work in 8.02 but its' interesting that it fails in the SVN build as that's very recent.
after the release I'm sure the DoxyBlocks will be integrated in the contrib plugins and all will have it. :lol:I support that, too. So it'll be with some others I have in mind, too...
after the release I'm sure the DoxyBlocks will be integrated in the contrib plugins and all will have it. :lol:I support that, too. So it'll be with some others I have in mind, too...
Hi Gary,
As you probably know already, your .cbplugin does not work on SVN 3190 either. It is built on your own non standard CB installation with a non-standard project and is likely to work only on your installation.
I guess that if you do not provide a standard working project based on a standard installation and capable of producing a .cbplugin that works on standard systems one of the maintainers will.
The issue then will be that the published project will not be compatible with your own development system. It'll make it more work for you to maintain it.
Wow! This time DoxyBlocks builds off the shelf on CB build 6190. There is no need anymore for me to merge my version of the project with yours as had been the case with previous releases.
Gary, your published .cbplugin still does not load on my system. I am not surprised, but the difference this time probably comes from my side as I have newer versions of the compiler and libraries. The .cbplugin produced by your un-modified project on my system loads without a hitch.
Apologies for pushing you so insistently. I thought I might have gone too far this time. At least now that you have done it, you have a standard system that will allow you to maintain your plugin more easily in the future.
I am very grateful to you for having provided such a convenient access to doxygen. A portable Code::Blocks (a recent build) including DoxyBlocks will be installed and used by our many users here (I hope) in the next few weeks. It will then really be tested for good. I am likely to have some feedback for you then.
Can't create object output directory /home/.objs/plugins/contrib/DoxyBlocks/
Can't create output directory /home/devel/share/codeblocks/plugins/
Hi guys,
sorry for my noob question, but I already struggle in the compiling step:
Using Ubuntu 9.10 with C::B 8.02 or SVN 6196, I chose the DoxyBlocks-unix.cbp project and simply pushed the build-button.
The I get errror messages:CodeCan't create object output directory /home/.objs/plugins/contrib/DoxyBlocks/
Can't create output directory /home/devel/share/codeblocks/plugins/
Do I have to place the doxyblocks source into a special folder? Or what else I'm doing wrong?
Thanks for your support in advance.
Released version 1.4.366 of DoxyBlocksBTW: You should add a virtual target named "All" to your project files that would compile the main target. This would ensure that when compiling the C::B workspace (where all projects / target belong also to the virtual target "all") you plugin gets compiled, too. I just realised that. Have a look at other plugins if in doubt.
For those people, it would be a pain if they had to set their preferences according to their in-house standards again every time they start a new project. Could ALL the commenting style preferences last used be stored and become the new default commenting style preferences when a new, not yet commented project is started?I was thinking about that myself. My idea would be to have a template file which is read on startup rather than hard-coded internally. This file you could load and parse the buffer for certain tokens to replace - similar as we do it with the default code or C::B's HTML startup page, for example.
PROJECT_NAME = Code::Blocks
PROJECT_NAME = $(project_name)
For those people, it would be a pain if they had to set their preferences according to their in-house standards again every time they start a new project. Could ALL the commenting style preferences last used be stored and become the new default commenting style preferences when a new, not yet commented project is started?I was thinking about that myself. My idea would be to have a template file which is read on startup rather than hard-coded internally. This file you could load and parse the buffer for certain tokens to replace - similar as we do it with the default code or C::B's HTML startup page, for example.
As I start using DoxyBlocks in a few projects myself prior to the big release, I am going to dribble in a few issues as I encounter them. Starting now:
And a minor one:
The prototype: int yes( const char *question );
generates: ----- * @param *question constchar ----- for the parameter.
The prototype: bool yes( const string &question );
generates: ----- * @param &question conststring ----- for the parameter.
Can this be easily fixed?
Released version 1.4.366 of DoxyBlocksBTW: You should add a virtual target named "All" to your project files that would compile the main target. This would ensure that when compiling the C::B workspace (where all projects / target belong also to the virtual target "all") you plugin gets compiled, too. I just realised that. Have a look at other plugins if in doubt.
should be C:\Users\<USER>\AppData\Roaming\codeblocks on Windows.
Prefered %APPDATA%\codeblocks folder.
Hi,should be C:\Users\<USER>\AppData\Roaming\codeblocks on Windows.
Prefered %APPDATA%\codeblocks folder.
If you could manage a complete sentence, that would help. ;-)
What does this mean? Are you suggesting that it would be better to use the path you mention? If so, I can only say that that directory doesn't exist and I don't propose to create a non-standard path. Otherwise, please explain. Note that things may yet change somewhat with this functionality, as well.
Thanks.
I gave the correct location of the Code::Blocks folder NOT just the Windows 7 location.
If you are a Linux person; I excuse your remark; but, a windows programmer should know better.
Tim S.
%APPDATA% is a standard path. Just like %TEMP% is the windows standard for the temporary directory, and %USERPROFILE% the user home directory. Try entering any of these environment variables in the start menu and see what happens.
Tim, Gary, please stop that squabble... it does not matter who started first.
It makes both of you feel miserable and makes both of you look like the "letter of the alphabet" you have started calling each-other.
Let's get back to business.
You are an A because you are not able to think and read; my tone was not bad till after yours was a.
Edit: I am very sorry for assuming your were a programmer.
Tim S.
Gary, here is your explanation:
The reason why using the %APPDATA% environment variable is preferable is that this location is often redirected (the environment variable reassigned) when launching Code::Blocks in a portable manner.
For example I use a CB launcher that reassigns %APPDATA% with: SetEnvironmentVariable(_T("APPDATA"), currDir);
before executing codebocks.exe
edit: I know that Biplab does the same in his CBlauncher and loaden also does something similar, except that he modified the CB code to do it.
Regarding the "settings template", it basically works, but I do not understand the purpose of the "Load settings template" entry.
Isn't the settings template if it exists supposed to be loaded automatically on startup?
Unless you are planning on adding the possibility of choosing between multiple templates in the future (which would be great!), I do not see the use of "Load settings".
Testing the function banner comment generation:
The const parameter issue is fixed. Thanks.
A few other issues would really benefit if they are fixed before a release (like the first one and perhaps the second). Others we can live with for a while.
There are default settings loaded when you first open prefs. After that, the prefs saved in the project are loaded. What the template functionality will do is allow you to import a set of prefs to avoid having to set them manually, as you initially mentioned. Once they're imported, they're saved in the project and loaded from there on subsequent occasions.
The only real question is where we're loading the template from. It sounds like the best option would be to have a file selection dialogue that defaults to the directory pointed to by %APPDATA%. You would then get the default location initially, wherever that might be in the circumstances, and can browse from there. How does that sound?
This needs to be thought out carefully. At the moment 3 different sets of prefs can be active at various points:
When I start a new project the user prefs (2) from the template are active. They are my choices and I don't want to have to manually load them at each new project.
In light of this:
- Load settings issue:
Note that in the above scenarios I have indeed found a usage for the "Load settings" option in Case 2, Existing project (if we keep the current structure with project prefs - see below.).
- No loading of user prefs on startup:
You seem to have a different scenario in mind for Case 2, new project, one that would force a user to manually load their chosen settings from template every time a new project is started.
Are you sure requiring this repetitive manual loading is needed? Is the automatic loading of user preferences on startup hard to do?
- Getting rid of project prefs:
Is the saving of DoxyBlocks project prefs in projects and loading of these preferences from projects really useful? What would be the cost of simply getting rid of project prefs? If the costs are not great, being able to simplify the prefs this way could be worth doing.
-------------------
For Later:
When we have discussed this, we will have to examine what happens when a new project is started after an existing one, or when several projects are concurrently in memory. These are issues that disappear if we get rid of project prefs.
The only real question is where we're loading the template from. It sounds like the best option would be to have a file selection dialogue that defaults to the directory pointed to by %APPDATA%. You would then get the default location initially, wherever that might be in the circumstances, and can browse from there. How does that sound?
Offering saving directory choice is an added interface complexity. It would also make the automatic loading of user preferences that I am plugging for in my previous post impossible.
How about just saving into %APPDATA% or a preset subdirectory of %APPDATA% without giving the choice?
Thanks for replying to my long email.
I am not surprised that you are slowing development on this. It felt like you were working full time on DoxyBlocks previously, and while I was rejoicing at the great job you have done so far, I am also glad for you that you are stepping back and taking a rest from it. There's life beyond them thar mountains of code.
Yes, I am the guilty party putting together CB EDU-Portable.
Can you please edit that post of yours and obfuscate the EDU-Portable URL... (whole bunch of good reasons)
A new release of EDU-Portable is on its way where things start really working (and DoxyBlocks will be there). I'll tell you where and when it is available.
Regarding offering loading the template from elsewhere, it is not an issue with me if it is loading only, it's only an extra click to ignore it, we can live with this. I was afraid that you would be offering saving elsewhere as well.
I was not really expecting you to accept getting rid of the per-project preferences (for the reasons you mention).
On my side I see much added complexity there and some potential issues but little benefit ...
Once again many thanks for this work. Getting apprentice programmers to start documenting their code is tough (ask any programming teacher). With DoxyBlocks presented up-front on the CodeBlocks menu, it will become easy. Students will see it as a normal thing to do and almost as a game. DoxyBlocks will be a major asset for CB EDU-Portable.
I was not really expecting you to accept getting rid of the per-project preferences (for the reasons you mention).
On my side I see much added complexity there and some potential issues but little benefit ...
Hmmm, I dunno why and I don't agree. To me, the template is purely a way of importing a set of prefs, nothing more. It can in no way replace the existing system for storing and managing prefs. There are already measures in place to manage switching between projects, etc. That's WHY we have per-project prefs. ;-)
In My Humble Opinion, we don't need DoxyBlocks at all. first, it can't work in my CodeBlocks; second, we can just use Doxys with CodeBlocks's Tools option. :?
-----------------------------------------------------------
** @brief Example 3: array notation
*
* @param param1[] char*
* @return char
*
*/
char *myFunc(char *param1[])
/** \brief Brief desc.
*
* \param param1[] char*
* \return char*
*
*/
char *myFunc(char *param1[]){};
-----------------------------------------------------------
/** @brief example 4: Operator not recognised as function
*
* @param
* @param
* @return
*
*/
Rational Rational::operator + (const Rational &other) const;
Rational Rational::operator+(const Rational &other) const;
-----------------------------------------------------------
/** @brief example 5: inline (and static) taken as return types
*
* @param num int
* @param den int
* @return inline
*
*/
inline Rational::Rational(int num, int den) : numerator(num), denominator(den){}
...
Scanning for plugins in /opt/codeblocks-svn/lib/codeblocks/plugins
/opt/codeblocks-svn/lib/codeblocks/plugins/libDoxyBlocks.so: not loaded (missing symbols?)
Loaded 38 plugins
...
One or more plugins were not loaded. This usually happens when a plugin is built for a different version of the Code::Blocks SDK. Check the application log for more info. List of failed plugins: libDoxyBlocks.so
linux-vdso.so.1 => (0x00007fff715ff000)
libcodeblocks.so.0 => /opt/codeblocks-svn/lib/libcodeblocks.so.0 (0x00007f1800f9e000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f1800d5f000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f1800b5a000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f180084a000)
libm.so.6 => /lib/libm.so.6 (0x00007f18005c6000)
libc.so.6 => /lib/libc.so.6 (0x00007f1800256000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f180003f000)
libwx_gtk2u_richtext-2.8.so.0 => /usr/lib/libwx_gtk2u_richtext-2.8.so.0 (0x00007f17ffd47000)
libwx_gtk2u_aui-2.8.so.0 => /usr/lib/libwx_gtk2u_aui-2.8.so.0 (0x00007f17fface000)
libwx_gtk2u_xrc-2.8.so.0 => /usr/lib/libwx_gtk2u_xrc-2.8.so.0 (0x00007f17ff834000)
libwx_gtk2u_qa-2.8.so.0 => /usr/lib/libwx_gtk2u_qa-2.8.so.0 (0x00007f17ff611000)
libwx_gtk2u_html-2.8.so.0 => /usr/lib/libwx_gtk2u_html-2.8.so.0 (0x00007f17ff35f000)
libwx_gtk2u_adv-2.8.so.0 => /usr/lib/libwx_gtk2u_adv-2.8.so.0 (0x00007f17ff07c000)
libwx_gtk2u_core-2.8.so.0 => /usr/lib/libwx_gtk2u_core-2.8.so.0 (0x00007f17fea62000)
libwx_baseu_xml-2.8.so.0 => /usr/lib/libwx_baseu_xml-2.8.so.0 (0x00007f17fe856000)
libwx_baseu_net-2.8.so.0 => /usr/lib/libwx_baseu_net-2.8.so.0 (0x00007f17fe626000)
libwx_baseu-2.8.so.0 => /usr/lib/libwx_baseu-2.8.so.0 (0x00007f17fe2cf000)
/lib64/ld-linux-x86-64.so.2 (0x00007f18018b2000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00007f17fdcc3000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00007f17fda17000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00007f17fd7f7000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00007f17fd5cd000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00007f17fd3b1000)
libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007f17fd107000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00007f17fcebd000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f17fcc38000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f17fca06000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f17fc7be000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f17fc5ba000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007f17fc3b5000)
librt.so.1 => /lib/librt.so.1 (0x00007f17fc1ac000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00007f17fbee5000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007f17fbce3000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x00007f17fbad9000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007f17fb8b3000)
libz.so.1 => /lib/libz.so.1 (0x00007f17fb69c000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00007f17fb476000)
libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00007f17fb21b000)
libexpat.so.1 => /lib/libexpat.so.1 (0x00007f17faff1000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007f17fade4000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f17faaae000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x00007f17fa8ab000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007f17fa6a8000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f17fa4a2000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007f17fa21f000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f17fa00c000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f17f9e02000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x00007f17f9bf7000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f17f99ed000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007f17f97e3000)
libpcre.so.3 => /lib/libpcre.so.3 (0x00007f17f95b4000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00007f17f939b000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00007f17f917d000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x00007f17f8f61000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00007f17f8d5c000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f17f8b3f000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x00007f17f88fa000)
libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0x00007f17f866f000)
libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0x00007f17f8464000)
libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0x00007f17f8249000)
libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0x00007f17f8045000)
libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x00007f17f7e3b000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f17f7c38000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f17f7a32000)
Hi,
I've still trouble getting doxyblocks to work under linux.
Could anybody please give me a receipe on how to compile doxyblocks and link everything together?
Add DoxyBlocksLogger.* to the project-file, hey seem to miss in the linux-version.
Add DoxyBlocksLogger.* to the project-file, hey seem to miss in the linux-version.
You are right, I added this to the doxygen-project, but it still don't work here:-(
Hi,
I downloaded the doxyblocks.cbplugin from sourceforge but when I install
it through the Plugin Manager I get the usual error message:
"One or more plugins where not loaded... " etc.
I'm using svn 6181 under Windows XP.
#include <wx/wx.h>
Ok, thx.
Taking a look at the plugin source I saw the line:Code#include <wx/wx.h>
So do I need wxWidgets to compile myself?
Add DoxyBlocksLogger.* to the project-file, hey seem to miss in the linux-version.
You are right, I added this to the doxygen-project, but it still don't work here:-(
make
...
sudo make install
on Ubuntu Karmic. C::B has what I think are serious issues on Linux. I can't run it from C::B, either, although I can build it. Why we have to build from the command line when we're building an IDE I don't know but it refuses to work from the IDE for me. Changes are in the latest SVN.
Jens/maofde,
After rebuilding wx and C::B for unrelated reasons, Doxyblocks now works from the installed version and from my built versions, including via run.sh. I don't know exactly what changed to make the difference but it's nice either way.
Cheers.
I'll give it a try tomorrow with a fresh brain 8)
Edit: svn6261 with Jens patch (adapted to the newer version), doxyblocks rev34 --> on ubuntu 9.10-x64 building via make works fine now!
Thank you Cryogen, it works! This plugin is incredible useful. :D
-interaction=nonstopmode
Hi,
The last Doxygen version (1.3.312) won't load with CB 10.5.
Will there be a version that supports 10.5?
Hi,Hi,
The last Doxygen version (1.3.312) won't load with CB 10.5.
Will there be a version that supports 10.5?
I'd need a lot more information than that before I can do anything for you. I use it almost every day with increasingly later SVN versions. I currently have SVN 6333. 10.5 was SVN 6283, according to the revision graph. What are you trying to do and in what way won't it load?
Cheers.
DoxyBlocks.dll: not loaded (missing symbols?)
I've found an inconvenient situation when using latex formulas: If you have a syntax error inside the formula, usually latex asks what to do and waits for a user input. doxygen waits for latex to finish, which never happends, because there is no possibility to interact with latex, which in the end causes doxyblocks to block codeblocks.
I've two solutions in mind: Either it should be possible to abort the doxygen-call inside codeblocks, or it should be possible to get the console in which doxygen runs and interact there with latex.
I would prefer the second option, the first one would just avoid killing C::B each time doxygen doesn't finish.
What type compiler are you using SJLJ or DW2 like Code::Blocks is using; the plugin failed to load for me and it is a missing symbol like error in code::blocks log.CodeTim S.DoxyBlocks.dll: not loaded (missing symbols?)
fyi : DoxyBlocks is sitting ready on my system to become a contrib plug-in.
We are trying to iron out some last issues.
And then we will create a nightly containing it.
Other plug---ins coming at the same time are :
* Nassi-Shneiderman
* Cscope
* Aligner
The Aligner plugin was merged with the EditorTweaks plugin. Do you plan to add EditorTweaks or the "old" Aligner?
maybe that's a better idea. Could you email me the code, you have my email address ;-)True what danselmi said. The plugin is under SVN here:
And then we will create a nightly containing it.
I am truly anxious! :lol:The word you were looking for is probably "eager", "impatient" or "keen". :P
Hi Cryogen,
I'm no expert at this yet, but I did successfully rebuild Code::Blocks 10.05 for Windows. I have also downloaded revision 34 of DoxyBlocks and rebuilt it from the source. It
........
I hope this helps, and I'm happy to try to bundle this up in a better fashion if someone can give me a little coaching.
Hi Guys,
Released version 1.6.596 of DoxyBlocks
-. . .
-Added: Feature that allows you to load a saved template instead of the default settings, if no saved settings exist when loading a project. Requested by Codeur.
-. . .
Cheers,
Cryo.
Thank you Gary!
I am much obliged to you for DoxyBlocks. It's already been used a lot by students here and will be of huge service when Codeblocks-EP is publicly released and starts being used by other educational institutions (won't be long now.. a month and a bit. It'll be ready for when universities and colleges start again in the Northern hemisphere.).
Any chance on a 10.05 '.cbplugin' yet, or are you waiting on resolving the last few issues?
Hi,
thank you for really cool plugin. :) I have some small suggestions - It would be great if you will add some integration with CodeCompletion plugin
and when somebody will press a key which inserts doxygen comment, DoxyBlocks will detect if in line below carret is function, or class, or struct
(or something else) and automatically insert proper doxygen comment. And another thing - it would be great if you will allow to make custom
"template" for doxygen comments (something like in astyle "source formatter" plugin have for formatting sources).
thank you for really cool plugin. :) I have some small suggestions - It would be great if you will add some integration with CodeCompletion plugin
and when somebody will press a key which inserts doxygen comment, DoxyBlocks will detect if in line below carret is function, or class, or struct
(or something else) and automatically insert proper doxygen comment. And another thing - it would be great if you will allow to make custom
"template" for doxygen comments (something like in astyle "source formatter" plugin have for formatting sources).
/*! \class Test class.h "inc/class.h"
* \brief This is a test class.
*
...
No problem, thanks. Well, it does that already via regular expressions, without CodeCompletion, but it could certainly be extended. For example, I don't think classes are detected at present and that should be easy to do. I have thought about a custom template but haven't looked at it. For me it's unnecessary but I'd like it to be as flexible as possible.Hi,
int foobar(int something, long other)
{
// Before DoxyBlocks
}
/**
* \since [current date]
* \author [current user, or user-chosen value - something similar like ToDo plugin have]
* \brief
*
* \param something -
* \param other -
*
* \retval
*/
int foobar(int something, long other)
{
// After DoxyBlocks
}
template
<
class T,
class TT,
class TTT
>
class FooBar
{
// Before DoxyBlocks
};
/**
* \since [current date]
* \class FooBar
*
* \author [current user, or user-chosen value - something similar like ToDo plugin have]
* \brief
*
* \tparam T -
* \tparam TT -
* \tparam TTT -
*/
template
<
class T,
class TT,
class TTT
>
class FooBar
{
// After DoxyBlocks
};
*** Your caret position A***
void functionXXX ( )
{
*** Your caret position B***
...
}
int NativeParser::FindCurrentFunctionStart(cbEditor* editor, wxString* nameSpace, wxString* procName, int caretPos)
{
...
TokenIdxSet result;
size_t num_results = m_pParser->FindTokensInFile(editor->GetFilename(), result, tkFunction|tkConstructor|tkDestructor);
if (s_DebugSmartSense)
Manager::Get()->GetLogManager()->DebugLog(F(_T("FindCurrentFunctionStart() Found %d results"), num_results));
TokensTree* tree = m_pParser->GetTokens();
for (TokenIdxSet::iterator it = result.begin(); it != result.end(); ++it)
{
if (s_DebugSmartSense)
Manager::Get()->GetLogManager()->DebugLog(_T("FindCurrentFunctionStart() (Next) Iteration..."));
Token* token = tree->at(*it);
if (token)
{
if (s_DebugSmartSense)
Manager::Get()->GetLogManager()->DebugLog(F(_T("FindCurrentFunctionStart() Iterating: tN='%s', tF='%s', tStart=%d, tEnd=%d"),
token->DisplayName().wx_str(), token->GetFilename().wx_str(), token->m_ImplLineStart, token->m_ImplLineEnd));
// found a matching function; check its bounds
if (token->m_ImplLineStart <= (size_t)line && token->m_ImplLineEnd >= (size_t)line)
{
// got it :)
if (s_DebugSmartSense)
Manager::Get()->GetLogManager()->DebugLog(F(_T("FindCurrentFunctionStart() Current function: '%s' (at line %d)"),
token->DisplayName().wx_str(),
token->m_ImplLine));
s_LastNS = token->GetNamespace();
s_LastPROC = token->m_Name;
s_LastResult = control->PositionFromLine(token->m_ImplLine - 1);
// locate function's opening brace
while (s_LastResult < control->GetTextLength())
{
wxChar ch = control->GetCharAt(s_LastResult);
if (ch == _T('{'))
break;
else if (ch == 0)
{
if (s_DebugSmartSense)
Manager::Get()->GetLogManager()->DebugLog(_T("FindCurrentFunctionStart() Can't determine functions opening brace..."));
return -1;
}
++s_LastResult;
}
if (nameSpace) *nameSpace = s_LastNS;
if (procName) *procName = s_LastPROC;
if (s_DebugSmartSense)
Manager::Get()->GetLogManager()->DebugLog(F(_T("FindCurrentFunctionStart() Namespace='%s', proc='%s' (returning %d)"),
s_LastNS.wx_str(), s_LastPROC.wx_str(), s_LastResult));
return s_LastResult;
}
else if (s_DebugSmartSense)
Manager::Get()->GetLogManager()->DebugLog(F(_T("FindCurrentFunctionStart() Function out of bounds: tN='%s', tF='%s', tStart=%d, tEnd=%d, line=%d (size_t)line=%d"),
token->DisplayName().wx_str(), token->GetFilename().wx_str(), token->m_ImplLineStart, token->m_ImplLineEnd, line, (size_t)line));
}
}
if (s_DebugSmartSense)
Manager::Get()->GetLogManager()->DebugLog(_T("FindCurrentFunctionStart() Can't determine current function..."));
s_LastResult = -1;
return -1;
}
TokenIdxSet result;
size_t num_results = m_pParser->FindTokensInFile(editor->GetFilename(), result, tkFunction|tkConstructor|tkDestructor);
@polygon7
I have write my suggestions here about How does CC can support Doxygen. ( I wrote it here, because I hope others can benefit too :D)
Anything new on this?
I'm getting the same "missing symbols?" error when trying to install the plugin in C::B version 10.05 on both Ubuntu 10.04 and Windows 7.
I downloaded the plugin file...do I need other files as well?
My attempt to make an plugin worked; but I have no idea if the plugin works.
The plugin loaded on my Windows 7 32 computer.
Anyone have a site I can upload the Windows Doxygen Plugin to or an email address of a person who wants to test the plugin?
/** \brief
*
* \param
* \param
* \return
*
*/
size_t FindAIMatches(std::queue<ParserComponent> components,
TokenIdxSet& result,
int parentTokenIdx = -1,
bool fullMatch = false,
bool caseSensitive = false,
bool use_inheritance = true,
short int kindMask = 0xFFFF,
TokenIdxSet* search_scope = 0);
/** \brief
*
* \param actual const wxString&
* \param components std::queue<ParserComponent>&
* \return size_t
*
*/
size_t BreakUpComponents(const wxString& actual, std::queue<ParserComponent>& components);
Here is my test on doxygen, which I just right click on the function name and would like to add the block comment
So,
1, I guess the function parameter in multiply lines are not supported.
2, I think we don't need to add the "type" information , so "\param actual" is enough.
any comments?
2. I don't know what you mean, here.thanks for the reply and sorry for my bad English.
/** \brief
*
* \param actual const wxString&
* \param components std::queue<ParserComponent>&
* \return size_t
*
*/
size_t BreakUpComponents(const wxString& actual, std::queue<ParserComponent>& components);
/** \brief
*
* \param actual
* \param components
* \return size_t
*
*/
size_t BreakUpComponents(const wxString& actual, std::queue<ParserComponent>& components);
2. I don't know what you mean, here.thanks for the reply and sorry for my bad English.
I mean thatCode/** \brief
*
* \param actual const wxString&
* \param components std::queue<ParserComponent>&
* \return size_t
*
*/
size_t BreakUpComponents(const wxString& actual, std::queue<ParserComponent>& components);
should be:CodeNot type information about the parameter is need. (this is most comment style in codeblocks' source)./** \brief
*
* \param actual
* \param components
* \return size_t
*
*/
size_t BreakUpComponents(const wxString& actual, std::queue<ParserComponent>& components);
My feeling is, no need to specify the type information (another thing to change when the parameter would become a different type).I agree here, as usually Doxygen handles that for you anyways. I'd say the variable name is enough.
Hi,Yes it's quite easy.
its hard to describe ... but is it possible to configure plugin (update source) so that inserting block comment is one unite editor action and can be removed using one "undo"? Now it needs much more undo operations to return to the state before inserting comment, which is especially annoying in case of accidental comment insertion :)
Done in svn r6840 .
Hi Jens,
No, you go ahead. My SF repo. is defunct, now.
Thanks.
I agree here, as usually Doxygen handles that for you anyways. I'd say the variable name is enough.Yeah, you can see type name already so it's not needed.
First time I use your plugin Cryogen. It's very efficient, good job and thank you !
/** @brief
*
* @param
* @param
* @return
*
*/
void handle_write(const int error,
long bytes_transferred)
/** @brief
*
* @param error const int
* @param bytes_transferred long
* @return void
*
*/
void handle_write(const int error, long bytes_transferred)
Hi,
it seems that plugin has problem with commenting multiline function/procedure declarations. It adds block comment, but parameter names (and types) are missing. For example:
Hi Cryogen,
I just hit a minor bug in DoxyBlocks:
When saving the documentation into a place different from the standard "doxygen" directory and clicking "Extract documentation" in the DoxyBlocks menu, the final message is "Your documents are in: ..\..\..\..\doxygen\ (the default documentation directory) which is incorrect. The documentation is however properly saved in the requested place.
Hey Codeur,Hi Cryogen,
I just hit a minor bug in DoxyBlocks:
When saving the documentation into a place different from the standard "doxygen" directory and clicking "Extract documentation" in the DoxyBlocks menu, the final message is "Your documents are in: ..\..\..\..\doxygen\ (the default documentation directory) which is incorrect. The documentation is however properly saved in the requested place.
I'm afraid that's rather too vague. I'll need specific steps to reproduce it including exactly how you're setting the path.
Thanks for reporting.
Success.
Your documents are in: C:\Utilities\Code\CbLauncher_0.1.5\CbLauncher\doxygen\
Done.
HTML Help not found at C:\Utilities\Code\CbLauncher_0.1.5\CbLauncher\doxygen\CbLauncher.chm.
Default browser launched with URL file://C:\Utilities\Code\CbLauncher_0.1.5\CbLauncher\doxygen\html/index.html.
Thanks for the new version release.
Extracting documentation for CbLauncher.
DoxyBlocks is working, please wait a few moments...
Found existing doxyfile...
Success.
Your documents are in: C:\Temp\CbLauncher\doxygen\
Done.
Index.html not found at C:\Temp\CbLauncher\doxygen\html/index.html.
The path to the output directory is set in the doxyfile by using the doxywizard (project -> expert tab).The output directory ../doc was originally entered in the "output directory" field on that page.
I think you must have re-generated a new doxyfile and therefore erased the output path from the project doxyfile prior to your test, so it could not show the issue.
Can you give me a more precise hint of where it is?Doxyblocks is not related to the wxSmith branch as it is already part of the contrib plugins. Have a look at Cryogens "patchorama" (http://forums.codeblocks.org/index.php/topic,12619.msg95229/topicseen.html#msg95229) or at BerliOS, the patch tracker of C::B (http://developer.berlios.de/patch/?func=detailpatch&patch_id=3127&group_id=5358).
Doxyblocks is not related to the wxSmith branch as it is already part of the contrib plugins...Thanks Morten,
I'll wait to proceed until either trunk is updated with those last modifications or a patch relative to trunk is provided.I've tried myself and it seems this patch is broken I cannot apply it at all: Neither to trunk nor the branch. I've asked for a new patch in the patch tracker accordingly.
Is this one still problematic?
Is this one still problematic?Yes. It does not apply at all. :-(
Hey - this is already applied ! :-)
Patch #3127 was applied on 8 February. I built and tested the new version (1.7.655).
The repair is only partial and the issue is not fixed.
DoxyBlocks still does not properly handle output documents located elsewhere than in the doxygen folder (even when the doxyfile is in that "other" output folder).
Patch #3127 was applied on 8 February. I built and tested the new version (1.7.655).
The repair is only partial and the issue is not fixed.
Yes. See the previous response
... however, you might reconsider your use of the word "properly". As explained in detail below, it still won't do exactly what you're after as it wasn't designed to do so.
I can see the future of this plug-in extracting the documentation and having fly-outs as you highlight a function in auto-complete and by right clicking on things. Keep up the good work.
----------------------------------------------------------------------------------------------------
Extracting documentation for Test.
DoxyBlocks is working, please wait a few moments...
Writing doxyfile...
Failed. /home/killerbot/Projects/Test/Project/doxygen/doxyfile was not created.
Done.
/** \brief
\param
\param
\return
*/
Re-install and make sure you've enabled all plugins!
/** \mainpage wxETKSQLite3
\section intro What is wxETKSQLite3?
\b wxETKSQLite3 is a C++ wrapper around the public domain
written in C++ that allow to access <a href="http://www.sqlite.org/">SQLite3</a> database.<br>
This library is used to allow user to quickly make database binding and make easy request with C++ operators
and is specifically designed for use in programs based on the \b <a href="http://www.wxwidgets.org/">wxWidgets</a> library.
A workaround has been made to make it works with \b <a href="http://qt.nokia.com/products/">QT</a> Library.<br>
<dl>
<dt><b>1.1</b> - <i>02 July 2012</i></dt>
<dd>
QT Integration...
</dd>
<dt><b>1.0</b> - <i>12 December 2011</i></dt>
<dd>
First release - Not published...
</dd>
</dl>
locate codeblocks | grep -i "Doxy"