I want to dynamically get a property value from an object instance.
I was able to get the class properties, ordinal types and strings. The delphi source of the GetPropValue does not support tkInterface. Is there any way of getting the interface using the property info. BTW all the properties exposed are published properties.
for time being, i am using the TObject as the return type. GetPropValue returns the address of the object instance. I am typecasting that to TObject and returning the result.
If I understand you right you want to use GetInterfaceProp() function. Usage is same as GetPropValue() but it returns an IInterface which you can "cast" to right type using ie Supports().
Related
As we can find a Property or an Object using RTTI, can we search for a certain function or procedure (not from an object as a method but from an unit) loaded in memory knowing just it's name?
And if we can, is it possible to execute it sending it's parameters?
Delphi's RTTI system is based around types. However, procedures and functions with unit scope are not associated with types and so cannot be reached using RTTI.
I have a Delphi 6 class object that contains an array of 30 Variants, each of which is exposed via a different indexed property. For example:
property responseCode: integer
Index 7 read getIndexedProperty_integer write setIndexedProperty_integer;
I did this to make using the array of Variants easier (helps the IDE's auto-complete) and to provide type safety. It works fine but now I have a wrinkle. The array of Variants are initialized to NULL when the class that wraps it is constructed, so I can tell if a particular variant has ever been instantiated with a value. A consequence of this is if only some of the Variants are instantiated (given valid values), any attempt to access a property that currently represents a NULL Variant will cause a Variant conversion error when Delphi tries to convert the variant to the type declared by the indexed property.
I would much rather not declare an "isValid" property for each indexed property. I was wondering if there was a way to use the TypeInfo library to get the raw value of the underlying Variant without having to access the indexed property directly and thus triggering the conversion Exception. Then I could write code like (using the example property above):
isValidProperty(responseCode);
and that function would return TRUE if the Variant underlying the responseCode property is not NULL and FALSE if it is.
I know I can walk the PPropList property list for the class and access the properties by name, but then I would have to use code like:
isValidProperty('responseCode');
and pass the property name in string form instead of passing in the property directly like the first isValidProperty() above. Is there a way to do this?
So you want "to get the raw value of the underlying Variant without having to access the indexed property directly and thus triggering the conversion Exception". So long as you can access the underlying Variant itself, yes, you can. You will need to change the container class itself most likely.
From the Delphi XE2 help page on variant types:
The standard function VarType returns a variant's type code. The
varTypeMask constant is a bit mask used to extract the code from
VarType's return value, so that, for example,
VarType(V) and varTypeMask = varDouble
returns True if V contains a Double or an
array of Double. (The mask simply hides the first bit, which indicates
whether the variant holds an array.) The TVarData record type defined
in the System unit can be used to typecast variants and gain access to
their internal representation.
You should be able to use a combination of the methods and records mentioned here to find out anything you want about the internal data inside the variant, including if it's a NULL variant, as well as getting direct access to it.
(This system seems slightly dodgy design to me: it doesn't seem a very type safe implementation... see my comment above. I think a design based on the actual types of the values you are expecting might be safer. But, this will let you achieve your goal.)
In Delphi you can pass class references around to compare the types of objects, and to instantiate them. Can you do the same with interface references being passed to a COM automation server?
For example, you can define a method taking a GUID parameter using the type library editor:
function ChildNodesOfType(NodeType: TGUID): IMBNode; safecall;
In this function I would like to return automation types that support the interface specified by NodeType, e.g.
if Supports(SomeNode, NodeType) then
result := SomeNode;
But the Supports call always fails, I tried passing in the Guids defined in the type library but none of the different types (Ixxx, Class_xxxx, IId_Ixxxx) seem to work.
The SysUtils unit comes with at least five overloads of Supports, and they all accept a TGUID value for their second parameters.
You can indeed pass interface types as parameters, but they're really just GUIDs. That is, when a function expects a TGUID argument, you can pass it the interface type identifier, such as IMBNode or IUnknown. For that to work, though, the interface type needs to include a GUID in its declaration, like this:
type
IMBNode = interface
['{GUID-goes-here}']
// methods and properties
end;
When the first parameter to Supports is an interface reference, the function calls its QueryInterface method. If it returns S_OK, then Supports return true; otherwise, it returns false. When the first parameter is an object reference, then it first calls the object's GetInterface method to get its IUnknown interface, and calls Supports on that like before. If it doesn't work that way, then it falls back to asking for the requested interface directly from GetInterface. If you've implemented QueryInterface correctly on your object, or if you've used the default implementation from TInterfacedObject, then everything should work fine.
If Supports never returns true for you, then you should revisit some assumptions. Are you sure your node really supports the interface you're requesting? Go make sure the class declaration includes that interface. Make sure QueryInterface is implemented properly. And make sure SomeNode actually refers to the node you're expecting it to.
ShowMessage(TRttiContext.Create.GetType(TStringList)
.GetProperty('Strings').ToString);
Above code fails as .GetProperty returns nil on properties like "Strings", "Objects", "Values" (ones with indexers). I assume this is a known limitation and the question is if there's any way to access those indexed properties (preferably without falling back to the old RTTI utils).
Indexed properties don't have RTTI, but the underlying fields do. So you can access TStringList.FList directly through RTTI. Be careful, though, as this involves raw pointers, and make sure you don't go beyond the Count property. You can do similar things with other classes.
There are gaps in the RTTI. Indexed properties are one.
But when you don't get the property name, why you try to access them? ;-) When you know there is such a property you can try a cast instead.
You don't get RTTI for method parameters of the typ
procedure MyProc(const AParam: array of AType)
also.
Anybody knowing more elements were we can't get RTTI?
Is it possible to declare a property in an interface without declaring the get- and set-methods for it? Something like:
IValue = interface
property value: double;
end;
I want to state that the implementor should have a property called value, returning a double, but I really don't care if it returns a private field or the result from a function.
If it is possible, is it possible to declare it read/write or read-only?
No. Interfaces are implemented as function tables (basically a simple virtual method table) and the compiler needs to know there's a function to map the property onto. You can declare a property on an interface, but it has to have functions as getter/setter values, not fields. You can make it read-only or write-only, though.
When working with properties in an interface, think of the property as a shortcut to the reader/writer. Only one is required to satisfy the shortcut...otherwise it doesn't point to anything.