|
|
|
Home » Developing U++ » Documentation » T++ working
| Re: T++ working [message #19061 is a reply to message #19057] |
Sat, 08 November 2008 10:36   |
cbpporter
Messages: 1427
Registered: September 2007
|
Ultimate Contributor |
|
|
| captainc wrote on Sat, 08 November 2008 00:41 |
Great stuff. You rock. 
|
Thanks! I intend, with a little help from you all of course, to get everything that is worth documented from Core documented. And Chameleon too. The rest like CtrlLib, PDF, etc. I'll have to leave to others  .
I added documentation for Rect_. It does not contain all the methods, but I'll ad them in the next session. Rect is a little bloated.
Also a question: what is with all the tpp. files. They seem to be generated on the fly. And what about all.i. I also get the impression that those files should not be up on SVN.
And a suggestion: sure, the new system is great,but if you are not using the help browser, you are stuck with having to browse sources to get the documentation for something. It would be great to add a small description frame in the bottom of the auto-complete window. When pressing . and using the cursor to highlight a method, the description should pop up bellow the class list and the method list, with exactly the same content as if I were to hover my mouse over the respective little icon.
|
|
|
|
|
|
| Re: T++ working [message #19064 is a reply to message #19053] |
Sat, 08 November 2008 14:27 |
 |
mirek
Messages: 14255
Registered: November 2005
|
Ultimate Member |
|
|
| cbpporter wrote on Fri, 07 November 2008 15:17 |
I finished MathUtil, except for about six function which I don't know what they do exactly, so I've left them empty rather than write an approximate description.
|
I will alert the author 
| Quote: |
I also extracted the constructors and destructor of Vector to it's own section, like in other docs. It is distracting to read a function doc, then a couple of constructors, then a destructor, then again some functions, then another constructor. Having them in the same place is better IMO.
|
I do not know, but perhaps it is really a little bit better.
BTW, it seems like export to HTML of these tables is a little bit wanting. Something to check...
| Quote: |
I can also do a check-up round on all the other docs from Core if you don't mind. I saw that most have their references fixed.
|
Excellent. Please, update from svn before each run, I am fixing random topics as well.
Mirek
|
|
|
|
|
|
| Re: T++ working [message #19142 is a reply to message #19072] |
Fri, 14 November 2008 21:34 |
cbpporter
Messages: 1427
Registered: September 2007
|
Ultimate Contributor |
|
|
I updated another bunch of documentation files. Nothing very interesting .
The only problem was String. String is extremely complicated and this makes it hard to document. If I maintain the current style with String and WString documented together, it makes the document more concise, but it leaves a lot of code without document references, making the little icons useless. String being so complicated should get all the help that it can get.
On the other hand, if I document them separately, the documentation becomes a little more redundant, but more items are documented.
I tried something experimental: I documented String as if were a normal class without that complex templated inheritance. Wstring will be documented with the same approach. And AString will be also documented as an interface that bridges between the two types. If a method appears in all 3 classes, like with Cat, the same documentation will be copied to String (String0 that is, but I left String0 undocumented as I considerate a private implementation detail), WString (WString0) and AString. This way if someone reads String code or documentation, all the info will be available. If someone browses over AString code, then again valid documentation will be available.
You can check it out in SVN. I left the old doc intact, but prepended it with a String doc. Let me know what you think about this approach. Another approach would be to allow a documentation to be linked to multiple definitions, but I would prefer to not further complicate A++.
| Quote: |
Also a question: what is with all the .tppi. files. They seem to be generated on the fly. And what about all.i. I also get the impression that those files should not be up on SVN.
|
I would still like to know the answer.
|
|
|
|
| Re: T++ working [message #19150 is a reply to message #19061] |
Sat, 15 November 2008 14:48 |
|
mirek
Messages: 14255
Registered: November 2005
|
Ultimate Member |
|
|
| cbpporter wrote on Sat, 08 November 2008 04:36 |
Also a question: what is with all the tpp. files. They seem to be generated on the fly. And what about all.i. I also get the impression that those files should not be up on SVN.
|
tppi files are "included" files into C++. They are only relevant if you are using T++ for application docs, e.g. help (appdoc group is reserved for this purpose).
You need to explicitly activate generation of tppi by making the group "includeable".
Note: 2008.1 used identical format in all cases. Anyway, that did not played well with conflicts in svn, as the format was basically compressed -> that is why I have made the change. (The idea is, of course, that you can safely ignore the conflict in tppi, just serve the tpp problem).
As for those files being required in svn, hard to say. You cannot compile without them and you need theide to generate them and they do NOT get generated before compilation even in theide.
IMO, ignoring them for svn would cause more troubles than having them there.
Mirek
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: T++ working [message #20326 is a reply to message #20325] |
Wed, 11 March 2009 12:01 |
cbpporter
Messages: 1427
Registered: September 2007
|
Ultimate Contributor |
|
|
Results are much better. Still a little margin visible, but I'll fix that together with my proposal for HTML generation.
As for the generated HTML, I think that any web developer who writes such HTML in 2009 should immediately buy a book on this subject and not leave the house until he can write pages that actually have a chance of passing any validation . And since XHTML is pretty much a subset of HTML, and XHTML code is valid HTML code, all code should be XHTML compatible, albeit sans the XML headers.
PS: I updated Pusher and all derived control documentation (except for OptionButton). I can't commit just yet because my new security measures keep me cut of from SVN. I'll commit from different computer latter. Just letting everybody know, so that we are not working on the same pages.
Also, I started going over old unresolved issues of mine. I'll start giving them arbitrary numbers to keep track.
Issue #001 is documentation. Am working on it.
Issue #002. The code reference window used to show little icons for documented items. With new changes, this feature was lost, but it still works for public functions, but not class members. So either make it work for everything, or remove it completely.
[Updated on: Wed, 11 March 2009 12:03] Report message to a moderator |
|
|
|
| Re: T++ working [message #20337 is a reply to message #20326] |
Thu, 12 March 2009 11:56 |
cbpporter
Messages: 1427
Registered: September 2007
|
Ultimate Contributor |
|
|
I tried running some validations on the generated HTML. I navigated to the CParser documentation, and ran validation on it, together with U++ site content. I got 76 errors. After I ran validation on content only, without U++ site, and got 0 errors. Pretty good, this means generation is OK.
Then I switched document type to XHTML and got 2579 error with U++ site, and 2157 without site. Seeing that these two formats are almost identical, such a huge number of error is not a good think.
I uploaded a version of EncodeHtml that keep 0 errors for HTML, and reduces errors to 150 for XHTML. There is still lots to be improved, but I wouldn't like to submit large changes all at once.
HTML size is a little bigger, but it's negligible.
Also fixes the last padding issues I could find.
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Tue Apr 29 14:57:20 CEST 2025
Total time taken to generate the page: 0.05219 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
