The design of rbrw basically follows that of the OOFILE report-writer, specifically the Windows environment:
- specify a report layout using a few classes pointing to data sources
- choose an appropriate environment that acts as a factory to create renderer classes that mirror each of the layout classes
- renderers generate output as a series of Drawing Elements, collected into pages
- draw a single page on a preview window, or multiple pages to a printer.
The current task is to create a right-aligned page count eg: Page 1 of 3 for a report.
This poses two large and one small problems: Continue reading
I posted the first downloadable archive of rbrw-core yesterday and spruiked it to the RB NUG mailing list and the forums for ARBP and RealSoftware.
This release was prompted by achieving an inhouse milestone of producing robust Financial Statements at Inforge. In order to get it out the door, I did some last minute hacking to basically render borders in a fixed manner, which needs generalising.
Due to many distractions, it has taken a while for the port of OOFILE’s report-writer to REALbasic to achieve some usable state. I’ve just committed the first version which includes printing and crude preview to the rbrw-core repository. The directory layout may look a bit weird, with many empty directories. That is because most files are external XML format (under the top rbrw directory) but the VCP format used for the sample creates a hierarchy of empty directories.
I will be adding more documentation over the next few months explaining how to use the library and how it works (the latter proving more challenging than I realised – it’s been nearly 10 years since I did more than trivial extensions). In a bitter lesson about using digital documentation, the inches of paper-based design documents for the original product have been mislaid/filed in one of my house moves of the last decade.
This initial release does include a fairly comprehensive sample program showing how to create reports of various styles. Continue reading
When I review the list of bugs in my generic shape editing source, many of them are related to either the behaviour or the final rendering effects of being able to rotate shapes. Rotating shapes in an editing environment, especially those with text, involves a lot more work than people may at first consider:
- Rendering the rotated shape, which may require an additional level of masking on Windows and Linux.
- Drawing drag-shapes as rotated or at least rotated rectangles.
- Drawing the selection outline and handles at rotated positions.
- Changing the cursor type as you mouse-over rotated handles, once you have rotated past 90 degrees.
- Changing the behaviour of constrained resize handles, depending on the angle, as X movement may now for example imply changing the height of the shape rather than width.
- Changing the behaviour of constrained resize or drag, if modifier keys held down, similarly based on shape angle.
- The dilemma of whether to implement rotated inline editing or to jump to a straight edit box (which maps to the issue of using edit boxes for inline editing or rolling your own behaviours).
- Possibly changing or enhancing the behaviour of nudging shape positions with the arrow keys or menu option (I always like to include a menu equivalent). If a shape is rotated, do the arrow keys move it along the XY axes relative to the canvas on which it is drawn or relative to the shape itself or do you give the user the ability to choose as a preference or runtime toggle?
When I consider the domains in which the generic editor is going to be used for our initial products: report-writer layout, screen layout and possible diagram editor, rotation becomes a lot less desirable than the original arbitrary editor required. However, dropping rotation from the common editor does constrain all of those products for now.
Decision: retain rotation code where possible, to avoid too much culling, but remove the UI for the feature so any related bugs can be deferred until the next version.