|
Is it possible to export the generated document to a Wiki ?
Code that isn't documented can then be documented using the Wiki manually.
!@#$%^&*()_+
|
|
|
|
|
Hi thanks for such a great tool. Overall its very nice, I like it much more then doxygen. I am, however, having some problem with callgraphs. I enabled callgraphs in the config file and also tried adding \callgraph in the functions description. DoxyS is generating incorrect callgraphs in both the cases, all the arrows representing calls from a functions point to function making those calls. I guess in the callgraph nodes representing different functions are rendered at the same place, so it appears all the arrows point to same funciton. Is this a reported bug or am I doing something wrong?
Thanks,
Saurabh
|
|
|
|
|
Great work, brilliant tool! But I'm having the same problem... It appears that the call graph works on a class/file basis (ie. each box represents a class or a file) but displays only the first function name it calls - so if you have two functions called in the same file, it just points to itself (or has double arrows to that file).
If fixing it properly will take a considerable amount of time, or if screen real estate is a problem, may I suggest a quick fix:
Fix it in three stages:
1) As it is inaccurate (and therefore hardly usable) in its current form, first change it to display the class name (or filename if processing C) instead of the function name. This will at least make it correct and moderately useful.
2) After doing point 1), expand the box so that it lists all functions that are called from that file. This will obviously make the file boxes larger, but more descriptive.
3) After points 1) and 2), and when you have a lot more time to spare, think about pointing the arrows at the correct function in the list.
|
|
|
|
|
Hi All
We have (finally  ) released version 0.87b of DoxyS.
(see www.doxys.dk)
The main new thing is that all graph generation is compiled into
doxyS executable so now you don't need to install the dot tool anymore.
Ofcourse there are a number of bugfixes as well. One in particular is a fix
for the previous version tremendous lonf filenames which could occur and was
a real problem as they could exeed typical maximum of 256 chars.
We will begin fixing a lot of the bugs which people have reported since the last
release. But first we will prioritize the order in which we fix them, which will
be visible from our website during the next weeks.
With a little luck we get a new team member to help us out which would be very great.
And as allways if you should feel the urge to help us out in programming DoxyS ... Then we would like to hear from you!
Regards Martin Harring and Martin Lütken
|
|
|
|
|
Why does DoxyS freak out if it sees Doxygen group tags?
|
|
|
|
|
We disabled the Doxygen groups by design... because we concluded that they were hard to use and that our \page system can do something similar .....
.... But ...
We regret the decision and will reenable them again ... just need input to how they should be displayed in the documentation....
Regards Martin Lütken
|
|
|
|
|
It would be nice if DoxyS would just IGNORE the groups instead of throwing errors. You see, I used previously Doxygen to document a (quite large) project. And with Doxygen, the only way to get some organization in a large output, is with groups. So I took a lot of effort to put everything in groups.
I still wasn't satisfied with the result and decided to give DoxyS a try. The first thing I noticed was that I had to remove all group tags by hand (and there were a lot). The second thing was that DoxyS did not run with my sourecode anyway (see post below). Returning to Doxygen, I now have to put all groups in again  ...
|
|
|
|
|
I think it would be easy to make DoxyS just ignore the group tag...
About the templates. If you mail an example to ml@doxys.dk I will fix it as the first thing and make a new release!
Regards Martin Lutken
|
|
|
|
|
It seems that DoxyS has big problems with templates which are not directly inlined, but where the body of the template function is in a separate .inl file.
For each of these functions I get a warning: "No matching class member found". And even more, DoxyS does not produce any output and simply says "This application has requested the Runtime to terminate it in an unusual way."
With plain Doxygen, it works. Is this a bug, or what?
|
|
|
|
|
I am afraid that is a bug!
Quite serious, but I must admit it has not been tested. I allways implement templates in the header file since that what STL, Boost and others do. Can you please mail a small example to bug@doxys.dk, and I will try to fix it..
Hopefully we can make a release within this week ... however this bug I can't promise will be fixed...
Regards Martin Lütken
|
|
|
|
|
Shame on me! 
I just discovered that it's definitely not the templates which make DoxyS bail out. I will try to figure out where the problem is and send it to your email address.
Keep up the good work!
|
|
|
|
|
Great!
We really want to fix those kind of problems!
There is a new version out now! Since yesterday!
Regards Martin
|
|
|
|
|
DoxyS - How come you don't tout/market/profess DoxyS' inherent use in documenting PHYSICAL software architecture in addition to logical (i.e. John Lakos - Large Scale C++, Software Design)? Your collegues, including Doxygen do not provide a way of documenting this critical perspective of a system's architecture. For example
||Physical||Logical
|Package|Directory
|Component|Unit
This is a key point I think many people don't care to comment about, but it is the core of your paradigm. In addition, your pages feature provides a space for us to put our higher level UML diagrams that cover multiple components (units) and or packages (directories).
Care to discuss?
ErickR
|
|
|
|
|
Sorry...correction to table above
||Lakos||DoxyS
|Package|Directory
|Component|Unit
|
|
|
|
|
Hi
Very interresting thught you have there!
I could mention that one of the key reasons for starting the DoxyS project was the lack of a natural place to put the overview documentation for the code in a directory. At the time I was working in computergames and we had 500.000 lines of code with no documentation what-so-ever. I did not miss class/function documentation the most, but I really missed overviews of each of the 160 main- and sub-directories. Documentation outlining how to use the code in this directory and it fits into the grander picture.
But my own side ambition is to also use the page/dir concept for more than just documentation. I hope it could be used for also design documents and general documentation not necesarily code related.
To that end I would like to have a simple WYSIWYG editor for DoxyS wiki-like syntax. This would make it (for many people at least) nicer to use when writing larger designdocs etc., but still make it possible to open the documents in any simple text editor and make modifications to the text. This is convenient whne for example coding: A change in the code might call for a documentation a desig-doc change ... if you first have to find a Word document on a remote server you are likely not to get the correction into the design document.
It is important however to keep the wiki-syntax easily readable in plain text form. We do not want to reinwent HTML/XML style formatting which is really not user freindly to read in my humble opinion.
Also since we are using simple text files it is possible for many people to work together on the same document using version control systems like CVS or whatever you prefer. You can easily make diffs between versions and we could even make the WYSIWYG editor have a dual-diff-view-something allowing for easa merge even for non-technical people.
Well this got long! I hope it is not too far from what you meant, but anyways I really needed to get this out ..
Regards Martin Lütken
|
|
|
|
|
Thanks for the quick reply. Also, I wanted just to comment briefly on your statements.
1. I concur...class/function documentation is not where I like to start looking at a system and DoxyS does a marvelous job in extending documentation for subsystem or package level entities.
2. DoxyS really does allow us to integrate a design document with source code without making it painful (i.e. XML). The design and source really become one in the same; and when someone new to the system has a high level starting point to look at, it makes it easier to for them to dig deeper into the details (that is...the details they are individually interested in). This is a huge difference from other tools that I hope people recognize when they first start using DoxyS...one exception to this might be Headway ReView now called Structure 101 (but it's not free!).
3. Lastly, since DoxyS was designed to document the physical structure of any text content (not just logical source elements - class, function) it only makes sense that it would mesh well with physical software design techniques as presented by John Lakos. What I realize now is the similarities are not coincendental in nature but merely intrinsic to the problem of designing and documenting a system comprised of a heirarchy of physical entities.
4. With that said, I think DoxyS has potential of going further in this direction. Some ideas include making use of package and component diagrams. Making use of the Lakos metrics (CCD, NCCD, ACD, etc.) or even other object-oriented metrics (Martin's instability and abstractions principles) is relatively trivial but can offer a lot of insight into the high-level structure of a system. Lastly, but not so closely related is enabling pdf support for all of this great documentation we are now doing.
My response was much too "longer" than yours, but I just wanted to affirm my approval with what DoxyS has done and hopefully bring to your attention how closely it's paradigm is related to physical software design. This is such a fundamental difference to Doxygen (and others) that I don't think it should be brushed aside. Thanks, ErickR
|
|
|
|
|
It looks very well, but there is one thing I do not see:
In the "Call Graph" I do not get what I would expect:
Every Point in the app where that method is called from and every method it calls.VC has something like this but has serious problems when using objects from libraries.
The same goes for data members.
This is actually the most desired feature of any documenter.Anything else is nice, good to impress supervisors, but with very little practical use.
But maybe I have looked in the wrong place...
|
|
|
|
|
I think we know what you mean. Until now we're still using the original callgraphs from Doxygen, and they are a bit strange.
Seems that the arrow goes between classes, instead of between the individual methods in classes. We do plan to fix this . We are still rewriting all the graph generation code, to use a compiled-in version of the dot-tool. we have made an easy to use class based API for generating dot-graphs. As soon as we have that working in the old way we will look into the call-graph diagrams. Any suggestions to how it should work are welcome.
|
|
|
|
|
This may sound like a bit fo a noob question, but when I run doxys on some source I get a Windows pop-up "Open File - Security Warning" asking if I want to run dot.exe. The problem is it pops up about a thousand times while doxys is creating the documentation files.
I figure someone here would know how I can disable this bizarre behavior?
|
|
|
|
|
Do you have the file on a network or removable drive?
John
|
|
|
|
|
No, Doxys is installed on my main drive. I am running a RAID 1 (Mirror)configuration though.
|
|
|
|
|
I really like what this tool is doing for me. However, I've one problem I can't figure out. I'm documenting a typical function in the following manner:
/**
Enable or disable the window's menu.
EnableMenu enables or disables the window's menu and submenus.
*/
void cWindow::EnableMenu(HMENU _hMenu, ///< The menu to enable
bool _Enable) ///< #true# to enable
{
if (_hMenu==GetMenu())
SetMenu(_hMenu);
}
In the generated documentation, I get the parameter description repeated. The parameter list will be correct, but I will see "The menu to enable The menu to enable" in the description.
Any ideas what I'm doing wrong? Can I give you any more information?
|
|
|
|
|
Hi Doxy's
I haven't tried your tool yet, but the screenshots turned me on  - so I want to know a bit more about the project and its future before i commit myself to using the tool.
What's the future plans of this project? I can see that there is a lot of things to do
http://www.doxys.dk/doxys_homepage/homepage/Project_Status/FeaturesTodo0_page_description.html
But how dedicated are you? Are you willing to commit to the future development that is needed to keep this project alive? Is this going to evolve into a commercial product at some time? What about donations?
One important issue is IDE integration - do you have any plans in that department? I've tried using a webbrowser on the side, but it's not the same as something that is integratet - like Eclipse and Javadoc.
Last but not least, its nice to see a project from DK here
/Markowitch
|
|
|
|
|
First: Thank you Well try it out. It's very easy to use. Just place yourself in the root of your code directory and type 'doxys'. Assuming you placed doxys and dot executebles somewhere in your path.
As for the commited thing:
We are very committed both of us and will continue to develop DoxyS. We have been working quite hard for 1½ years to get to where we are now, but we still have lots of ideas . Also we wish it to become as stable and reliable as possible!
IDE integration:
We do have some IDE integration for VS.NET, and Bobby Michalca has promised to make an even tighter form of integration to VS.NET (I'm not sure actually what this exactly mean though).
We plan to make tools to help you actually write the documentation via plugins for various editors. But if it's just about being able to access documentation from the IDE, we so far only have it for VS.NET. We would very much like to have it for other editors, but we would probably need some help from you people out there in order to do that
Maybe you can elaborate a little on what you mean when you say IDE integration or perhaps you can even help in implementing it .. either by doing it yourself or a least educate us howto make IDE integration for Eclipse if thats the one you want support for. Making the XML file for .NET integration was not that hard, and the class doing it should make a good stating point for others like it.
Regards The DoxyS team (Martin Harring & Martin Lütken)
|
|
|
|
|
Doxys can generate the Html Help projects for you. Also there are some settings to make doxys look more like MSDN (no menu on left side, etc).
After that all you have to do is call hhc to generate .chm file. More details on will be available with the next release help.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
