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;
Related
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);
I am trying to write a component which is loading 3D objects from obj files.
I am using ToolsAPI library for GetActiveProject.FileName. I added designide.dcp to Requiers part in the bpl. I registered my object and in design when I put an instance of this object on a TViewPort3D which I put before everything is OK and I can see the object from the obj file is loaded in the scene, but when I try to compile the project I get an error that says ToolsAPI.dcu not found.
The procedure that I use for loading the obj file is (Type of Model variable is TModel3D) :
procedure TMyObject.LoadModel(fileName: string);
begin
if(csDesigning in ComponentState)then
Model.LoadFromFile(IncludeTrailingPathDelimiter(ExtractFilePath(GetActiveProject.FileName))+'Obj\'+filename)
else
Model.LoadFromFile(IncludeTrailingPathDelimiter(ExtractFilePath(ParamStr(0)))+'Obj\'+filename);
end;
This procedure is used in constructor as follow (TMyObject inherited from TDummy):
constructor TMyObject.Create(AOwner:TComponent)
begin
inherited;
Model:=TModel3D.Create(Self);
Model.Parent:=Self;
LoadModel('Object1.obj');
end;
Is there anyway to prevent using the ToolsAPI library when the host project for the component is about to compile?
I just thinking about something like directives as follow.
{$IFDEF DESIGNTIME}
uses ToolsAPI;
{$ENDIF}
But is it possible to do such a thing?
It sounds as though you are trying to compile the design time code into a run time project. Either a run time package, or an executable. That's not allowed. You simply cannot compile any of the ToolsAPI units into a project that is not a design time package.
You can certainly use conditional compilation to exclude the ToolsAPI units, but you will have to define your own conditional define. There is no built-in conditional that will serve your needs.
But using conditional compilation is probably not the best solution. Typically you would separate the code that used Tools API into distinct units, and only include those units in the design time projects.
So the code for your component would be split into, say, two units. The first unit, uMyComp.pas, say, contains the bulk of the code. This unit declares the component and provides its implementation. Nothing in uMyComp.pas makes any reference to ToolsAPI. The second unit, uMyCompReg.pas say, performs the component registration and any other tasks that require the ToolsAPI. There is a dependency between these units in that uMyCompReg.pas uses uMyComp.pas. Then your design time package will include both units, and any other projects that are not design time will include only uMyComp.pas.
You could achieve the same effect using conditionals. The design time project would define a conditional to indicate that this was design time. So the project settings might include a definition of a conditional named DESIGNTIME. Then all the code for your component would reside in a unit named uMyComp.pas, say. Any code related to design time would be conditional on DESIGNTIME. And any other projects that included uMyComp.pas would not have DESIGNTIME defined and so would omit the design time only code.
Whilst this is possible it is not, in my view, the best way to solve the problem. Indeed if you look around the wealth of open source examples of component development I'd be surprised if you found any that handled the separation of design time code from run time code using conditionals.
How would you separate the ToolsAPI code into a design time unit? Here's the problem method:
procedure TMyObject.LoadModel(fileName: string);
begin
if csDesigning in ComponentState then
Model.LoadFromFile(IncludeTrailingPathDelimiter(
ExtractFilePath(GetActiveProject.FileName))+'Obj\'+filename)
else
Model.LoadFromFile(IncludeTrailingPathDelimiter(
ExtractFilePath(ParamStr(0)))+'Obj\'+filename);
end;
First of all, let's look at the commonality of this code. The first think to observe is that the outsides of the call to LoadFromFile are the same. Only in the middle, the choice of directory, is there variation. So let's write it like this:
procedure TMyObject.LoadModel(fileName: string);
var
ModelDir: string;
begin
if csDesigning in ComponentState then
ModelDir := ExtractFilePath(GetActiveProject.FileName)
else
ModelDir := ExtractFilePath(ParamStr(0));
Model.LoadFromFile(IncludeTrailingPathDelimiter(ModelDir)+'Obj\'+filename);
end;
The problem for you is how to move GetActiveProject.FileName into the design time code. You need to use dependency injection (DI) to do this. Allow some other party to supply the logic. You need to make TMyObject ignorant of this particular detail. You could use a DI framework for this, but that's perhaps a little heavyweight just for this one task. So instead let's declare a class variable that holds a function pointer:
type
TMyObject = class(...)
...
public
class var GetModelDir: TFunc<string>;
end;
This function point allows other parties, external to the class, to specify how the model directory is located. Now LoadModel becomes:
procedure TMyObject.LoadModel(fileName: string);
var
ModelDir: string;
begin
if Assigned(GetModelDir) then
ModelDir := GetModelDir()
else
ModelDir := ExtractFilePath(ParamStr(0));
Model.LoadFromFile(IncludeTrailingPathDelimiter(ModelDir)+'Obj\'+filename);
end;
At this point, your code can now be used outside of a design time package. The next step is to add code to specify GetModelDir at design time. This code goes in the design time only unit that also registers the component. The obvious place for the code is in the initialization section of that unit. It looks like this:
initialization
TMyObject.GetModelDir :=
function: string
begin
Result := GetActiveProject.FileName;
end;
I've used anonymous methods here, but you could equally use method of object, or plain old functional types, depending on your Delphi version.
Yes, but preferably not with conditional defines as this would create far more complications and restrictions than it's worth.
You need to separate your code into different units according to whether it's design-time code or run-time code.
E.g. For a single component, the bulk of the (with no ToolsAPI dependency) goes into one unit.
A second unit performs component registration and perhaps provides custom design-time editors for the component.
The second unit uses the first and you have a clean separation without conditional defines.
You then create 2 separate packages: design-time and run-time.
The design time package will have a dependency on the ToolsAPI.
Make sure that none of the run-time units use any of the design-time units.
If any design-time units use run-time units (very likely) then the design-time package will require the run-time package.
With the above package structure, your application that uses your new components should only have dependencies on the run-time units.
So basically here is what I did:
I made a new FMHD Application and dropped a TTabControl and a Button on it. Then I designed an interface IFoo. To keep it simple, let's just pretend it only has one procedure:
type
IFoo = interface
['{D035-N07-M4773R-...}']
procedure makeTab(tc : TTabControl);
End;
I implemented this interface in a DLL. The DLL is loaded via LoadLibrary and exports a
function getFoo : IFoo;
MakeTab basically creates a TTabItem and sets tc as it's parent:
procedure TFoo.makeTab(tc : TTabControl);
var
tab
: TTabItem;
begin
tab := TTabItem.Create(tc);
tab.text := 'Hi, I am Tab';
tab.Parent := tc;
// ...
end;
If I forgot something, I am very sorry. I do not have the exact source in front of me at the moment.
This method is invoked when the Button on the form is pressed.
But nothing happens.
So I put this method into my TForm1 class. If I call it now, a tab is created.
So how can I create this tab (and several child components) from within the DLL on the application's main form?
The fundamental issue here is that you cannot share Delphi class types between modules using DLLs. The reason is that there will be multiple versions of what needs to be a single type. One version in the executable, and one version in each DLL that uses it.
This is the same well known issue that exists with the VCL and is the reason why runtime packages were developed. And that's your solution for FMX also. If you need to share Delphi class types between modules you need there to be one single definition of a type. And runtime packages are the mechanism that makes that possible.
So, stop using DLLs, move the code into a runtime package, make sure that the RTL and FMX are linked using runtime packages, and that problem will be solved.
I am new to firemonkey but am using dxscene since a year now. In dxscene brush resources could be added without a hastle in the resources object (style book in firemonkey). But firemonkey boggles me, the docwiki of embaracadero suggests to manually add it in the style book which i don't know how.
Can someone help me to add brush resources in the style book so they could be looked up? Preferably a way involving the GUI.
Style books can only contain descendants of TFMXObject, but TBrush descends directly from TPersistent so can't be added. The FMX.types unit contains a TBrushObject which is suitable but it doesn't appear to be registered anywhere so it's not available in the tool palette.
I suggest creating a package which registers it and therefore make sit selectable. You will need to add a unit to the package such as:
unit RegisterBrushObject;
interface
uses FMX.Types;
procedure Register;
implementation
uses Classes;
procedure Register;
begin
RegisterComponents('Custom', [TBrushObject]);
end;
initialization
RegisterFMXClasses([TBrushObject]);
end;
Once you've added that to a package, right click on the package in the project manager (top-right) and select Install.
Programming Environment: Delphi 6 and upwards
I am aware of the fact that since Delphi 6, custom components must have separate design- and run-time package. All run time features of the a component must therefore be in a separate unit and packaged separately to the component's design-time package.
My problem is the following: My component has code that needs to be run both when it is created on the form at run time and, additional code that needs to be run at design-time, when the component is placed on the form. I have managed to put the run time code into the separate run time unit, package it and deploy it successfully.
However, in the separate design-time module unit, how do I reference and add the design-time code that needs to be included into the component's create constructor during design-time, when the component gets placed onto the form?
You can separate design time behaviour from run time behaviour with
if [not] (csDesigning in ComponentState) then
But if your constructor code needs the DesignIDE design time package, e.g. from the units DesignEditors, DesignIntf, etc..., then I think you are stuck. Maybe some IOTA involvement can help. But since there does not seem to exist a notifier interface for the creation of components, that would require a custom IOTAFormEditor. Not that easy, if not impossible.
Why not use callbacks?
From your designtime package initialization code do this:
unit MyDsgnUnit;
interface
//TMyHook defined in AnImplUnit
TMyDesignHandlerObject = class
procedure MyMethod(Sender:TObject;ParentForm:TObject); { must match TMyHook }
end;
implementation
uses AnImplUnit, DesignUnitNamesHere;
procedure TMyDesignHandlerObject.MyMethod(Sender:TObject);
var
newObject:TMyComponent;
begin
newObject := TMyComponent(Sender);
DoSomethingThatneedsDesigntimeStuff(newObject);
end;
finalization
ADesignHandlerObject.Free;
initialization
ADesignHandlerObject := TMyDesignHandlerObject.Create;
AnImplUnit.AfterConstructionHook := TDesignHandlerObject.MyMethod;
and in your component do something like this:
unit AnImplUnit;
interface
type
TMyHook = procedure(Sender:TObject;ParentForm:TObject) of object;
var
AfterConstructionHook:TMyHook;
implementation
...
procedure TMyComponent.Create(AOwner:TComponent);
begin
inherited Create(AOwner);
DOMyStuff;
if Assigned(AfterConstructionHook)
AfterConstructionHook(Sender,Parent);
end;
Update Flushed out example more. There is no reason you can't add more parameters to the AfterConstructionHook, but since your reference to Sender is already of type TMyComponent, I don't see the point, when you can access everything public or protected, in TMyComponent(Sender) from within your hook function, and if you inherit locally (known as a protected-access class), you can access the protected stuff too.
Make sure your DPK defines a symbol of your choice, for example DESIGNTIME. Then you'll be able to use something like this to only include design-time units when needed:
uses Windows, Whatever, Something
{$IFDEF DESIGNTIME}
,DesignIntf
{$ENDIF}
;
Then to the same in your constructor code:
constructor TMyClass.Create(aOwner:TComponent);override;
begin
inherited;
{$IFDEF DESIGNTIME}
// I'm at design time.
{$ENDIF}
end;
When using this technique you should either use a separate DCU directory for your pacakge and your normal executable, or do a build each time you switch from the design time package to other projects. That's because Delphi will only re-build a DCU if the PAS has changed, when in this case the PAS doesn't tell the whole story, defined symbols also matter. If you have a DCU on disk that was compiled by Delphi while you were building your design time project, you might see a ToolsApi.DCU not found when trying to compile a normal project. Rebuilding re-compiles the DCU and makes the message go away. Just as well, if you re-compile (not re-build) the design time project after you built a normal project, your DCU might be stuck in it's non-DESIGNTIME state, leaving you without your special design-time behavior.
As long as your code does not require the IDE tools, like design interface and so on, then all you need to do is check the component flag and you can use it anywhere within the component, as follows...
procedure TNewEdit.Loaded;
begin
inherited;
if (csDesigning in ComponentState) then
ShowMessage('Designing')
else
ShowMessage('Running');
end;
However without really knowing what you are attempting to do, there are several doors left open... for example, if you want to change a property value at design time, and a different value at run time, then there are streaming issues you have to deal with.