Well I mentioned 'one way' to do it. I guess Neven has mentioned 'another' way to do it.
'correct' is like skinning a cat. It depends on the question asked. While the interface method is potentially a cleaner way of doing something in a perfect world where all things are defined In a nice application Framework where the author has subclassed every visual control they ever want or might use, VCL or 3rd party to implement an interface. Giovanni's original question implied a generic, I don't want to know what I'm talking to, only That it has a property and is already an existing object in an existing architecture. Therefore correct is a matter of perspective within the given boundaries of the environment. In this case, based on the question, I think RTTI use to replace the one routine is more 'correct' than recommending refactoring an entire application of unknown quantity. IMHO Regards Kyley -----Original Message----- From: [EMAIL PROTECTED] [mailto:owner-delphi@;delphi.org.nz] On Behalf Of Neven MacEwan Sent: Wednesday, 23 October 2002 9:12 p.m. To: Multiple recipients of list delphi Subject: Re: [DUG]: Polymorphic assignment to Color - How? (sometime it's a Property, sometimes not) Giovanni The 'correct' way would be to implement an interface 1/ Declare the interface type IPresentation = interface(IInterface) procedure SetColor(Value: TColor); end 2/ Implement the IF on your classes type TColorableFrom = class(TForm, IPresentation) you then have the option of implementuing the interface or delegating it to an 'helper' object then to use it var PesI: IPresentation; if Supports(Instance,IPresentation, PresI) then Pesi.SetColor(Color) HTH Neven ----- Original Message ----- From: "Moretti, Giovanni" <[EMAIL PROTECTED]> To: "Multiple recipients of list delphi" <[EMAIL PROTECTED]> Sent: Wednesday, October 23, 2002 6:23 PM Subject: [DUG]: Polymorphic assignment to Color - How? (sometime it's a Property, sometimes not) > Hi > > I'm building a list of objects that can be coloured and want to be > able to get/set their colour. > > The object properties are all going to be stored in a Tlist so the > types will probably need to be stored along with them. I'm happy to store the Object type (eg Tform ...) along with the reference to the object but I can't see a general way to do this and get/set the color. > > ========= ATTEMPT #1 =========================================== > > In the olden days, before properties, I'd have just passed a pointer > to the Tcolor value: > > procedure setObjectColour (Color : ^TColor ; > newColour : TColor); > begin > Color^ := newColour; > end; > > setObjectColour(@Label3.Color, clRed); > > I tried this, but it's unpredictable as sometimes an object's color is just a TColor (a glorified integer) but other times it's a property with get/set methods. > > ========= ATTEMPT #2 =========================================== > > Figuring the run-time type information should be able to handle this, > I tried: > > Type TControlClass = Class of Tcontrol; > > procedure setObjectColour ( obj : TObject; > whatClass : TControlClass; > newColour : TColor); > begin > (obj as whatClass).color := newColour; > ^-------------- ERROR - COLOR not declared > // OR > > whatClass(object).color := newColour; > ^----------------------------Missing Operator or ; > end; > > setObjectColour(Label3, Tlabel, clRed); // To Recolour something > > But neither will compile without errors. > > ========= FINALLY =========================================== > > It's not elegant but has the great virtue that it actually works: > > procedure setObjectColour ( obj : TObject; > newColour : TColor); > begin > if (obj is TForm) then (obj as TForm) .color := newColour > else if (obj is TLabel) then (obj as TLabel).color := newColour > else if (obj is TFont ) then (obj as TFont) .color := newColour > else if (obj is TBrush) then (obj as TBrush).color := newColour > else if (obj is TPen) then (obj as TPen) .color := newColour > else showMessage('setObjectColour: Don''t know how'); > end; > > setObjectColour(Form1, clRed); > > Except this means that adding new types of things will require adding > of extra "if .." statements which with polymorphism should be necessary. Unfortunately you can't do the more general: > > (obj as Tcontrol).color := newColour; > > As Tcontrol's "color" is protected (and can't be seen this won't > compile). Only Tcontrol's descendents expose some way of getting/setting color. > > I want to be able to recolour anything that has a colour but there > must be a better way than tests for explicit types/classes ... > > Any Ideas? > > Thanks > Giovanni > ====================================================================== > == > Giovanni Moretti | Institute of Information Sciences and Technology > Senior Lecturer | Massey University, Palmerston North, New Zealand > Computer Science | Ph 64-6-3505799x2474 == Fax 64-6-3502259 == ZL2BOI > ------------------------------------------------------------------------ > http://www-ist.massey.ac.nz/moretti mailto:G.Moretti@;massey.ac.nz > ------------------------------------------------------------------------ -- - > New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] > Website: http://www.delphi.org.nz > To UnSub, send email to: [EMAIL PROTECTED] > with body of "unsubscribe delphi" > Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/ > ------------------------------------------------------------------------ --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi" Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/ --------------------------------------------------------------------------- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi" Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
