Custom component has no name (again)

Last try here.

If you have ever bought one of those 40 pound volumes "Delphi Developer's
Guide" by Teixeira and Pacheco (Delphi 4,5,6) you can find the source for
this in the chapter on creating custom components. This is what they call
a "container component". Decending from TCustomControl (or TWinControl, I
tried both), it has an edit box and a button. Not complicated stuff.

Three questions.

1. Why do they free the edit control and the button in the destructor? If
these "contained components" are created with Owner=self, where is the
need to free them?

2. The component works fine. Assume it is named FOO, either in the
designer or in code. The normal way of naming components. Then the test
"if ActiveControl=FOO" always fails. I can see the name property is not
set. Yet it has a name and the IDE handles it fine.

This is a head-scratcher for me. Complete failure to understand something
very basic.

3. This is my third try in this forum. So I am not phrasing the question
well, or I am asking in the wrong place. Yet when I google for component
writing groups or forums, all I can find is dead links. Is anyone aware of
group that is active, with help for basic component writing?

I found a professional outfit willing to try and answer for some big
bucks. I must go with them unless I can find help here.

Thanks in advance.

=========================================================
unit imMyControl;
{
Simple test 'container component' appears to work but
fails to have a name property (or otherwise be detected as ActiveControl).
}
interface

uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
StdCtrls, Buttons,Mask;

type

//=========================================
{ Later we will want to tweak keystroke handling for masked edits.
}
//TImsCustomMaskEdit = class(TCustomMaskEdit)
//end;

//=========================================
{ Base class
}
TImsCustomMyControl = class(TWinControl)
constructor Create(AOwner: TComponent); override;
destructor Destroy; override;

private
FEdit:TEdit;
FSpeedButton: TSpeedButton;

procedure ButtonClick(Sender:TObject);
function GetText:string;
procedure SetText(Value:string);

protected
procedure WMSize(var Message: TWMSize); message WM_SIZE;

public
procedure SetFocus;override;
property Text:string read GetText write SetText;
end;

//=========================================
{ Lookup control
}
TImsMyControl = class(TImsCustomMyControl)
published
property Align;
property Enabled;
property Font;
property OnEnter;
property OnExit;
property Text;
property TabOrder;
property TabStop;
property Visible;
end;

procedure Register;

implementation

procedure Register;
begin
RegisterComponents('TEST', [TImsMyControl]);
end;

//==============================================================================
{
}
constructor TImsCustomMyControl.Create(AOwner: TComponent);
begin
inherited Create(AOwner);

// An edit contro
FEdit:=TEdit.Create(self);
FEdit.Parent:=self;
FEdit.Height:=21;

// A button
FSpeedButton := TSpeedButton.Create(Self);
FSpeedButton.Left := Width;
FSpeedButton.Height := 19; // two less than TEdit's Height
FSpeedButton.Width := 19;
FSpeedButton.Caption := 'F';
FSpeedButton.Parent := Self;
FSpeedButton.OnClick := ButtonClick;//MyDropDown;

Width := Width+FSpeedButton.Width;
Height := FEdit.Height;
end;

destructor TImsCustomMyControl.Destroy;
begin
// Curious. Why free these? Are not owned components to be freed
automagically?
FEdit.Free;
FSpeedButton.Free;
inherited Destroy;
end;

{ Maintain edit control and button in their respective places
}
procedure TImsCustomMyControl.WMSize(var Message: TWMSize);
begin
inherited;
FEdit.Width := Message.Width-FSpeedButton.Width;
FSpeedButton.Left := FEdit.Width;
end;

//==============================================================================
{ Delegate to edit control
}
function TImsCustomMyControl.GetText:string;
begin
Result:=FEdit.Text;
end;
procedure TImsCustomMyControl.SetText(Value:string);
begin
FEdit.Text:=Value;
end;
procedure TImsCustomMyControl.SetFocus;
begin
FEdit.SetFocus;
end;

//==============================================================================
{
}
procedure TImsCustomMyControl.ButtonClick(Sender:TObject);
begin
FEdit.SetFocus;
ShowMessage('click');
end;

{ -Compile and install.
-Drop one on a new form. Compile and run.
-Try to report the name of the control, or test for it when it is
ActiveControl!
}
end.

Messages in this topic (1) Reply (via web post) | Start a new topic

.

steward%40manscat.com">stewardmanscat.com wrote:
> 2. The component works fine. Assume it is named FOO, either in the
> designer or in code. The normal way of naming components. Then the test
>; "if ActiveControl=FOO" always fails. I can see the name property is not
> set. Yet it has a name and the IDE handles it fine.

The active control is not the container. The active control is one of
the contained controls, which you didn't name.

One of your own experiments revealed that. When you exposed the Name
property of one of the contained controls as a property of the
container, you saw that ActiveControl.Name matched the value you
assigned to the container's new property.

I thought you noticed that; that's why I stopped paying attention before.

> 3. This is my third try in this forum. So I am not phrasing the question
> well, or I am asking in the wrong place. Yet when I google for component
> writing groups or forums, all I can find is dead links. Is anyone aware of
> group that is active, with help for basic component writing?

Have you tried borland.public.delphi.vcl.components.writing.win32?

--
Rob

Messages in this topic (0) Reply (via web post) | Start a new topic

.

When self is the owner, it is responsible for freeing itself.
It's the same concept as when you create a form at runtime:

Form1 := Tform.create(self);
Form1.Showmodal;
Form1.Free;
Form1 := nil;

If the component was owned by something else, then you wouldn't have to worry about it, the owner would free it. This is also analagous to when you create a
secondary form owned by mainform:

