Opening Doors.
Getting inside the IDE
by Allen Bauer, Staff Engineer/Delphi/C++Builder IDE R&D Manager
An Overview of the Open Tools API
Design Goals
In order to better appreciate what the Open Tools API provides the developer
I will outline several design goals that have driven the development of the Open
Tools API (OTA). This will hopefully get the reader "on the same
page" and set appropriate expectations. There have been many
"Blue-Sky" proposals for OTA enhancements over the years. While
many have merit, many are beyond the scope for what the OTA is intended.
For example, providing access to the compiler's browser information is
definitely within the realm of possibilities. Whereas allowing the code
editor to be completely replaced by a third party is currently not
planned. (the technical details are too numerous to detail and could be
the subject of an entire article).
Expanding the possibilities
One key goal of the OTA is to provide a mechanism that allows for post-ship
enhancements to be made either by Borland or third parties. This is
accomplished by providing a rich set of interfaces to key IDE sub-systems.
These sub-systems include Editor, Debugger, Form Designer, Module/File Handling,
User Interface (Menus, docking forms, etc...). Since the possible
enhancements to the IDE are virtually endless, there is no way that the Delphi/C++Builder
team (regardless of team size), could implement them all. This also opens
doors for many industrious third party developers to provide these things.
Consistency is key
Another requirement was that these interfaces be exposed in a consistent
manner that leverages the the same skill set across the entire set of
interfaces. The most visible example of this is the Notifiers; All
notifier interfaces are implemented by the developer of the IDE enhancement and
serve as a coduit through which the IDE can notify enhancements of events
deep in the IDE. All these interfaces descend from IOTANotifier. In
most cases, when a descendant of IOTANotifier is implemented, all the ancestors
must be declared and implemented as well. This is due to the fact that the
IDE centralizes the calling of these interfaces so it must work on the lowest
common ancestor. This is one of the common errors made by OTA developers.
Carved in stone
The last requirement I'll discuss (there are others that will be
covered in future articles), familiar to most programmers that have worked with
COM; Once an interface is published the declaration can never change.
This insures that an IDE enhancement will not become invalid when used with a
new release of Delphi or C++Builder.
In practice, however, this is somewhat different than the more traditional
COM model because an IDE enhancement will typically be linked against that
product rev's run-time packages. Using packages to implement the IDE
enhancement greatly simplifies the programming model because the programmer has
full access to the exact same copy of VCL and the RTL that the IDE uses.
This is how many of the more advanced IDE enhancements pull off their
magic.
By doing and end-run around the nicely "sanitized" OTA, some
interesting things can be done. Be warned, however, because these kinds of
enhancement are now at the full mercy of the Delphi/C++Builder developers with
regard to internal IDE code changes. The OTA can be viewed as a contract
between the IDE developer(s), and the user. By moving outside that realm,
all bets are off and one must understand the consequences. The most severe
of these is when the same major revision of the IDE is changed in an update or
service pack This kind of subtle bug is caused by programmers playing
outside the bounds of the published OTA.
For instance, say a given enhancement expects to find certain forms in the
Application.CustomForms[] but the class name was changed. While this kind
of change would have no effect on an enhancement that adheres strictly the
published OTA, it could have profound effect on these enhancements which do an
end-run around the OTA.
The reason I bring this up is that in a future article, I will reveal some
secrets which will allow anyone to write an IDE enhancement that creates
onscreen forms that can be docked like any other built-in IDE form!
In the next installment, I will show you how to get started in writing your
own IDE enhancements. In the mean-time, check out the wizard I wrote that
creates an IDE keybinding enhancement. Full source code is included.. In
fact you have to compile it yourself. You'll need to be a member of the
Borland community site in order to gain access to this since it is in the
CodeCentral repository.
http://ww6.borland.com/codecentral/ccweb.exe/listing?id=13907
I look forward to "opening more doors" in the future and giving you
more insight into the inner workings of the IDE...
Allen Bauer.
| 
