One thing first. I am calling it FormEditor. IS that OK? Everyone is referring to it as FormDesigner....
Second: I was thinking that the Set/Get methods for the TComponentInterface would be used by the Object Inspector and the FormEditor.
When someone changed something in the OI they could then call the Set method for the TICOmponentInterface and it would change it. Otherwise how does the FormEditor know what changed? Where would the OI store what was changed? It would need to set the new value to the property wouldn't it?
Shane
Show quoted text 6 lines
>> 11/20/00 04:53AM >>>
Can you explain to me what the functions.....
procedure FormDesigner.GetMethods(TypeData: PTypeData; Proc: TGetStrProc);
procedure FormDesigner.GetComponents(TypeData: PTypeData; Proc:
TGetStrProc);
This is my idea:
GetMethods is used, when the combobox of a Method-Property is filled with all valid Method names.
GetComponents is used, when the comboboc of a Component-Property is filled with all valid Property names.
TypeData:
PTypeData is defined in TypeInfo and describes the method/component type.
Proc:
TGetStrProc = procedure(const S: string) of object;
Proc: TGetStrProc is for example the Add procedure of a TStrings instance.
To implement the two functions you must compare every (published) property of the form with the TypeData. I'm not yet an expert in RTTI, so I don't know, if there already exists a function that can say if two types are compatible.
Show quoted text 9 lines
The FormEditor class is the class that controls the FORM
and keeps a list of selected controsl on that form.
It will return a TComponentInterface to you for each control
on the form. The TComponentInterface can Set/Get property
values (by name and index), return the component type,
return an TComponentInterface for it's parent, Focus
the control, Delete the control, Selects the control
(and tells the object inspector), etc.
How's that all sound?
That sounds, as if lazarus is getting better. :)
(Florian Klaempfl has mentioned it):
The components can be remote controlled by the RTTI. Every Control on the form is owned by the form itself and can be found via the form.Components property. The Property Editors read and write values with the RTTI. So, I think, we don't need the Set/Get property in the TComponentInterface. As far as I can see, the OI needs in the form designer only select, unselect, delete and add procedures and a RootComponent and Modified property.
If the user changes some values on the form designer itself (e.g. moving, resizing a component) the form designer executes the UpdatePropertyValues in the Object Inspector, and the OI will show all changed values. If the selection changes in the formdesigner, the formdesigner sets the "property Selections:TSelectedComponentList;" in the Object Inspector: ObjInspec.Selections:=FormDesigner.Selections;
Then the OI will destroy its old list, sets the new list, builds the intersection of all selected components and shows the properties.
The TSelectedComponentList is a simple pointer list:
TSelectedComponentList = class
private
FComponents:TList;
function GetItems(Index: integer): TComponent;
procedure SetItems(Index: integer; const Value: TComponent);
function GetCount: integer;
public
procedure Clear;
property Count:integer read GetCount;
function Add(c:TComponent):integer;
procedure Delete(Index:integer);
property Items[Index:integer]:TComponent read GetItems write SetItems;
default;
constructor Create;
destructor Destroy; override;
end;
There is yet another point. The formdesigner should have an Modified property, that the ObjectInspector sets if something has changed. Thus, the formdesigner knows, if the lfm file must be stored.
These are only my personal ideas. I think, they are very similar to Delphi. But is Delphi always the best?
What do you think?
Mattias
_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus
