In previous versions of Delphi, my custom Form showed its published properties.
However, I'm running into an issue with Delphi 10.2 Tokyo. Specifically, I'm not seeing a good way to call the appropriate method found in this post.
To sum it up, a call to RegisterCustomModule() is needed, however, in the DesignIntf unit described here, there is no TCustomModule (there is TBaseCustomModule and TCustomModuleClass, though), also the base custom module inherits from TInterfacedObject, which TForm does not (using FMX as my framework).
What is the correct method for registering a FMX Form to show published properties in the latest version of Delphi?
uses DesignEditors;
type
TMySpecialForm = class(TCustomForm)
end;
RegisterCustomModule(TMySpecialForm, TCustomModule);
RegisterCustomModule takes 2 parameters: ComponentBaseClass and CustomModuleClass. The first is your custom form class, which will, of course, be derived from TCustomForm. The second is a class that will be used by the designer. This class must do 2 things: derive from TBaseCustomModule (in DesignIntf unit) and implement the ICustomModule interface. Take a look at the comment in the DesignEditors unit, around line 502.
The TCustomModule class is provided for you to use if you have no behavior other than the default to add to your custom form at design time.
If you do want some kind of custom behavior for your form while in the designer, say, a pop-up menu with various property-setting commands, you would create your own TCustomModule class:
uses DesignEditors;
type
TMySpecialFormDesigner = class(TCustomModule, ICustomModule)
function GetVerb(Index: Integer): string; override;
function GetVerbCount: Integer; override;
end;
RegisterCustomModule(TMySpecialForm, TMySpecialFormDesigner);
Related
I built a wrapper around the TWebBrowser in Delphi. The wrapper aims at implementing multiple web browsers (edge chromium, chrome etc) into a single wrapper that auto detects which browser to use.
After I completed the class I turned said class into a VCL component and loaded it into a design time package. My component includes only two files, the wrapper itself and a utilities class. When I drag my component from the tools palette onto a VCL form the wrapper and the utilities class are not added automatically to the project. This means I have to manually include both the wrapper and the utility into the project.
I was hoping there was a way to automatically include these two files into the project when the wrapper is added to the form. I think I have seen this before with other third party components I have used but my memory may be failing me.
If this is a thing that can be done, my assumption is that it would be in the register section of the VCL component.
procedure Register;
begin
RegisterComponents('My Wrappers', [TWebBrowserWrapper]);
end;
As that is the code that I believe is run when in design time.
Have your design-time package implement a class that inherits from TSelectionEditor and overrides its virtual RequiresUnits() method, and then register that class for your component using RegisterSelectionEditor(). This way, whenever you place your component onto a Form/Frame/DataModule Designer at design-time, any additional units you report from RequiresUnits() will be added automatically to that unit's uses clause when the unit is saved.
For example:
uses
..., DesignIntf;
type
TWebBrowserWrapperSelectionEditor = class(TSelectionEditor)
public
procedure RequiresUnits(Proc: TGetStrProc); override;
end;
procedure TWebBrowserWrapperSelectionEditor.RequiresUnits(Proc: TGetStrProc);
begin
inherited RequiresUnits(Proc);
// call Proc() for each additional unit you want added...
Proc('MyWrapperUnit');
Proc('MyUtilityUnit');
end;
procedure Register;
begin
RegisterComponents('My Wrappers', [TWebBrowserWrapper]);
RegisterSelectionEditor(TWebBrowserWrapper, TWebBrowserWrapperSelectionEditor);
end;
I have extended the TForm in a separate unit...
TForm = class(Forms.TForm)
protected
{ convenient extensions }
public
{ more extensions }
end;
And this unit (with the extended TForm) is declared in all units of the Forms to which I want to apply these extensions...
However, in some of these units have the following code snippets:
Initialization
RegisterClass(TFormN);
Finalization
UnRegisterClass(TFormN);
But this way I get the message [EFilerError] 'A class named TForm already exists'
I spent the last few days looking for a way to solve / work around this conflict, but without success ...
Has anyone experienced this ...? Or can shed light on why this problem ...?
The problem is that I already have implemented this unit, with the extended form, in 2 projects - successfully...
Just now, in the third project, the form classes are called without being instanciated... and I can't change the extended class form from:
TForm = class(Forms.TForm)
to:
TStyleForm = class(Forms.TForm)
...
What I'd need is something like:
TFormStyle = class(Forms.TForm)
public
constructor Create(AOwner: TComponent); override;
end;
TForm = ^TFormStyle;
But in the units I can't do a declaration like:
TMyForm = class(TForm)
{ something... }
end;
Cause now it's a pointer...
You now have two distinct types in your program, both with the name TForm. The one declared in the VCL is registered with the name TForm. Since you are trying to register your TForm with the global registry, using the same name as the VCL version, the registration naturally fails.
Some possible ways forward:
Rename your form to avoid the clash.
Don't register your class at all. You don't need to register forms since they are not instantiated by the streaming framework. You instantiate them by providing a meta class. Either to Application.CreateForm, or by a standard constructor TForm.Create. You'd need to make sure that you always listed the unit that declared your TForm after Forms in any uses clauses. Or use a fully scoped type like MyForms.TForm.
If you used a later version of Delphi you could add your extensions using a class helper.
Personally I'd be inclined to do both 1 and 2 above.
Note that I am assuming that your intent is that your TForm is used for all your forms rather than Forms.TForm.
Is there a way to create forms dynamically by only their names;
The concept goes like this. I have a main form, and by some user selection, a number of predefined forms must be created and docked on tabitems on a pagecontols on the main form.
I do know the names of the forms and i do know when to create each one of those, but i would like to know if a better way of creating these forms by a single procedure call, and not having all of these information in my code.
Its Delphi XE3 firemonkey, on win 7.
Thanks in advance for any help
Apparently on Firemonkey Delphi doesn't automatically register form classes to be available by name, so you'll first need to add something like this to the end of the unit that holds your form class:
unit Form10;
[ ... ]
// Right before the final "end."
initialization
RegisterFmxClasses([TForm10]);
end.
This will automatically register TForm10 so it'll be available by name. Next you can use this kind of code to create a form at Runtime by it's class name:
procedure TForm10.Button1Click(Sender: TObject);
var ObjClass: TFmxObjectClass;
NewForm: TCustomForm;
begin
ObjClass := TFmxObjectClass(GetClass(ClassName));
if ObjClass <> nil then
begin
NewForm := ObjClass.Create(Self) as TCustomForm;
if Assigned(NewForm) then
NewForm.Show;
end
end;
You can only create objects when you have a class reference for it. To get a class reference for something given its string name, call FindClass. Call the constructor on the result. You may have to type-cast the result to a different metaclass before the compiler will allow you to access the constructor you want. In the VCL, you might use TFormClass, but plain old TComponentClass will work, too, since all FireMonkey objects are descendants of TComponent; the important part is that you have access to the right constructor, and that's where the one you need is introduced.
It only works for classes that have been registered. Your form classes should be registered by Delphi automatically, but if they're not, you can call RegisterClasses manually, or RegisterFmxClasses if you need to put your classes in groups.
Delphi.About.com has a VCL demonstration.
I have some business objects written in Delphi with a custom scheme of database persistence which is finally working for my needs. Ok, great. Now it's time for GUI implementations. And here begins the problems.
How to bind my object to the GUI properly?
I cannot use Data Aware controls since I isolated all data access components into the ORM layer, so I start to write some "Object Aware" controls using the RTTI unit (I'm working with Delphi 2010), but I have the feeling I'm going the wrong way...
Some ideas on how to resolve this using only the VCL controls?
You have several patterns for linking ORM with User Interface.
See for instance the Model GUI Mediator pattern. In short, you write an observer which will reflect the ORM content into the UI components, and vice versa. This has been implemented for instance in the tiOpf framework for Delphi (this link has videos).
Another approach is to map your data at runtime: you design your form just like usual, then you fill the content in the OnShow event, then the "Save" or "OK" button will validate then save the content into the ORM record. This is what is done in the main Sample application of our framework. Easy to code in this simple sample, but could lead into spaghetti code if you have a lot of fields and validation to operate.
The last approach is to let your ORM creates the form.
In our framework, you can define some UI properties about each table, in a dedicated structure. Then a single unit will create a form with all editable fields of your ORM object. Links to other records will be displayed as a combo box, booleans as checkboxes, sets as radioboxes, and so on. Then the filtering (e.g. trim a text field from spaces on left or right side) and the validation (e.g. ensure that a field value is unique or a valid IP address) is handled not in the UI part, but in the business logic itself, i.e. the ORM.
IMHO it's mandatory to keep a true multi-tier architecture. That is, the UI has to rely mostly on the business logic. For instance, data validation must be part of the ORM, not of the UI. For instance, if you decide to add a web client to your Delphi client application, you won't have to code the validation another time: it will be common to both clients, separated from the UI implementation details.
What you could do (though I have no code samples) is use a combination of
class helpers or interceptor classes
binding interfaces for single domain objects and/or domain object lists
Class helpers have the disadvantage that they are not officially supported and you cannot add any fields to the class you are helping.
Interceptor classes are simply descendant classes with the same name as their ancestor:
uses
stdctrls;
type
TButton = class(stdctrls.TButton)
end;
You can put interceptor classes in their own unit and use that whereever you want. Just make sure these units are included AFTER the standard unit, so your descendant is used at run time.
Benefit of interceptor classes:
You can continue to design your UI using standard VCL or third party controls.
You get all the advantages of descendants.
You do not need to create or install your own controls.
No need for special mapper classes or use of RTTI.
Easily (well, relatively easily) integrated into a (DUnit-) testable user interface along the lines of Julian Bucknall's article on this in the (distinct) Delphi Magazine as referred to in this question/answer: Unit-testing mouse event handlers
Pseudo sample of interceptor control with binding interface / command interface:
uses
stdctrls;
type
ICommandAction = interface(IInterface)
function IsEnabled: Boolean;
procedure Execute;
procedure Update;
end;
IBindSingle = interface(IInterface)
function GetValueFromControl: string;
procedure LoadValueIntoControl(const aValue: string);
end;
TButton = class(stdctrls.TButton, ICommandAction)
protected
function IsEnabled: Boolean;
procedure Execute;
procedure Update;
end;
TEdit = class(stdctrls.TEdit, IBindSingle)
function GetValueFromControl: string;
procedure LoadValueIntoControl(const aValue: string);
end;
implementation could be along the lines of:
function TButton.IsEnabled: Boolean;
begin
Result := Self.Enabled;
end;
procedure TButton.Execute;
begin
Self.Action.Execute;
end;
procedure TButton.Update;
begin
Self.Action.Update;
end;
function TEdit.GetValueFromControl: string;
begin
Result := Self.Text;
end;
procedure LoadValueIntoControl(const aValue: string);
begin
Self.Text := aValue;
end;
My current customer have made their own "mapper" classes in the past (before I came).
Their data objects have fields (which are objects), and you can map these fields to a control. I extended the framework by using a MVC-like approach:
edtTarraCode: TAdvEdit;
procedure TframTarraTab.InitMapping;
begin
...
Mapper.AddMapping(edtTarraCode, Controller.DataModel.tarID);
...
end;
Per control a simple "mapping" class is created:
TMappingAdvEdit = class(TBaseEditMapping)
protected
procedure InitControl; override;
procedure AppData2Control; override;
procedure Control2AppData; override;
end;
No rocket sience, and maybe better solutions are available in the mean time (this worked in D6 and lower :-) ) but it works good enough for the customer.
Btw: also a data object generator is used. So if a field changes in the database (for example tarra.tarid is changed into tareID) we get a compiler error because "tarid" does not longer exist. This works much better than "fixed string" mapping (runtime errors).
There's currently no way to do this using only VCL controls. I know that Lazarus has a set of RTTI-based data-aware controls; you might want to look at them for some basic ideas. But it's more difficult than you might think at first. For example, unlike a dataset, an object has no built-in signaling mechanism when its members' values change. Which means that unless your data-binding controls own the object completely and nothing else has access to it, it's possible for some other code to change some value and then that change doesn't get reflected in the UI.
I've heard various things from the Delphi team in the last few years about extending the object model or the RTTI model to allow for better data binding, but whatever that's about is still a few years out.
Take a look at EverClassy Dataset at http://www.inovativa.com.br. It may meet your needs. EverClassy Dataset is a Delphi dataset designed to be populated by objects instead records from a database system.
With this component you will have the chance to interoperate your domain objects with dataware componentes, what will give you great power to build your GUI.
After much searching, it looks like I have to assign RegisterComponentsProc and RegisterPropertyEditorProc, which I have done.
However, I thought that I could call my design time Register function, i.e. <myComponentUnit>.Register();.
When I do I get stack overflow, because, well ...
procedure myComponentUnit.Regiter;
begin
RegisterPropertyEditor(TypeInfo(Integer),
TMyComponent, 'myProperty', TMyProperty);
end;
procedure RegisterPropertyEditor(PropertyType: PTypeInfo;
ComponentClass: TClass; const PropertyName: string;
EditorClass: TPropertyEditorClass);
begin
if Assigned(RegisterPropertyEditorProc) then
RegisterPropertyEditorProc(PropertyType, ComponentClass, PropertyName,
EditorClass);
end;
So, I call .Register();
which calls RegisterPropertyEditor()
which call RegisterPropertyEditorProc()
which calls RegisterPropertyEditor() <=== aaargh!!
So, what should I have in the body of my RegisterPropertyEditorProc ?
After further searching, it looks like I want to call DesignEditors.RegisterPropertyEditor() directly, but it is not in the interface section ...
There is no point in trying to register a property editor at run-time, as it is not usable at run-time to begin with. It is only usable within the IDE during design-time.
Delphi does not include the source for the DesignEditors unit; its implementation is provided solely in the DesignIDE package. That package has access to IDE internals, such as the list of registered property editors. The IDE assigns values to the RegisterComponentsProc and RegisterPropertyEditorProc callback functions. As you noticed, RegisterPropertyEditor calls RegisterPropertyEditorProc. The IDE provides its own function to handle that event.
If you want to register a property editor at run time, then your program plays the role of the IDE. You need to provide implementations for those callback functions to register the property-editor classes with your own property-editing framework. You could probably just keep everything in a simple list. Then, when you want to know what kind of editor to display for a certain type of property, consult the list to find the best match.
You're correct that you should call your units' Register procedures. But that's how you initiate the registration process, not how you implement it. That part's up to you; Delphi doesn't provide any of this for you.