|
|
I am working on a CodeTool for the RB, I've something that more or less
works, but there are bugs that I can't seem to resolve. The general lack of
design documentation and lack of a clearly-defined API for CodeTools have
wasted a lot of my time. After staring at incomprehensible code for two
days, I feel stuck.
I'd like to solicit the collective wisdom of this list, so that we might
eventually try and improve the class comments and documentation. Probably,
we'll get it wrong, but since the original designers dropped the ball on
this, expectations must be lowered. It is obvious enough that one must
subclass CodeTool and CodeToolSelectionPolicy. The fun begins after that.
W.r.t. the API, as near as I can tell, a CodeTool needs to provide some of
these methods:
#activeTool
#subcanvases
#rebuildMenus
#resetBuilder
#saveState
#updateDisplay
#updateContents
#updateRequest
#isEditing
#isTextSelected
#isTextTool
Some of these are probably optional. There may be others I've not found. To
figure out an API in VisualWorks, one must trawl through a bunch of
different classes, trying to guess which methods are public, which are
private, etc. It's far too difficult.
What, exactly, all of these methods are supposed to do is something of a
mystery. Most of them have no comments and some have vague or even
counterintuitive names. #subcanvases, for example, does not return a
collection of any sort of VisualComponent, but in fact a collection of
models. I can try to guess what #resetBuilder is going to do, but I have no
idea why it is being sent or what need it fulfills.
By inserting breakpoints, I find that some of these methods are called many
times. When I open a CodeTool for the first time (e.g., clicking on the
"Properties" tab in the System Browser), I find that the models are queried
nine (9) times for their contents, #resetBuilder, #subcanvases, and
#updateDisplay are sent five times, and the CodeTool's subcanvas is rebuilt
from scratch six times. It's all too confusing to try and get a clear
picture of what's happening.
At first, I thought some of this superfluous activity was due to known
problems in the wrapper UI classes, but upon closer investigation, it seems
that the cause is in the RB CodeTool framework itself. There is some kind
of quasi-circularity between #updateDisplay and
#installSubcanvasIn:using:spec: (the latter being a rather ugly method that
manages to use both #respondsTo: and #isKindOf:).
Any ideas, tips, pointers to Wiki pages or newsgroup posts would be greatly
appreciated.
M
|
Locked