Form1 := TForm.create(mainform);
Form1.showmodal;
//don't free it, mainform will free it when it shuts down.

Not freeing it would produce a memory leak.

Dave

steward%40manscat.com">stewardmanscat.com wrote: Last try here.

If you have ever bought one of those 40 pound volumes "Delphi Developer's
Guide"; by Teixeira and Pacheco (Delphi 4,5,6) you can find the source for
this in the chapter on creating custom components. This is what they call
a "container component". Decending from TCustomControl (or TWinControl, I
tried both), it has an edit box and a button. Not complicated stuff.

Three questions.

1. Why do they free the edit control and the button in the destructor? If
these "contained components" are created with Owner=self, where is the
need to free them?

2. The component works fine. Assume it is named FOO, either in the
designer or in code. The normal way of naming components. Then the test
"if ActiveControl=FOO" always fails. I can see the name property is not
set. Yet it has a name and the IDE handles it fine.

This is a head-scratcher for me. Complete failure to understand something
very basic.

3. This is my third try in this forum. So I am not phrasing the question
well, or I am asking in the wrong place. Yet when I google for component
writing groups or forums, all I can find is dead links. Is anyone aware of
group that is active, with help for basic component writing?

I found a professional outfit willing to try and answer for some big
bucks. I must go with them unless I can find help here.

Thanks in advance.

=========================================================
unit imMyControl;
{
Simple test 'container component' appears to work but
fails to have a name property (or otherwise be detected as ActiveControl).
}
interface

uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
StdCtrls, Buttons,Mask;

type

//=========================================
{ Later we will want to tweak keystroke handling for masked edits.
}
//TImsCustomMaskEdit = class(TCustomMaskEdit)
//end;

//=========================================
{ Base class
}
TImsCustomMyControl = class(TWinControl)
constructor Create(AOwner: TComponent); override;
destructor Destroy; override;

private
FEdit:TEdit;
FSpeedButton: TSpeedButton;

procedure ButtonClick(Sender:TObject);
function GetText:string;
procedure SetText(Value:string);

protected
procedure WMSize(var Message: TWMSize); message WM_SIZE;

public
procedure SetFocus;override;
property Text:string read GetText write SetText;
end;

//=========================================
{ Lookup control
}
TImsMyControl = class(TImsCustomMyControl)
published
property Align;
property Enabled;
property Font;
property OnEnter;
property OnExit;
property Text;
property TabOrder;
property TabStop;
property Visible;
end;

procedure Register;

implementation

procedure Register;
begin
RegisterComponents('TEST', [TImsMyControl]);
end;

//==============================================================================
{
}
constructor TImsCustomMyControl.Create(AOwner: TComponent);
begin
inherited Create(AOwner);

// An edit contro
FEdit:=TEdit.Create(self);
FEdit.Parent:=self;
FEdit.Height:=21;

// A button
FSpeedButton := TSpeedButton.Create(Self);
FSpeedButton.Left := Width;
FSpeedButton.Height := 19; // two less than TEdit's Height
FSpeedButton.Width := 19;
FSpeedButton.Caption := 'F';
FSpeedButton.Parent := Self;
FSpeedButton.OnClick := ButtonClick;//MyDropDown;

Width := Width+FSpeedButton.Width;
Height := FEdit.Height;
end;

destructor TImsCustomMyControl.Destroy;
begin
// Curious. Why free these? Are not owned components to be freed
automagically?
FEdit.Free;
FSpeedButton.Free;
inherited Destroy;
end;

{ Maintain edit control and button in their respective places
}
procedure TImsCustomMyControl.WMSize(var Message: TWMSize);
begin
inherited;
FEdit.Width := Message.Width-FSpeedButton.Width;
FSpeedButton.Left := FEdit.Width;
end;

//==============================================================================
{ Delegate to edit control
}
function TImsCustomMyControl.GetText:string;
begin
Result:=FEdit.Text;
end;
procedure TImsCustomMyControl.SetText(Value:string);
begin
FEdit.Text:=Value;
end;
procedure TImsCustomMyControl.SetFocus;
begin
FEdit.SetFocus;
end;

//==============================================================================
{
}
procedure TImsCustomMyControl.ButtonClick(Sender:TObject);
begin
FEdit.SetFocus;
ShowMessage('click');
end;

{ -Compile and install.
-Drop one on a new form. Compile and run.
-Try to report the name of the control, or test for it when it is
ActiveControl!
}
end.





---------------------------------
Boardwalk for $500? In 2007? Ha!
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.

[Non-text portions of this message have been removed]

Messages in this topic (0) Reply (via web post) | Start a new topic

.

Delphi 5
Have existing (legacy-don't-blame-me) app with 100+ packages.

Want to create a new version.
-Change output paths, search paths, compiler options.
-Change location of source files

Big job!

1. Any tools out there which will help? Simple search and replace in
DOF/CFG/DPK files seems to be perilous.

2. Any other approach, apart from doing each package by hand?

PS: We use all approaches: compile within IDE, compile using batch file,
final compile with VisualBuildPro. So all files (DOF/CFG/DPK) need to be
updated.

===

To avoid this in future, all paths should be relative. We can aim for
this, but in practice it becomes difficult. Since Delphi wants to include
full path information automagically, it's a constant battle to check and
see if Delphi has "de-relatived" parts of the project.

Another solution might be to leave the search and output paths blank for
all packages, then rely on the global setting under the tools menu.

...but then we'd want a fast way to switch those settings (I assume they
are stored in the registry).

===

Just wondered what other people were doing to cope with this kind of issue...

Many thanks in advance.

Messages in this topic (0) Reply (via web post) | Start a new topic

.