Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I can do this in other languages that I use. For instance I can do this in PHP when needed for web app creation, but here is what I want to do and can't find a solution:
I want to define an interface say:
unit myBigUnit;
interface
uses someUnits;
type
TsampleType = class
someVar: Integer;
someOtherVar: Integer;
someObj: TneatObj;
procedure foo;
function bar : String;
procedure foobar(a: boolean);
All this in one file. Now I want two files that implement this interface or at least know about it. In php I can just say
class blah implements thisInterface
but I can't find an equivalent in Delphi. What I am trying to do is implement this in one unit while in another one I just want it to know about these functions/procedures/et al so I can then call them from there. I couldn't care less about how it is implemented. I thought this was the whole point of having interfaces and separating them from implementors?
How do I do this in Delphi?
You need to use an actual interface, eg:
type
IsampleType = interface
procedure foo;
function bar : String;
procedure foobar(a: boolean);
end;
An interface can only have methods and properties, not variables.
You can then implement the interface in your classes as needed, eg:
type
TMyClass = class(TInterfacedObject, IsampleType)
public
someVar: Integer;
someOtherVar: Integer;
someObj: TneatObj;
procedure foo;
function bar : String;
procedure foobar(a: boolean);
end;
var
Sample: IsampleType;
begin
Sample := TMyClass.Create;
// use Sample as needed...
end;
Delphi interfaces are reference counted. TInterfacedObject handles the reference counting for you. It automatically frees the object when its reference count falls to 0.
You can find more details in Delphi's documentation:
Object Interfaces Index
Then you should use an Interface:
...
type
IsampleType = Interface
.....
an implement this in your classes:
type
TIntfType = class(TInterfacedObject, ISampleType)
....
and the details you will find with F1 in Delphi...
Related
This question already has answers here:
Copy object data fields into subclass instance
(2 answers)
Closed 8 years ago.
depending on the dataflow (data itself) i'm starting with a very simple data type "AboutMe", later depending on the data itself or the workflow I want to continue working using this data now in a class called "AboutMe_more". This procedure might happen 1..3 times in my program.
AboutMe= class
Name : String
end;
AboutMe_more = class(AboutMe)
gender : String;
Birth : TDate;
Aboutme_complete = class (AboutMe_more)
adresss : String;
salery : Real;
.....
end;
starting with the complete class is not a good idea in my case because there might be a different switch to an other desired class like
Aboutme_complete_option = class (AboutMe_more)
company : string;
city : String;
kids : String;
.....
end;
Q:
a) What is the best way to transfer data from one class to the derived class, not need for transfer data to parent class .
b) Is the way a good programming style or does the need for that datamovement indicate a poor class construction / design ?
It almost looks like you are trying to model a database using objects.
b) Is the way a good programming style or does the need for that datamovement indicate a poor class construction / design ?
The problem here (as mentioned by #jpfollenius) is that you'll end up with a very deep hierarchy of objects.
a) What is the best way to transfer data from one class to the derived class [...]?
I don't know about the best way, but in Delphi transferring data from one object to another is often done using an overloaded Assign.
TMyObject = class(TPersistent)
procedure Assign(Source: TPersistent); overload;
....
implementation
procedure TMyObject.Assign(Source: TPersistent);
begin
inherited Assign(Source);
if (Source is TMyObject) then begin
Self.Field1:= Source.Field1;
Self.Field2:= Source.Field2;
end;
end;
More sensible approach
Inheritance is only one way to address this problem.
A more appropriate way would be to use encapsulation.
Here you have an object and an interface which holds the data and container objects which give you access to that data.
Delphi has a very nice mechanism for that because it allows you to delegate the implementation of an interface to a contained object.
An example using 2 data objects with interfaces and a container object.
type
IData1 = interface
['{3F996D68-1FD0-4490-AE60-8F735A9DFFE8}'] //Use ctrl+alt+g to generate a number
function GetData1: integer;
procedure SetData1(value: integer);
property Data1: integer read GetData1 write SetData1;
end;
IData2 = interface
['{3F996D68-1FD0-4490-AE60-8F735A9DFFE9}']
function GetData2: integer;
procedure SetData2(value: integer);
property Data2: integer read GetData2 write SetData2;
end;
TData1 = class(TInterfacedObject, IData1);
private
FData1: integer;
protected
function GetData1: integer;
procedure SetData1(value: integer);
public
property Data: integer read GetData1 write SetData1;
end;
TData2 = class(TInterfacedObject, IData2);
{see TData1 above}
TContainer = class(TInterfacedObject, IData1, IData2)
private
FData1: TData1;
FData2: TData2;
public
constructor Create();
property Data1: TData1 read FData1 implements IData1; //delegates implementation to object FData.
property Data2: TData2 read FData2 implements IData2;
end;
Copied from this question: https://stackoverflow.com/questions/6063274/hidden-features-in-the-delphi-language (now sadly deleted).
Is it possible to add and implement an interface to an already existing class (which is a descendant of TInterfaced or TInterfacedPersistent) to accomplish separating Model and View into 2 units?
A small explanation why I need something like this:
I am developing a tree-structure, open-type model, which has following structure (VERY simplified and incomplete, just to illustrate the outline of the problem):
Database_Kernel.pas
TVMDNode = class(TInterfacedPersistent);
public
class function ClassGUID: TGUID; virtual; abstract; // constant. used for RTTI
property RawData: TBytes {...};
constructor Create(ARawData: TBytes);
function GetParent: TVMDNode;
function GetChildNodes: TList<TVMDNode>;
end;
Vendor_Specific_Stuff.pas
TImageNode = class(TVMDNode)
public
class function ClassGUID: TGUID; override; // constant. used for RTTI
// Will be interpreted out of the raw binary data of the inherited class
property Image: TImage {...};
end;
TUTF8Node = class(TVMDNode)
public
class function ClassGUID: TGUID; override; // constant. used for RTTI
// Will be interpreted out of the raw binary data of the inherited class
property StringContent: WideString {...};
end;
TContactNode = class(TVMDNode)
public
class function ClassGUID: TGUID; override; // constant. used for RTTI
// Will be interpreted out of the raw binary data of the inherited class
property PreName: WideString {...};
property FamilyName: WideString {...};
property Address: WideString {...};
property Birthday: TDate {...};
end;
Using a GUID-based RTTI (which uses ClassGUID), the function GetChildNodes is able to find the matching class and initialize it with the raw data. (Each dataset contains ClassGUID and RawData beside other data like created/updated timestamps)
It is important to notice that my API (Database_Kernel.pas) is strictly separated from the vendor's node classes (Vendor_Specific_Stuff.pas).
A vendor-specific program's GUI wants to visualize the nodes, e.g. giving them an user-friendly name, an icon etc.
Following idea works:
IGraphicNode = interface(IInterface)
function Visible: boolean;
function Icon: TIcon;
function UserFriendlyName: string;
end;
The vendor's specific descendants of TVMDNode in Vendor_Specific_Stuff.pas will implement the IGraphicNode interface.
But the vendor also needs to change Database_Kernel.pas to implement IGraphicNode to the base node class TVMDNode (which is used for "unknown" nodes, where RTTI was unable to find the matching class of the dataset, so at least the binary raw data can be read using TVMDNode.RawData).
So he will change my class as follows:
TVMDNode = class(TInterfacedPersistent, IGraphicNode);
public
property RawData: TBytes {...};
class function ClassGUID: TGUID; virtual; abstract; // constant. used for RTTI
constructor Create(ARawData: TBytes);
function GetParent: TVMDNode;
function GetChildNodes: TList<TVMDNode>;
// --- IGraphicNode
function Visible: boolean; virtual; // default behavior for unknown nodes: False
function Icon: TIcon; virtual; // default behavior for unknown nodes: "?" icon
function UserfriendlyName: string; virtual; // default behavior for unknown nodes: "Unknown"
end;
The problem is that IGraphicNode is vendor/program-specific and should not be in the API's Database_Kernel.pas, since GUI and Model/API should be strictly divided.
My wish would be that the interace IGraphicNode could be added and implemented to the existing TVMDNode class (which is already a descendant of TInterfacedPersistent to allow interfaces) in a separate unit. As far as I know, Delphi does not support something like this.
Beside the fact that it is not nice to mix Model and View in one single unit/class, there will be following real-world problem: If the vendor has to change my Database_Kernel.pas API to extend TVMDNode with the IGraphicNode interface, he needs to re-do all his changes, as soon as I release a new version of my API Database_Kernel.pas.
What should I do? I thought very long about possible solutions possible with Delphi's OOP. A workaround may be nesting TVMDNode's into a container class, which has a secondary RTTI, so after I have found the TVMDNode class, I could search for a TVMDNodeGUIContainer class. But this sounds very strangle and like a dirty hack.
PS: This API is an OpenSource/GPL project. I am trying to stay compatible with old generations of Delphi (e.g. 6), since I want to maximize the number of possible users. However, if a solution of the problem above is only possible with the new generation of Delphi languages, I might consider dropping Delphi 6 support for this API.
Yes it is possible.
We implemented something similar to gain control of global/singletons for testing purposes. We changed our singletons to be accessible as interfaces on the application (not TApplication, our own equivalent). Then we added the ability to dynamically add/remove interfaces at run-time. Now our test cases are able to plug in suitable mocks as and when needed.
I'll describe the general approach, hopefully you'll be able to apply it to the specifics of your situation.
Add a field to hold a list of dynamically added interface. An TInterfaceList works nicely.
Add methods to add/remove the dynamic interfaces.
Override function QueryInterface(const IID: TGUID; out Obj): HResult; virtual;. Your implementation will first check the interface list, and if not found will defer to the base implementation.
Edit: Sample Code
To answer your question:
I understand that the class now can tell others that it supports interface X now, so the interface was ADDED during runtime. But I also need to IMPLEMENT the interface's methods from outside (another unit). How is this done?
When you add the interface, you're adding an instance of the object that implements the interface. This is very much like the normal property ... implements <interface> technique to delegate implementation of an interface to another object. The key difference being this is dynamic. As such it will have the same kinds of limitations: E.g. no access to the "host" unless explicitly given a reference.
The following DUnit test case demonstrates a simplified version of the technique in action.
unit tdDynamicInterfaces;
interface
uses
SysUtils,
Classes,
TestFramework;
type
TTestDynamicInterfaces = class(TTestCase)
published
procedure TestUseDynamicInterface;
end;
type
ISayHello = interface
['{6F6DDDE3-F9A5-407E-B5A4-CDF91791A05B}']
function SayHello: string;
end;
implementation
{ ImpGlobal }
type
TDynamicInterfaces = class(TInterfacedObject, IInterface)
{ We must explicitly state that we are implementing IInterface so that
our implementation of QueryInterface is used. }
private
FDynamicInterfaces: TInterfaceList;
protected
function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
public
constructor Create;
destructor Destroy; override;
procedure AddInterface(AImplementedInterface: IInterface);
end;
type
TImplementor = class (TInterfacedObject, ISayHello)
{ NOTE: This could easily have been implemented in a separate unit. }
protected
{ISayHello}
function SayHello: string;
end;
{ TDynamicInterfaces }
procedure TDynamicInterfaces.AddInterface(AImplementedInterface: IInterface);
begin
{ The simplest, but least flexible approach (see also QueryInterface).
Other options entail tagging specific GUIDs to be associated with given
implementation instance. Then it becomes feasible to check for duplicates
and also dynamically remove specific interfaces. }
FDynamicInterfaces.Add(AImplementedInterface);
end;
constructor TDynamicInterfaces.Create;
begin
inherited Create;
FDynamicInterfaces := TInterfaceList.Create;
end;
destructor TDynamicInterfaces.Destroy;
begin
FDynamicInterfaces.Free;
inherited Destroy;
end;
function TDynamicInterfaces.QueryInterface(const IID: TGUID; out Obj): HResult;
var
LIntf: IInterface;
begin
{ This implementation basically means the first implementor added will be
returned in cases where multiple implementors support the same interface. }
for LIntf in FDynamicInterfaces do
begin
if Supports(LIntf, IID, Obj) then
begin
Result := S_OK;
Exit;
end;
end;
Result := inherited QueryInterface(IID, Obj);
end;
{ TImplementor }
function TImplementor.SayHello: string;
begin
Result := 'Hello. My name is, ' + ClassName;
end;
{ TTestDynamicInterfaces }
procedure TTestDynamicInterfaces.TestUseDynamicInterface;
var
LDynamicInterfaceObject: TDynamicInterfaces;
LInterfaceRef: IUnknown;
LFriend: ISayHello;
LActualResult: string;
begin
LActualResult := '';
{ Use ObjRef for convenience to not declare interface with "AddInterface" }
LDynamicInterfaceObject := TDynamicInterfaces.Create;
{ But lifetime is still managed by the InterfaceRef. }
LInterfaceRef := LDynamicInterfaceObject;
{ Comment out the next line to see what happens when support for
interface is not dynamically added. }
LDynamicInterfaceObject.AddInterface(TImplementor.Create);
if Supports(LInterfaceRef, ISayHello, LFriend) then
begin
LFriend := LInterfaceRef as ISayHello;
LActualResult := LFriend.SayHello;
end;
CheckEqualsString('Hello. My name is, TImplementor', LActualResult);
end;
end.
You can preserve the ability to persist data and implement it through inheritance and still create the correct instances for the ClassGUIDs stored in the tables if you'd apply the factory design pattern.
For each node class there would be one class factory (or just a function pointer) responsible for creation of the correct Delphi class. Class factories may register themselves in the unit initialization section (once per application startup) at the kernel singleton object.
The kernel singleton would then map GUID to correct factory that would in turn call the correct class instance constructor (as shown at http://delphipatterns.blog.com/2011/03/23/abstract-factory)
Packages may be split into separate DLLs and classes implemented in separate units, still inheriting from one base TVMNode class.
The features you now use RTTI for can be supported in descendant classes or in the factory classes easily through some virtual methods.
You might also consider using simpler Data Transfer Objects for saving/loading the TVMNodes and perhaps take some inspiration from an already well perceived Object Relational Mapper or a Object Persistence framework as the problem you are trying to solve seem to me like exactly the problems they are handling (already)
I don't know about good Delphi open source frameworks of this class. But from other languages you can look at Java Hibernate, Microsoft .NET Entity Framework or minimalistic Google Protocol Buffers serializer
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How to cast a Interface to a Object in Delphi
Using Delphi 5; I have an interface that I cannot change for legacy reasons. I am passing (pointers to) that interface all over the place. The implementing class has several new properties - is there a way to force a cast from the interface to the actual implementation?
http://www.malcolmgroves.com/blog/?p=500 says that this is (newly) implemented in Delphi 2010, which strongly suggest that it wasn't possible before. Is this indeed the case, or is there a way I'm not familiar with? RTTI, maybe?
(I checked, and if pScore is TOleScore then is indeed not allowed by the Delphi 5 compiler - here pScore is my pScore: IScore argument, and TOleScore is the implementing class.)
The classic take on this is by Hallvard Vassbotn: Hack #7: Interface to Object
More recently Barry Kelly, a Delphi compiler engineer, also provided an implementation: An ugly alternative to interface to object casting
I think both approaches should work.
Incidentally, does anyone know if Hallvard is still active? I've not come across him in the past few years.
H/t to my boss, the answer is: use the incredibly useful JEDI library, specifically the GetImplementorOfInterface method.
i do what the "possible duplicate" question's accepted answer does:
Have the object implement the IObject interface:
IObject = interface(IUnknown)
['{39B4F98D-5CAC-42C5-AF8D-0237C8EFBE4C}']
function GetSelf: TObject;
end;
So it would be:
var
thingy: IThingy;
o: TOriginalThingy;
begin
o := (thingy as IObject).GetSelf as TOriginalThingy;
Update: To drive the point home, you can add a new interface to an existing object.
Existing object:
type
TOriginalThingy = class(TInterfacedObject, IThingy)
public
//IThingy
procedure DrinkCokeZero; safecall;
procedure ExcreteCokeZero; cafecall;
end;
Add IObject as one of the interfaces it exposes:
type
TOriginalThingy = class(TInterfacedObject, IThingy, IObject)
public
//IThingy
procedure DrinkCokeZero; safecall;
procedure ExcreteCokeZero; cafecall;
//IObject - provides a sneaky way to get the object implementing the interface
function GetSelf: TObject;
end;
function TOriginalThingy.GetSelf: TObject;
begin
Result := Self;
end;
Typical usage:
procedure DiddleMyThingy(Thingy: IThingy);
var
o: TThingy;
begin
o := (Thingy as IObject).GetSelf as TThingy;
o.Diddle;
end;
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I would like to build a program which lets lyrics of a song run over the screen. Something like this:
http://www.youtube.com/watch?v=kIAiBvD9njM
Can you help me?
Algorithm:
pushes the marker to the right of a line fitting the music
lets a line above the current line disappear
inserts a new line above the current line
What is needed?
lyrics of the song (line per line)
time to text data? (when does a line start/end)
Some approaches would help me a lot. Pseudo-code or even Delphi code of any part would be fantastic.
If you're interested in karaoke code in pascal, make sure to take a look at UltraStar Deluxe.
It's a super slick and very popular karaoke application. The project is active and it's open source. It can be compiled to various platforms with FPC. You can compile it from both Delphi and Lazarus.. nice.
http://ultrastardx.sourceforge.net/
My neighbours thought that my dog was their worst nightmare until I found this program.
See it in action: po-po-po-pokerface po-po-pokerface.. mum mum mum mah! :)
let's assume you have a text file with the text to be shown and the annotated time of when to hightlight it (kind of a subtitles file, for example the standard proposal w3c timed text (http://www.w3.org/AudioVideo/TT/) or the SUB - Movie subtitle file format in use by several media players.
Your program must first read and parse the text file, and decode the annotated time. Insert it in a stringlist called Subtitles which items would also keep objects similar to this one
type tSubtitle = class
num : integer;
prevTime, fromTime : tdatetime;
toTime, nextTime: tdatetime;
text: string;
end;
You might want to extend the object to hold some highlighting attributes as well.
Then you just need to display those objects synchronized with a timer.
procedure TForm1.Timer1Timer(Sender: TObject);
var rt : TDateTime;
done:boolean;
si,st,sb:integer;
s:string;
begin
rt:=now-startTime;
st:=0;
sb:=subtitles.Count; // binary search the subtitle for the current time
repeat
si:=(st+sb) div 2;
s:=TSubtitle(subtitles.Objects[si-1]);
done:= ((t>=s.prevTime) and (t<=s.nextTime));
if not done then
begin
if t>s.prevTime then st:=si
else if t<s.nextTime then sb:=si;
if st=sb then done:=true;
end;
until done;
// do what you want with s
end;
Another option would be to create your own markup that you parse for that contains both the text and the delay timing. While a timer would work, the problem is that its not going to be accurate enough over time to give you reliable results since its fired based on messaging. Instead, I would perform triggers based on how far from the beginning of the music file you want the event to occur. This also allows the system to catch-up if some other app blocking process gets in the way and should help keep things in sync.
Something as simple as:
00:00:15;LYRIC;This is lyric line 1
00:00:18;FADEOUT
you then can parse this into list of appropriate objects which take the appropriate actions.
You should create a new class based on TGraphicControl/TCustomControl(anything with a canvas) and add a string property, now you have to create a timer as a private variable with it's interval value published through your class, something like so
...
type TLyricViewer = class(TGraphicControl)
private
FTimer : TTimer;
FLyric : string;
FBitmap : TBitmap;// offset bitmap on which you draw
// some more variables to store paint information
private
procedure OnNextWord(Sender: TObject);// assign this to FTimer.OnTimer event
public
constructor Create(AOwner: TComponent);
destructor Destroy; override;
public
procedure StartLyric;
procedure StopLyric;
procedure Paint; override;
published
property WordInterval : Integer|Cardinal
read GetWordInterval write SetWordInterval;
end;
...
procedure TLyricViewer.Paint;
begin
// here is where the magic happends
end;
constructor TLyricViewer.Create(AOwner: TComponent);
begin
// create timer, bitmap and set default properties
end;
destructor TLyricViewer.Destroy;
begin
// free and nil the timer and bitmap
inherited Destroy;
end;
The rest is up to you, after all your the one getting paid, work for it :)
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
What is the difference between these two pieces of code
type
IInterface1 = interface
procedure Proc1;
end;
IInterface2 = interface
procedure Proc2;
end;
TMyClass = class(TInterfacedObject, IInterface1, IInterface2)
protected
procedure Proc1;
procedure Proc2;
end;
And the following :
type
IInterface1 = interface
procedure Proc1;
end;
IInterface2 = interface(Interface1)
procedure Proc2;
end;
TMyClass = class(TInterfacedObject, IInterface2)
protected
procedure Proc1;
procedure Proc2;
end;
If they are one and the same, are there any advantages, or readability issues with either.
I guess the second means you cannot write a class that implements IInterface2 without implementing IInterface1, whilst with the first you can.
The two snippets of code have very different effects, and are in almost no way equivalent, if we are talking about Delphi for Win32 (Delphi for .NET has different rules).
A class that implements its interface must implement all the members of that interface's ancestors, but it does not implicitly implement the ancestors. Thus, attempts to assign instances of type TMyClass to locations of type IInterface1 will fail for the second case.
Related to the previous point, if IInterface1 and IInterface2 both had GUIDs, dynamic casts (using Supports or 'as') of interface references with a target type of IInterface1 would fail on instances of TMyClass in the second case.
The interface IInterface2 has an extra method in the second case, which it does not in the first.
Values of type IInterface2 in the second case are assignable to locations of type IInterface1; this is not true for the first case.
See for yourself in this example:
type
A_I1 = interface
end;
A_I2 = interface(A_I1)
end;
A_Class = class(TInterfacedObject, A_I2)
end;
procedure TestA;
var
a: A_Class;
x: A_I1;
begin
a := A_Class.Create;
x := a; // fails!
end;
type
B_I1 = interface
end;
B_I2 = interface
end;
B_Class = class(TInterfacedObject, B_I1, B_I2)
end;
procedure TestB;
var
a: B_Class;
x: B_I1;
begin
a := B_Class.Create;
x := a; // succeeds!
end;
begin
TestA;
TestB;
end.
First off, I'm assuming that the second example's declaration for IInterface2 is a typo and should be
IInterface2 = interface(Interface1)
because inheriting from itself is nonsensical (even if the compiler accepted it).
And "inheriting" is the key word there for answering your question. In example 1 the two interfaces are completely independent and you can implement one, the other, or both without problems. In example 2, you are correct that you can't implement interface2 without also implementing interface1, but the reason why that's so is because it makes interface1 a part of interface2.
The difference, then, is primarily structural and organizational, not just readability.
Assuming you meant
...
IInterface2 = interface(Interface1)
...
I interpret it the same as you, the second form requires a class implementing Interface2 to implement Interface1 as well, while the first form does not.
I guess the second means you cannot write a class that implements IInterface2 without implementing IInterface1, whilst with the first you can.
That would be the technical difference.
Which one is better depends very much on what the interfaces actually are. Does it ever make sense for an IInterface2 to exist without it also being an IInterface1?
If IInterface1 is "displayable" and IInterface2 is "storable," then the first option probably makes more sense. If IInterface1 is "vehicle" and IInterface2 is "truck," then the second option probably makes much more sense.