How do I hide inherited published properties in a runtime designer?

Question

I am using a property inspector (for example the nice JvInspector in the JVCL library) which nicely lets me view and edit the published properties of my class 'TMyClass'. TMyClass descends from TFrame and has a few published properties that are the only ones that I require to see and edit. Of course TFrame has lots of VCL properties, all published, which I see too.

How can I suppress the ancestor property RTTI and just leave my own published properties? I'm using XE3 so the world is my oyster... maybe.

Macomber

Brian, if you will tag your questions 'Delphi' you get times more views and more chances to get answer. – Argentiferous

@Serg - Thanks. I did wonder how the tagging system worked, I hoped that the connecting '-' generated two tags, but that's useful information. – Macomber

You cannot do that, as far as i know. It would break code when the (base-)class is used polymorphistic. – Organzine

Might be easier to create a custom-variant of TJvInspector that ignores properties based on your requirements. – Iodometry

that is why i don't like TFrame :-) in D5 time i used a lot Custom Containers Pack by Borland Moscow. I recently heard some guy ported Custom Containers Pack to XE2 and perhaps you can run it on XE3. Give it a try. – Selfwinding

Answer 1

Derive your class from TCustomFrame, and from your class publish only those properties you'll need. Although you can't basically hide already published properties, there's a lot of them that are protected and that will stay hidden by using of TCustomFrame class as the ancestor for your own class.

That's how almost every control in VCL is composed in the class hierarchy. For instance, TLabel is a TCustomLabel descendant, whose only role in the class chain is to publish properties you can see in the Object Inspector.

Calen

I tried that before posting the question but frustatingly it then breaks the DFM loading mechanism ('property Align is missing' etc). So, I need the basic component behaviour unfortunately. – Macomber

This happens to work because there is a TCustom version of the class. In the general case, though, there is no way to hide already-published properties. Brian, you can fix the DFM-loading by editing the DFM file and removing the no-longer-published properties. (If you still need to use those properties, then you cannot set them in the DFM because they're not published anymore. Instead, set them in code at run time.) – Hopple

@Rob. True. I'm beginning to think I might be better creating a specific dialog for this editing! It's complicated because my TFrame contains a TChart with all its lovely customisable parameters and I wanted to offer those to the user. I see now why FastReport created their own TChart editor. – Macomber

@Brian, the TJvInspector that you were talking about is Open Source; If you were happy with the Object Inspector concept, it shouldn't be difficult to sub-class that inspector and make it hide certain properties. – Iodometry

@Cosmin: Yes, good idea. I think its going that way. BTW I've accepted TLama's answer because although its not a viable solution for me, he is correct in his analysis of the problem. – Macomber

@Brian, although it's not possible to basically hide already published properties, you can at least not expose those published by the TFrame class itself. Using TCustomFrame will keep hidden many of them since there's just a few of them published by the ancestors of the TCustomFrame. – Calen

@Calen But descending from TCustomFrame will prevent it from being able to drop it (as a frame) on the form. – Caird

@NGLN, uhm, then this answer should be discarded. I should have try this before. Thanks for the note! @Brian, could you unaccept this answer, please ? I'll delete it, since if you'd derive your frame from the TCustomFrame then IDE prevents you from working with it. Thanks! I have quite (un)successful reputation period these days... – Calen

Answer 2

FWIW, I have found an RTTI solution to this - i.e to allow only the properties NOT belonging the ancestor class or classes, in other words the properties that you have added, published, yourself in the current class. JvInspector has a BeforeItemCreate event containing the name of the property that will appear in the inspector. This solution tests the property name for being a member of the ancestor class, and only if it is not, it does display it in the inspector. The benefit is that there is no change to any inspector code.

uses
  TypInfo;

procedure TForm1.JvInspectorBeforeItemCreate(Sender: TObject; 
  Data: TJvCustomInspectorData; var ItemClass: TJvInspectorItemClass);
begin
  if IsPublishedProp(TFrame, Data.Name) then
    ItemClass := nil;
end;

Macomber

Since you're only dealing with published properties, you don't need to go the Delphi-2010-RTTI-way: Just include TypInfo and use this one-liner: IsPublishedProperty(TFrame, Prop.Name); much easier to read and error-free. (your code is not calling ctx.Free, that's a bug). – Iodometry

@NGLN, only if the question is edited to say "hide as far as JvInspector is concerned". This solution (while perfect for the OP) doesn't actually hide the published properties. It just tells JvInspector not to show them. – Iodometry

@Cos Well, that's hiding enough for me... ;-) I already edited the question title by adding in a runtime designer. But it's on Brian to deside. (Upvoted TLama's answer too by the way.) – Caird

Answer 3

Create your TMyClass component/frame at runtime.

---

But to keep the ability to edit the properties at design time too, don't descend your TMyClass from TFrame. Instead, descend from:

• TCustomPanel if you want a border,
• TCustomControl if you are able to draw the border yourself,
• TWinControl if you can do without border.

Of course, your TMyClass component then will not appear in the Insert Frame Dialog any longer, but will just be a component like any other.

Caird

That would be the best fitting solution! [+1] – Calen