I would do the following
Var
Descendant : IFirstDecendant;
Begin
NewObject = TNewClass.Create; //I am going with the assumption that
your
//NewObject is know to be an interfaced object
If (NewObject as
IInterface).QueryInterface(IFirstDescendant,Descendant)=0 then
//Code here
In the past I have used const in a proc or func to allow re-entering the routine
later to use the same variable value. But reading the following help it seems I
am doing the wrong thing. Should I be using a global variable instead?
QUOTE
A constant (const) parameter is like a local constant
Dear Todd
My understanding is that interfaces inherit transparently (as you would
expect). QueryInterface should give you the answer you need.
A return result of 0 means success. An additional benefit is it does a
safe cast for you at the same time.
e.g.
if
If it is a COM object, you might be able to query the type lib to see if
this is the case.
The easy solution to your problem is
TNewClass = class(TInterfacedObject,IFirstDescendant,ISecondDescendant);
But I suspect that this is not feasible in your case.
Myles.
-Original Message-
Have you tried
if Supports(aObject, IFirstInterface,oFirstInterface)
Interface inheritance is different from object inheritance, and can seem odd
until you get your head around it. But the supports function always will
give you the answer you require providing you are using D6 or later.
Todd
What does 'Supports' return?
also you could declare
TNewClass = class(TInterfacedObject, IFirstDescendant, ISecondDescendant);
Neven
- Original Message -
From: Todd Martin [EMAIL PROTECTED]
To: Multiple recipients of list delphi [EMAIL PROTECTED]
Sent: Friday, June 13, 2003 1:52
IIRC, one doesn't get interface inheritance as you seem to expect.
You will explicitly have to implement IFirstDescendant in your TNewClass.
I'm sure there are people out there who can explain what's happening under
the hood, but AFAIK, that's the way it is.
HTH,
Conor
-Original
Todd Martin asks:
I'm thinking the VTable entry for the ISecondDescendant interface, might
link back to IFirstDescendant somehow.
No, The VTable specification for interfaces is basically a chunk of of
vitutal method table that implements the methods defined by an interface.
Interface
I probably should have been clearer in my reply.
This is what I was getting at, thanks Neven. ;-)
You have to explicitly declare every interface that you want your class to
implement directly, i.e. with your original declaration, you can be sure
that the compiler will force you to implement all
Max wrote:
In certian situation you may not want IFirstDescendant to be available
if ISecondDescendant is available, and so Delphi's behaviour is
actually to your benefit as it allow comlpete control over exactly
what interfaces an object makes available to QueryInterface. It is
always better
Hi Al,
The quote you mention is talking about constant PARAMETERS. You're talking
about having the value of a constant INSIDE a method maintain it's state
between invocations.
If you want to take an OO purist POV, don't ever use 'global' variables. ;-)
IMHO, don't even use variables in the
I am afraid you mistake a function parameter as a variable declared in a
function.
The QUOTE is talking about the const parameter e.g. procedure myProc(const
par1 : integer);
Your example shows that you are talking about the constant variable defined
in a procedure/function.
Different topic
Karl Reynolds asked me:
Hmmm. I'd like to hear of a situation where you wouldn't want an ancestor
interface to be available where the descendant is.
OK, one example I foiund within two minutes of looking into the MSDN is the
follwing quote directly from Microsoft:
An Interface is an Interface is an Interface is an Interface.
Really, there is no such thing as Interface Inheritance.
An object either implements an Inteface or it does not. End of story.
Something like
IMyStuff = interface(IDispatch)
...
end;
Is not actually inheritance. Technically this
So this is one simple case where you have IStream inheriting
from ISequentialStream (see ActiveX.pas) but you are not required
to implement ISequentialStream is you are implementing IStream.
Utterly bizarre. I get your point - that interface inheritance has to be
implemented the way it is in
Neven,
I have actually got it working... the critical bit (which is why it didnt
work before) was the sequence and the fact that you have to create
all the fields.
for qry
prepare
fielddefs.update
create the new fielddef
create all fields from fielddefs
modify own field to make calculated
Alistair I do it all the time for standalone procedures. For methods, I
put them in the component/object declaration as private variables -
allowing each invocation to have its own variable.
To: Multiple recipients of list delphi
[EMAIL PROTECTED]
Send reply to:
There are a lot of people (including me) who never use the term 'interface
inheritance'. You're right, it's not inheritance.
As an aside, having had the 'chance' recently to go some VB6 coding :-( I
found the Microsoft documentation utterly misleading when it talks about
interface inheritance,
Simple answer is no. Your class *DOES NOT* support IFirstDescendant. You
must explicitly tell the compiler that your class supports IFirstDescendant:
TNewClass = class(TInterfacedObject,IFirstDescendant,ISecondDescendant)
Interface inheritance is *DIFFERENT* from class inheritance. The idea
What you read only applies to const parameters. I would continue to use
method level consts and not move them to the unit level. In fact, I *never*
use unit level vars, except for the Delphi generated main form code. Using
method level is safer than unit level vars.
Eg. in multi-threading
FYI, maybe this is what you meant, but AFAIK you can safely remove the
Delphi generated form vars from every form unit except your apps main form.
[Comprehensive answer on the interface stuff, BTW!]
Cheers,
C.
-Original Message-
From: Dennis Chuah [mailto:[EMAIL PROTECTED]
What you
Hi Guys.
Thanks for all the feedback. I didn't realise it would get so much response.
In the end I decided to go with the following :
IFirstDescendant = interface(IInterface);
ISecondDescendant = interface(IFirstDescendant);
TNewClass = class(TInterfacedObject,IFirstDescendant
I'll second that!
Cheers,
C.
-Original Message-
From: Dennis Chuah [mailto:[EMAIL PROTECTED]
FYI, maybe this is what you meant, but AFAIK you can safely remove the
Delphi generated form vars from every form unit except your apps main
form.
Yes, that is kinda what I meant. Its a
Mmmm, I haven't got time right now to try it, but that's not the behaviour
I'd expect.
I'd have hoped the compiler would pick that up, as it appears to with your
second example.
Interesting, can't explain it...
C.
-Original Message-
From: Todd Martin [mailto:[EMAIL PROTECTED]
However
Rohit
This is interesting, obviously the query 'prepare' and the open/
close cycle on the table read enough metadata for you to regen the Fields
N
- Original Message -
From: Rohit Gupta [EMAIL PROTECTED]
To: Multiple recipients of list delphi [EMAIL PROTECTED]
Sent: Monday, June 16,
You need to look at the compiled code. I would expect that a
cast/QueryInterface is done behind the scenes by the compiler.
It is possible given the declaration of ISecondDescendant, that IFirst...
may be implemented. The compiler at the call point to DoSomething, does not
know the reference was
I believe it's a fault in the compiler. If you debug it it actually will
show the object as Isecond, even though
The variable is declared as Ifirst. The code will never crash because
all the methods of Ifirst must exist in an Isecond.
I wouldn't rely on future versions of Delphi keeping the
Karl
I think it was a mistake of Borland not to include ancestor
interfaces automatically.
If they did this there would be no method of declaring a 'abstract'
interface
Neven
---
New Zealand Delphi Users group -
28 matches
Mail list logo
