Delphi 6.0 中属性编辑器的解决方案
Delphi中用户可以自己声明属性编辑器在程序设计期间对第三方控件进行设计，对属性编辑器的声明可以在注册控件的时候通过RegisterComponentEditor过程进行定义，具体为：
procedure RegisterComponentEditor(ComponentClass: TComponentClass; ComponentEditor: TComponentEditorClass);
当然，用户在注册前要定义自己的属性编辑器，下面是一个例子：
TOutlookBarEditor = class(TComponentEditor)
function GetVerb(Index: Integer): string; override;
function GetVerbCount: Integer; override ;
procedure Edit; override;
procedure ExecuteVerb(Index: Integer); override;
end;
其中最关键的部分在于对RegisterComponentEditor的引用。
在Delphi5.0中，可以直接将$(DELPHI)\Source\ToolsAPI目录下的DsgnIntf.pas文件拷贝到控件的设计目录下或者拷贝到$(DELPHI)\Lib目录即可。
在Delphi6.0中，Delphi将文件分解成DesignIntf.pas和DesignEditors.pas两个文件，所以引用时要将$(DELPHI)\Source\ToolsAPI目录下的DesignIntf.pas和DesignEditors.pas两个文件拷贝到控件的设计目录下或者拷贝到$(DELPHI)\Lib目录。
当然，如果你的Delphi Package的搜索路径或者Delphi IDE的搜索路径可以搜索到$(DELPHI)\Source\ToolsAPI目录就省去此麻烦。
但是，在Delphi 6.0中，如果就此编译，会出现找不到Proxies.dcu文件的问题。因为Proxies被编译了，在Delphi的目录中根本就找不到此相关文件，它已经被编译到designide.dcp文件中，解决方案很简单，就是在你的Package中引用designide.dcp文件即可，具体作法是：
Project－＞View Source－＞在requires部分加入对designide的引用即可。
由于此部分文件只是在设计期间才有效，所以你的Package在设计时就要注意：
不要在运行期间将在进行期间使用的文件加入对DesignIntf.pas和DesignEditors.pas两个文件的引用，否则依然会出现找不到Proxies.dcu文件的问题，要将文件脱离！
当然，如果你的Package要在Delphi 5.0及Delphi6.0下同时能运行，那就要下点功夫通过编辑器的版本进行控制，Delphi 6.0的编辑器版本是VER140，Delphi 5.0的编辑器版本是VER130，下面是本人的一个真实的引用文件：
uses
Classes, {$IFDEF VER140}DesignIntf, DesignEditors{$ELSE}DsgnIntf{$ENDIF};
Package部分由于版本不同而对不同的版本要进行不同的设计，再此就不叙述了！
其它补记：由于Delphi 5.0和Delphi 6.0对过程及参数的定义区域不同而出现错误，所以在编写两个版本的Package时一定要注意引用虚函数时出现的问题。例如对TControl控件的SetAutoSize(Value: Boolean)过程的引用：
在Delphi 5.0中定义为：
private
procedure SetAutoSize(Value: Boolean);
而在Delphi 6.0中定义为：
protected
procedure SetAutoSize(Value: Boolean); virtual;
此时的定义要根据自己的实际情况定义了，可不能随便定义了！
***************************************
Missing unit 'Proxies.pas'
Question:
If your application or expert uses designtime information, you have to replace
uses DsgnIntf;
with
uses DesignIntf, DesignEditors;
But then you will run into an error message 'Cannot find unit Proxies.pas'
Answer:
The solution is to add DesignIde.dcp to your list of required packages.
You will have to ensure that the run-time package does not require the design-time package(s). This change in Delphi 6 enforces Borland's licence restrictions on designtime editors more strongly, which have been in the license documents since Delphi 3, I believe.
visitors since Nov 21th, 2001
*********************************************
What ever happened to Proxies.pas?
Abstract:This article illustrates a scheme for properly segregating runtime code from design-time code in Delphi. By Jeff Overcash.
One frequent question since Delphi 6 shipped has concerned the disappearance of Proxies.pas from the source.
This change is part of a larger trend.
Borland chose not to ship DsgnIntf.dcu with Delphi 5, apparently to force compliance with the Delphi and C++Builder license agreements. The design-time code had been inadvertently used at runtime by many components. In some ways Borland encouraged this behavior: If you use the new component wizard you will see that this wizard creates only one unit, putting both the component skeleton code (runtime) and the Register procedure (design-time) in the same unit.
With Delphi 6, Borland has taken the next step. Not only was DsgnIntf replaced with DesignIntf, but the property editors were also pulled out into DesignEditors, DesignMenus, DesignWindows and other design-time files. DesignEditors in particular uses another IDE file named Proxies. (The Proxies code resides in DesignIDE.bpl.) Needless to say, these changes can result in errors at compile time.
If your code is already segregated in terms of runtime versus design-time then the fix is very simple. Open up your design-time package, select the requires folder and hit the Add button. Type designide.dcp and hit OK. Recompile your package and the error should go away.
But how can this problem be fixed when design-time and runtime code has been mixed together? DesignIDE.bpl is not a redistributable package in Delphi. So even in situations where the "design-time only" package has the component's runtime code and only the component dcu is used, there can still be a problem.
In 99.99% of the cases this is actually very easy to fix. Your runtime code isn't actually using the design-time code; things just are not properly segregated. The segregation lines are fairly simple, however.
The design-time package should include:
All registration statements.
All property editors.
All Component editors.
Should require DesignIDE and each runtime package that holds the components themselves.
The runtime package should include:
The components themselves only.
Optionally, any forms the editors may use IF the component can call the form itself at runtime
The only place where there is a little confusion is if the property/component editor uses a form. If that form is available at runtime to the component, it belongs in the runtime package. If it is only available at design-time, it goes in the design-time package. A very common misperception is that the form itself is the editor, but it is not. It is the component editor that calls the form that is the design-time editor.
You should get in the habit of always separating your components into two packages even if you only statically link your application, because mixing design-time and runtime code leads to code bloat. Your design-time code can't be executed in the runtime, but the linker doesn't know that so it links it in anyway. (This is why DsgnIntf is trying to get linked in.)
Let's walk though a very simple component to see how to break the design-time code from the runtime:
{ TMixedComponent }
TMixedComponent = class(TComponent)
private
FFileName: String;
published
property FileName : String read FFileName write FFileName;
{ Published declarations }
end;
{ TMixedFileNameProperty }
TMixedFileNameProperty = class(TPropertyEditor)
function AllEqual: boolean; override;
procedure Edit; override;
function GetAttributes: TPropertyAttributes; override;
function GetValue: string; override;
procedure SetValue (const Value: string); override;
end;
procedure Register;
implementation
procedure Register;
begin
RegisterPropertyEditor(TypeInfo(string), TMixedComponent, 'FileName', TMixedFileNameProperty);
RegisterComponents('Samples', [TMixedComponent]);
end;
function TMixedFileNameProperty.AllEqual: boolean;
var
FirstVal: string;
i: Integer;
begin
FirstVal := GetStrValue;
Result := True;
i := 1;
while Result and (i < PropCount) do
begin
Result := Result and (GetStrValueAt(i) = FirstVal);
Inc(i);
end;
end;
procedure TMixedFileNameProperty.Edit;
var
Dlg: TOpenDialog;
begin
Dlg := TOpenDialog.Create(Application);
try
with Dlg do
begin
Title := 'File for ' + TComponent(GetComponent(0)).Name;
FileName:= Value;
if Execute then Value := FileName;
end;
finally
FreeAndNil(Dlg);
end
end;
function TMixedFileNameProperty.GetAttributes: TPropertyAttributes;
begin
Result := [paDialog]
end;
function TMixedFileNameProperty.GetValue: string;
begin
Result := GetStrValue;
end;
procedure TMixedFileNameProperty.SetValue(const Value: string);
begin
SetStrValue(Value);
end;
end.
The easiest way to segregate the design-time code from runtime code is to take all the code that requires DesignIntf and DesignEditors and put it in its own unit. That unit will need to use the component's unit. The component itself does not have need to know about the IDE editors that will work with it. So for a start, remove the design-time units DesignIntf and DesignEditors from the uses clause component unit and let the compiler/linker tell you which classes need to be moved into their own unit:
[Error] MixedComponent.pas(23): Undeclared identifier: 'TPropertyEditor'
[Error] MixedComponent.pas(23): Class type required
[Error] MixedComponent.pas(24): Method 'AllEqual' not found in base class
[Error] MixedComponent.pas(25): Method 'Edit' not found in base class
[Error] MixedComponent.pas(26): Undeclared identifier: 'TPropertyAttributes'
[Error] MixedComponent.pas(27): Method 'GetValue' not found in base class
[Error] MixedComponent.pas(28): Method 'SetValue' not found in base class
[Error] MixedComponent.pas(35): Undeclared identifier: 'RegisterPropertyEditor'
[Error] MixedComponent.pas(35): Undeclared identifier: 'TMixedFile'
[Error] MixedComponent.pas(46): Undeclared identifier: 'GetStrValue'
[Error] MixedComponent.pas(49): Undeclared identifier: 'PropCount'
[Error] MixedComponent.pas(51): Undeclared identifier: 'GetStrValueAt'
[Error] MixedComponent.pas(51): Operator not applicable to this operand type
[Error] MixedComponent.pas(64): Undeclared identifier: 'GetComponent'
[Error] MixedComponent.pas(65): Undeclared identifier: 'Value'
[Error] MixedComponent.pas(75): Undeclared identifier: 'paDialog'
[Error] MixedComponent.pas(80): Undeclared identifier: 'GetStrValue'
[Error] MixedComponent.pas(85): Undeclared identifier: 'SetStrValue'
[Fatal Error] JOComponents.dpk(33): Could not compile used unit 'MixedComponent.pas'
The next step is to create a new unit to hold the design-time code. Name it something like MixedComponentReg. Move the Register procedure over to that unit. Now start going through the error messages and start evaluating them. The first error, [Error] MixedComponent.pas(23): Undeclared identifier: 'TPropertyEditor', indicates that the whole class inherits from something in one of the design-time units we removed. This is a clear indication that this is only design-time code and the whole class needs to be moved over to the newly created unit.
At this point the runtime package now compiles cleanly (if not, keep pulling design-time code out until it compiles cleanly without errors). Now there is no need for Proxies.pas or any other design-time units for the component to work in your application at runtime. The runtime component unit is much simplified. It looks like this:
unit MixedComponent;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs;
type
{ TMixedComponent }
TMixedComponent = class(TComponent)
private
FFileName: String;
published
property FileName : String read FFileName write FFileName;
{ Published declarations }
end;
implementation
end.
The final step is to get the component and its property editors compiled into a design-time package and installed into the IDE.
Create a new package by doing File | New | Other and select package. Bring up the packages options and select design-time only. Give a descriptive name in the Description field. Select the Requires folder and hit the Add button. In the Requires Package edit box type Designide.dcp and hit OK. Also add the dcp for the runtime package that the component resides in. In this case it was put it in JOComponents.dpk, so JOComponents.dcp is added to the requires section. The requires section has three items: JOComponents, designide and rtl. Finally, select the Contains folder and add MixedComponentReg.pas to the package.
We're almost done!
Open up MixedComponentReg.pas to add a couple of units in the uses section. Which section depends on whether your component or property editor uses the component in its declaration (more complicated editors sometimes need knowledge of the component). If it does, then add it to the Interface uses clause. If not, put it in the implementation uses. In our example we don't need the information so MixedComponent goes in the implementation uses clause. DesignIntf and DesignEditors belong in the Interface uses. SysUtils, Forms, Dialogs, and Classes are all used internally in different ways in the property editor, so they belong in the implementation section. The final MixedComponentReg looks like this:
unit MixedComponentReg;
interface
uses DesignIntf, DesignEditors;
type
{ TMixedFileNameProperty }
TMixedFileNameProperty = class(TPropertyEditor)
function AllEqual: boolean; override;
procedure Edit; override;
function GetAttributes: TPropertyAttributes; override;
function GetValue: string; override;
procedure SetValue (const Value: string); override;
end;
procedure Register;
implementation
uses MixedComponent, SysUtils, Forms, Dialogs, Classes;
procedure Register;
begin
RegisterPropertyEditor(TypeInfo(string), TMixedComponent, 'FileName', TMixedFileNameProperty);
RegisterComponents('Samples', [TMixedComponent]);
end;
function TMixedFileNameProperty.AllEqual: boolean;
var
FirstVal: string;
i: Integer;
begin
FirstVal := GetStrValue;
Result := True;
i := 1;
while Result and (i < PropCount) do
begin
Result := Result and (GetStrValueAt(i) = FirstVal);
Inc(i);
end;
end;
procedure TMixedFileNameProperty.Edit;
var
Dlg: TOpenDialog;
begin
Dlg := TOpenDialog.Create(Application);
try
with Dlg do
begin
Title := 'File for ' + TComponent(GetComponent(0)).Name;
FileName:= Value;
if Execute then Value := FileName;
end;
finally
FreeAndNil(Dlg);
end
end;
function TMixedFileNameProperty.GetAttributes: TPropertyAttributes;
begin
Result := [paDialog]
end;
function TMixedFileNameProperty.GetValue: string;
begin
Result := GetStrValue;
end;
procedure TMixedFileNameProperty.SetValue(const Value: string);
begin
SetStrValue(Value);
end;
end.
All that is left is to compile and install the design-time package.
The runtime code is now completely segregated from the design-time code.
While this is a fairly simple example, the only time it gets a little more complicated is when the property editor uses a form to retrieve the data, and that form is also available at runtime. In those cases the form stays in the runtime package, and the design-time property editor will call that form from the runtime package.
If you get in the habit of always having a runtime package for the components and a design-time package for the registration and editors, you won't have any more problems, even if you only intend to statically link in the DCUs.
By Jeff Overcash (TeamB).
--------------------------------------------------------------------------------
Add or View comments on this article
NOTE: The views and information expressed in this document represent those of its author(s) who are solely responsible for its content. Borland does not make or give any representation or warranty with respect to such content.
Article ID: 27717 Publish Date: October 19, 2001 Last Modified: October 19, 2001