My favorites | Sign in
Project Home Downloads Wiki Issues Source
Search
for
CommentStyle  
How to add your own comments to document the code.
Featured
Updated Feb 4, 2010 by dentaroo@gmail.com

Current Disclaimer

Comments in the RB source are currently not processed - none of the source lines are processed other than declarations.

That's actually not a hugely difficult change to make if someone gave me a little encouragement (already received from the person to who I originally emailed these instructions - see issue 10).

I could copy comment blocks that were just inside the method into a Java comment with appropriate Doxygen / marker.

I normally put the comments in a separate file.

Details of Using a Separate File

If you look at the online sample there is quite a lot of documentation on docWindow at the bottom of the page.

that is generated by this comment in a separate .java file

/**
\class docWindow
The docWindow class encompases a drawing region and rulers.  The docWindow object is the entry point for most operations within the application.
The docWindow instance is the first object to be able to process user data.  
[AD even if not frontmost??]

The docWindow MouseDown, MouseDag and MouseUp calls determine which shape instance to operate on, then send appropriate messages to the shape instance.

The docWindow instance handles modfication of mouse co-ordinates to handle a scrolling drawing region or grid snapping before passing that data to the shape instance in question.

It also handles display of a user grid, if required.  The docWindow instance informs the application and inspector window instances of the currently selected shape instance so those isntances can update as required.

The docWindow instance implements the majority of the menu items available within the application such as effect selection and 'Edit' menu items such as Cut, Copy and Paste.

The docWindow instance handles manipulation and display of document rulers including scales and scrolling of those rulers.

\par Window Sizing
This is a complex issue because of the interactions between the auto-sizing behaviour of the Window plus need to size other panels.
\n
We must maintain a canvas drawing area sufficient to draw on the entire page
size of the current template.
\n
If the user sizes their drawing area larger than that we have an empty window and may draw page boundaries.
\n
If the user sizes their window smaller than the min area required then we will
be scrollable up to just enough space to keep the page boundaries in view.

\par Contextual Menus
Contextual menus in the docWindow are handled differently depending on being
in clear space (see MouseDownCMMInEmptySpace) or on a shape.
\n
If on a shape:
- select it
- display different menu depending if locked
- if they choose an Add Shape item, add the new shape
*/

Sign in to add a comment
Powered by Google Project Hosting