Opening Doors Part1 - Delphi K.Top 討論區

發表時間：2003-01-14 12:00:55

IP:61.218.xxx.xxx 未訂閱

Opening Doors: Notes On the Delphi ToolsAPI by its Creator - by Allen Bauer Abstract:This article, by Delphi R&D member Allen Bauer, provides an overview of the ToolsAPI. Readers will learn how to enhance the Delphi IDE. 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. 網路志工聯盟----Visita網站http://www.vista.org.tw ---[ 發問前請先找找舊文章 ]--- 發表人 - axsoft 於 2003/01/14 12:02:59