REALbasic Computed Properties Debugging Gotcha

I’ve been doing a huge amount of work recently porting the C++ OOFILE report writer to REALbasic as a complete transliteration, having given up on the earlier report-writer I was writing from scratch.

I’m using REALbasic 2008r4.1 and finding it extremely flaky when debugging. I finally worked out the cause and it’s an interesting trap.

OOFILE was written about 15 – 10 years ago and makes use of lots of inline and non-virtual functions for high-performance in C++. Methods in REALbasic are, of course, all virtual but it also has Computed Properties which allow you to write code as getter and setter functions. These are non-virtual and therefore (presumably) much faster – an ideal and idiomatic match for the inline getters and setters used heavily in OOFILE.

However, there’s one very big gotcha – if you look at an object in the REALbasic debugger, all its getters on computed properties are executed.

Continue reading

Culling Features to Ship – Rotating Shapes

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:

  1. Rendering the rotated shape, which may require an additional level of masking on Windows and Linux.
  2. Drawing drag-shapes as rotated or at least rotated rectangles.
  3. Drawing the selection outline and handles at rotated positions.
  4. Changing the cursor type as you mouse-over rotated handles, once you have rotated past 90 degrees.
  5. 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.
  6. Changing the behaviour of constrained resize or drag, if modifier keys held down, similarly based on shape angle.
  7. 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).
  8. 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.