Proposal: Using unregistered objects. Removing restriction from IDE.0

From: Felix Porsch (F.Porsch_at_t-online.de)
Date: 12/20/03

  • Next message: yavuz sevgi: "Problem on CLX form design with D7" 
    Date: Sat, 20 Dec 2003 16:29:15 +0100

    In Delphi (and others) you have to register components before you can
    use them in the IDE.
    As a consequence you frequently encounter statements like this:

        procedure TMainForm.FormCreate;
          begin
            initComponentX
          end;
    or
        procedure TMainForm.ComponentXEvent;
          begin
            doSomethingComponentInternal
          end;
    or
        procedure TDataModule1.Table1FilterRecord( accept : Bolean);
          begin
            applySomeFilterOps
          end;

    Properties and procedures of the components are coded in the body of the
    form or datamodule. But what you may want to have is something like

        procedure TComponentX.Create(AOwner:TComponent);
          begin
            inherited create(AOwner);
            initComponent
          end;
        // ComponentX is an object on its own. So why help from MainForm?
    and
        procedure TComponentX.Event;
          begin
            doSomethingComponentInternal
          end;
    and
        procedure TTable1.FilterRecord( accept : Bolean);
          begin
            applySomeFilter
          end;
        // Who knows better how to filter than the table itself?

    In fact, you can do so. Here is an example:
    ------------
        unit CompDemo;

        interface

        uses SysUtils, Classes, Forms, StdCtrls;

        type

        // a tiny special component, not registered, not installed
          TStartTimeLabel = class(TLabel)
            public
              constructor create(AOwner: TComponent); override;
          end;

          TMainForm = class(TForm)
              Label1: TStartTimeLabel;
              // nothing else here
          end;

        var
          MainForm: TMainForm;

        implementation

        {$R *.dfm}

        constructor TStartTimeLabel.create(AOwner: TComponent);
          begin
            inherited create(AOwner);
            Caption:= 'Program start at ' + DateTimeToStr(now);
          end;

        end.
    -----------------

    Here is CompDemo.dfm (I made it short):
    ----------------
        object MainForm: TMainForm
          object Label1: TStartTimeLabel
          end
        end
    ----------------
    You can compile and run the application. So what is the problem?

    You can’t load the form in the IDE! The IDE does not know how to handle
    a TStartTimeLabel because it is not registered.

    Of course, you can derive a new component, register and install it in
    the IDE and use it. But this needs some extra work and care. And soon
    you will have a lot of components at the Component palette with very
    special tasks and only minor differences. Or you have to use the ugly
    method described in the section Testing Uninstalled Components.
    Therefore the code for component initialization, destruction,
    properties, and event handling is scattered in the form code or the
    datamodule code.
    In short: The IDE hinders the early birth of new components.

    My proposal is as follows:
    Introduce a new IDE directive, which indicates what substitute the IDE
    should use for an unregistered component. For example:
                    TStartTimeLabel = class(TLabel) { USE TLabel}
    As far as I can see only little changes in the IDE are necessairy to
    bring this in operation.
    Or, as a better alternative, use ‘temporarly’ registered components,
    which can grow with every compilation of the project.

    What would we get?
    First, right from the beginning we can place the new component on a
    form/datamodule and manipulate the (inherited) properties with the prop
    editor.

    But we can do even more. Suppose you have some Tables on a data module.
    At some time you notice that you have to implement special filter
    operations (onFilterRecord) on several tables. The filter operations are
    the same for all tables but the parameters are different and may change.
    At present you have to implement TableFilterRecord for every such Table
    and to hold the different filter parameters in DataModule. With the new
    option you could declare a TFilteredTable with the parameters as
    property. Than you could substitute the type of this tables by the new
    type TFilteredTable without loosing the property values of the tables
    already set!

    I can imagine that there are more situations where this feature would
    bring advantages.
    At least it simplifies the birth of new components which may later
    become ‘regular’ registered compomponents.

    felix porsch

  • Next message: yavuz sevgi: "Problem on CLX form design with D7"

    Relevant Pages

    • VIA IDE performance under 2.6.0-test7/8?
      ... Am having trouble getting decent IDE performance from the 2.6.0-test8 kernel ... BM IDE Status Register Read Retry: ... Transfer Mode: UDMA PIO PIO PIO ... # ACPI Support ...
      (Linux-Kernel)
    • [git patches] IDE updates part #1
      ... ide: ... fix register loading order when issuing packet command ... make 'extra' field in struct ide_port_info u8 ...
      (Linux-Kernel)
    • Re: Proposal: Using unregistered objects. Removing restriction from IDE.0
      ... using unregistered components in IDE would mean that IDE would have ... > You can derive a new component type and register it. ... > var Accept:Boolean); ... property FilterParam: TFilterParam read getFilterParam ...
      (borland.public.delphi.ide)
    • [git pull] IDE fixes (updated)
      ... from David Brownell and a little CodingStyle fixup. ... I also updated MAINTAINERS file to reflect conversion of the IDE tree ... MISCCTL Miscellaneous Conrol Register ...
      (Linux-Kernel)
    • [git patches] IDE fixes for 2.6.23-rc6
      ... pdc202xx_new: fix PCI refcounting ... bool "Builtin PowerMac IDE support" ... This driver provides support for the built-in IDE controller on ... This register is only writeable via I/O space. ...
      (Linux-Kernel)