Delphi package types: Runtime, Design Time and IDE

An interesting question was asked on Nick’s blog regarding the differences between IDE and “normal” packages. First, all Delphi packages are really just normal packages the differences are how they are used and loaded particularly  by the IDE. The various packages types are as follows:

  • Runtime
    • Make up the Delphi RTL/VCL. They’re used by the IDE as well as by your applications if you have Build with runtime packages checked in your project options.
  • Design time
    • Typically contain code which augments components as their used in the designer including things like component registration, property editors and component editors. These can also include OpenTools add-ins.
  • IDE
    • Core packages – those required by all personalities
    • Personality specific packages – Delphi, C++Builder etc.
    • Personality agnostic packages – which contains things like the HTML editor and the Welcome page

I hope that answers the question!

4 thoughts on “Delphi package types: Runtime, Design Time and IDE

  1. Is the OTA the ‘interface’ for IDE packages, or is it possible to interact with the IDE on a deeper level? I guess your own packages, like the ones to implement particular personalities, use a lot of stuff us normal users can’t?

  2. Can you elaborate on the difference between Designtime and IDE packages? Are they loaded differently/at a different time? Do they have to fulfill any special requirements (e.g. implement special procedures/entry points)? What is the "official" procedure for registering an IDE package?
    It seems this article is written entirely from the perspective of CodeGear in that it only deals with the bundled packages. It doesn’t cover what steps have to be taken to create runtime/designtime/IDE packages ourselves (it’s obvious for runtime and designtime but not quite so for IDE).

  3. Hi Oliver,
    IDE packages are the domain of CodeGear and are not something customers would be writing. For end users the OpenTools API (OTA) is the mechanism to use to build add-ins for the IDE. IDE packages are not bound to using the OTA and in most cases they use a combination of the OTA and other non-public internal interfaces. In a perfect world all IDE packages would strictly use the OTA but that’s not the case which is why people like Eric Berry (of GExperts) constantly are requesting additions to the OTA for better access into the internals of the IDE.
    That said the OTA isn’t the only means of interacting with the IDE since it’s just a Delphi application based on the VCL there is really nothing that prevents an add-in from "getting in and messing around" with the object hierarchy inside of the TApplication object that is the IDE. The OTA is more or less a contract between CodeGear and add-in producers that those interfaces will stick around and be available whereas mucking with VCL object inside the IDE is playing rather "fast and loose" and could break in a subsequent release.
    it’s just the only real "contract" provided by CodeGear where we try to maintain compatibility whereas we’re free to change internal intefaces.

  4. Steve -> We could stand to see that contract broken in the spirit of simplifying access.
    Getting access to the contents of the current document being edited is needlessly complicated (almost insanely complicated it would seem).
    I’m trying to write a dockable tool window that can do full RegEx searches and replaces (the built in RegEx is over a decade old, and pretty underpowered by current regex standards) – but I have found that the only thing more complicated than getting the contents of the current editor window is refocusing the dang thing. If I assume that they aren’t in a new editor window, I can do the VCL trick, find the control and try to focus it – however, that might be the wrong editor window.
    Another example was trying to tie Jeremy North’s demo on adding to the project manager context menu with the file browser (to repoint the file browser) just left me dead in the water – there just isn’t anything "clean" or dirty that can be done here. (To make sure the file browser was available, I would probably have to crawl the menus/actionmanager and fake an onclick)
    It would be nice if someone could sit down, and made create a NEW sane, simple, straightforward revision of the OTA that did not involve code like this:
    ModuleServices := BorlandIDEServices as IOTAModuleServices;
    Module := ModuleServices.CurrentModule;
    If Not Assigned(Module) Then
    SourceEditor := Nil;
    Editor := Module.CurrentEditor;
    Editor.QueryInterface(IOTASourceEditor, SourceEditor);
    If Not Assigned(SourceEditor) Then
    For Loop := 0 to Module.ModuleFileCount-1 Do
    Editor := Module.ModuleFileEditors[Loop];
    If Editor.QueryInterface(IOTASourceEditor, SourceEditor) = S_OK then
    if Not Assigned(SourceEditor) Then
    Reader := SourceEditor.CreateReader;
    Source := ”;
    I := 10000;
    I := Reader.GetText(Length(Source),Pchar(S),I);
    Source := Source+S;
    Until (I<>10000);
    Just to get at the editor… And then there are the 3 different "addressing" modes, TOTACharPos TOTAEditPos and just an integer offset… It is just so needlessly complicated. I get that this whole thing grew organically, but maybe it is time that someone sat down, pruned it all back and cleaned it all up.

Comments are closed.