I am trying to register a style hook for a component that I have built using C++. But I am not sure how to get the TClass from my class definition. another word, how do I call RegisterStyleHook in C++. For example my component is called TProgressBarEx and my Style hook is TProgressBarExStyleHook. But
TCustomStyleEngine::RegisterStyleHook(TProgressBarEx, TProgressBarExStyleHook); does not compile because I need to get a TClass from TProgressBarEx and a TStyleHookClass from TProgressBarExStyleHook.
Thank you
Sam
I found the Answer myself. TStyleHookClass is just a typedef for TClass and __classid returns a TClass for any class definition. So my call should be like:TCustomStyleEngine::RegisterStyleHook(__classid(TProgressBarEx), __classid(TProgressBarExStyleHook));
Related
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
How to send attachment using TIdyAttachment ?
How to convert this TIdAttachment.Create(msg.MessageParts, 'c:\attach.bmp'); delphi statement to c++ builder ?
How to use this abstract class in c++ builder? Due to it's being abstract I cannot create an instance of it !!!
Note that TIdAttachment is indeed abstract (as Remy Lebeau noted in a comment). Use TIdAttachmentFile instead. In C++, I guess it should look like (Update: I see you already found that):
TIdAttachmentFile *attachment = new TIdAttachmentFile(msg->MessageParts, "C:\\attach.bmp");
FWIW, named constructor calls like TMyClass.Create(args) in Delphi are translated as new TMyClass(args) in C++Builder. That is why Delphi often overloads Create, instead of using differently named constructors like CreateWithSpecialParams. In Delphi, a constructor can have any name, but not in C++.
Note that in Delphi you can have a constructor Create(Integer) and a constructor CreateEx(Integer) and they are distinguishable. This is not translatable to C++Builder, since both translate to MyClass(int), so doing that should be avoided if the Delphi programmer wants his or her class to be usable in C++Builder.
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.
I'm attempting to write a unit test for a simple factory class that creates one of several possible implementing objects and returns it as an interface reference.
DUnit has a built in procedure, CheckIs(AObject: TObject; AClass: TClass; msg: string), that based on its name and the parameters it accepts should fail the test if the object's class type doesn't match the expected one. The only problem is it requires an object reference not an interface reference.
So I'm trying to use CheckTrue and perform the comparison in the body of the test but I'm not as familiar with Delphi's type checking support as I am with C#'s.
I know the is operator is out of the question since it only works with object references.
CheckTrue(LMyInterfaceReference {comparison here} TMyClass);
Any suggestions?
BTW, I'm using Delphi 2009 so I don't have access to the new RTTI support added in 2010+.
I'm wondering why you MUST have to test this... maybe you really don't have to.
But if knowing the underlying object of a Interface is a must, you have two choices:
Add a method to the interface which returns the underlying object, just a TObject, and implement this in each class just by returning self.
Hack a bit, for example using this Interface to object routine.
If you don't like hacks and don't feel like upgrading to Delphi 2010+ you may use an interface like this:
IImplementingObjectInterface = interface
function GetImplementingObject: TObject;
end;
Make sure your objects also implement this interface and use it to extract the implementing object. If you need to do this for a lot of objects you can define your own TInterfacedObject derivate that already implements this so you can simply change your inheritance and be done.
Barry Kelly (one of the main Embarcadero Delphi Compiler Engineers) wrote a nice An ugly alternative to interface to object casting this week.
It answers your question.
The fun is that Hallvard Vassbotn wrote a very similar piece of code back in 2004.
From Delphi 2010 on, you can just use an is check or as cast to go back from interface references to object references.
--jeroen
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.