How to automatically implement inherited abstract methods in Delphi XE - delphi

Is it possible to let the IDE automatically implement inherited abstract methods in Delphi XE? In Java and C# IDEs it's a common functionality like pressing ALT+SHIFT+F10 in Visual Studio or ALT+RETURN in IntelliJ IDEA.
Without this I always have to look up manually which methods have to be implemented and copy their declarations, which really is something I shouldn't have to do nowadays!

You can use ctrl+space in the class declaration to get a list of all the methods you might want to override (or implement from an interface). It does however not tell you which is abstract but once you figured that out you will get the declaration for free by selecting the method(s) from the list.
And after that you can of course use class completion ctrl+shift+c to generate the code in implementation section.

No, the Delphi IDE doesn't have an automatic shortcut for this. But, you can use the compiler to make it easier on you.
Define your new class. Then put a line somewhere in your code that says TMyNewClass.Create(whatever). When the compiler parses this, if there are any unimplemented abstract methods on TMyNewClass, it will tell you about them in the compiler warnings.

Related

OTL can't be compiled under D2007

I downloaded the OTL http://www.omnithreadlibrary.com/
and compile the D2007 grouproj, install the package, without problem.
I then create a simple console application that uses OtlParallel unit, of course, I add the OtlParallel and some other pas files to the project.
But it complains that Generics.Collections is not found.
The documentation says:
High-level abstractions are implemented in the OtlParallel unit. They are all created through the factory class Parallel. High-level code intensively uses anonymous methods and generics which makes Delphi 2009 the minimum supported version.
This us of both generics and anonymous methods makes this unit completely incompatible with Delphi 2007.
If you wish to use a construct like Parallel.For with Delphi 2007 and OTL then you will have to back-port OtlParallel yourself. Without anonymous methods this is very difficult to do and achieve the same fluid style of code. You would have to use procedural types instead of anonymous methods. And you would have to implement closures manually.
So instead of using
TProc = reference to procedure;
you would use
TMethod = procedure of object;
And then to implement this you create a class or record with a parameterless method. You'll need to add whatever state is needed as members of the type, and populate those members. That is in essence a manual implementation of a closure with variable capture. And you'll need to deal with lifetime. Make sure that the instances outlive the parallel loop.
Good luck!

delphi-shortcut to implement interface method and abstract method from ancestor interface or class

I have example code like this
IExample=interface
procedure Test;
end;
TBaseClass=class
function Check:boolean;abstract;
end;
TExampleObject=class(TInterfacedObject,IExample)
end;
TAnotherObject=class(TBaseClass)
end;
My question is, how I can implement interface method and abstract method from ancestor?
I use Visual Studio and C#, very simple to make implementation from abstract method and interface method, I just right click on my class, and Implement method.
Does RAD Studio XE2 have similiar tool or third party tool that have same function? because is annoying if I must write down all abstract and interface method manually
I suppose there are IDE plugins out there that offer the functionality you want.
I use this method every day:
Copy the methods from your interface to the public section of your class, set cursor on one of these methods and execute shortcut CTRL-SHIFT-C. Delphi will automagically create the functions/procedures in the implementation section for you!
This works for all classes...
Yeah, it would be nice if this worked for functions inherited through Interfaces too and it would be nice if it worked in Interfaces themselves for creating Getter / Setters for Interface Properties!
That said, I will log it with QC (if its not already) as its a good suggestion.
Update: Here you go :) - http://qc.embarcadero.com/wc/qcmain.aspx?d=121748

Instantiate Interface of Interop DLL

I'm working with some Interop code and need to instantiate an interface.
The equivalent in C# is:
Interop.SomeInterface theInterface;
theInterface = new Interop.SomeInterface();
theInterface.SomeEvent += new SomeEventHandler(...);
How can I accomplish instantiating this interface in F#? Do I need to re-wrap this interop dll into something that F# can make sense of?
It is impossible to instantiate an interface. The C# compiler is pulling a trick by instantiating a class by looking up the implementer of the interface. This is done by the compiler examining the CoClassAttribute.
As far as I know, F# knows nothing about the CoClassAttribute, so you need to change your code so that it instantiates an actual class, not an interface.
You could figure out the class you need by looking at the CoClassAttribute on SomeInterface with Reflector, ILdasm, or any other metadata inspector. If the interop wrapper was generated using tlbimp or visual studio, usually the class will be named SomeInterfaceClass by convention.

Redeclaration hides member in base class

I am trying to clean up compiler warnings in an application I inherited. One of our classes inherits from TControl. The warning I am getting is "Redeclaration of Changed hides a member in the Base class"
"Changed" is a protected procedure in TControl. The class I am looking at has overridden it with a boolean property
property Changed : Boolean read FChanged write FChanged stored true;
There are a few options I have ruled out already:
Rename from "Changed" to something else. This is not a practical option, as this property is used everywhere in the application.
Hide the warning using compiler directives. I can do this but I would prefer to find out what the warning means and how to correct it.
So my question is:
1) Is this warning actually a problem? What are the implications of "hiding the base member"?
2) How can I remove the compiler warning without renaming the property or hiding the warning?
I am using Delphi 2010
[Edit: There have been a few suggesions of using the refactoring tool to rename the offending property. I have ruled this out as the refactoring tool doesn't work at all on this codebase]
If your own 'Changed' was a procedure as well, you could use the override directive to tell the compiler that you add functionality to the base Changed method in TControl. If your declaration differs or you want for some other reason to break the chain of inheritance, you could specify the reintroduce directive to tell the compiler that you conciously break the chain.
Unfortunately this is not possible with properties, so there is no real solution for your problem, other than
Rename 'Changed' to something else
Hide the warning using directives
Don't inherit from TControl
I would opt for the first option. Since you are using Delphi 2010, you can use the Refactoring tools in Delphi to rename the property thoughout your application, although I would thoroughly check the modifications before making them final, because maybe they will affect the Changed method in the base class as well...

Delphi 6: Force compiler error on missing abstract class methods?

I'm using Delphi Pro 6. Right now, the only way to know if a class is missing a base class abstract method is to wait for the IDE to emit a "constructing instance of {derived class} containing abstract method {base class.abstract method name}" warning or to wait for a runtime Abstract Error method when an attempt to call the missing method is made. The former isn't sufficient since it only finds warnings for those derived classes actually constructed in the current project. The latter is just plain painful.
It would be so much better if Delphi output a fatal warning for all classes that do not declare/implement a base class abstract method immediately. Does anyone know a way to set this up or a plug-in that does this?
Thanks.
I've found the simplest way to do this is to add a section in the unit initialization area using a conditional define that creates an instance of each class that you think shouldn't have any abstract methods:
{$IFDEF CheckAbstracts}
initialization
TSubclass1.Create(params);
TAbstractClass1.Create(params); // Gives constructing instance of {derived class} containing abstract method warning
{$ENDIF}
Compile with the CheckAbstracts conditional, and you will get warnings whenever you have an incompletely implemented class.
A class containing abstract methods is only dangerous if you instantiate the class, so Delphi's warning is spot-on. You only get the abstract-error run time exception if you ignored at least one "instantiating class with abstract methods".
It's valid to not implement these methods. You might intend to implement the abstract method in yet another subtype.
A later version of Delphi/Win32 (I don't remember which) introduced formal abstract classes, which make it clear when you do and do not intend to instantiate the type. If you're rigorous about using this, the feature you request would then make sense. But for D6 it is not clear.

Resources